Slashdot Mirror


Hacker Destroys Avsim.com, Along With Its Backups

el americano writes "Flight Simulator community website Avsim has experienced a total data loss after both of their online servers were hacked. The site's founder, Tom Allensworth, explained why 13 years of community developed terrains, skins, and mods will not be restored from backups: 'Some have asked whether or not we had back ups. Yes, we dutifully backed up our servers every day. Unfortunately, we backed up the servers between our two servers. The hacker took out both servers, destroying our ability to use one or the other back up to remedy the situation.'"

3 of 780 comments (clear)

  1. Offsite backups? by Anonymous Coward · · Score: 5, Interesting

    I realize that from quite a few people's perspectives, storing their backups in a separate building constitutes off site storage. I'd almost buy that strategy. Not in the same environment, network, city etc.

    These guys were stupid.

    The day after 9/11 I was in an elevator, and caught a snippet of conversation between 2 people that had business interests with a firm that was in the WTC. The comment I heard was 'their backups were in the other building'. Another company lost.

    You can never totally plan for every contingency, but you can insure yourself. I know many developers that take hard copies of their code (meaning on removable media) home just for this reason. I have seen sys admins do the same because they didn't trust their DR stratagy.

    This was avoidable. This isn't even about disaster recovery. It is about business continuity.

    You can't afford not to protect your data.

  2. Some backup stories by IntentionalStance · · Score: 5, Interesting

    I worked for a computer bureaux in the 80's. We upgraded the operating system - very cool, the new release allowed larger files. We didn't, unfortunately, upgrade the backup utility to handle these larger files. Months go by - then there's a problem - whoops backups are useless - Luckily there's a physical audit trail so we we can pay for very large data entry exercise to get our client's data back.

    A couple of years later, I am in the pub with some mates and John turns up. I ask him how he's managed to finish work and get to the pub so early. "I did a fast backup" he said. I was interested so I asked him to explain. "Oh, it's easy, get the target tapes from the rack, rub out the old date, write the new date, put them back into rack and go to the pub"

    Worked for a large software shop in the 90's. I am part of a decent sized Oracle development (circa 50 devs). Ops decides that Oracles backup routines are too slow and 'optimize' them. Some weeks later - guess what - there's a problem and the backups are useless - No physical audit trail this time - the team has to redo all of there work - it was not good for the project budget, the team moral or the client

  3. Re:This should be a lesson... by short · · Score: 5, Interesting

    'dd if=/dev/random of=/dev/sda'

    • Use /dev/urandom as /dev/random will immediately exhaust your kernel entropy pool and hangs to get more (or it is at least unusably slow). urandom is more than enough for this purpose.
    • There are no reports anyone would be even able to restore data after rewriting them with simple /dev/zero. OTOH rewriting by /dev/urandom and /dev/zero costs mostly the same so why to care if /dev/zero is enough.
    • cat /dev/something >/dev/sda is enough/easier on any Linux kernel, dd had to be used on some old commercial Unices nobody has seen for 30 years now.