Slashdot Mirror
Why Do Companies Backup So Infrequently?
Orome1 writes "Businesses are on average backing up to tape once a month, with one alarming statistic showing 10 percent were only backing up to tape once per year, according to a survey by Vanson Bourne. Although cloud backup solutions are becoming more common, still the majority of companies will do their backups in-house. Sometimes they will have dedicated IT staff to run them, but usually it's done in-house because they have always done it like that, and they have confidence in their own security and safekeeping of data."
Portable HD is cheaper and faster, even for stacks of them. Small businesses may be using a bunch of these in place of tapes.
It's expensive, so management does not really want to pay for new tapes, a disk-based system or cloud backup. It requires personnel, which management does not want to pay for either. It's boring for the persons involved (who likes testing their backup?).
Most companies have no risk management, and no clear picture of the risks their business faces.
The result of "intuitive" risk-non-management is that the usual human flaws have full impact. Basically, aside from a narrow middle ground, all risks are wrongly estimated.
Assorted stuff I do sometimes: Lemuria.org
Seriously. Most people aren't willing to put in the effort to determine just how bad things would be if they had to resort to their (often inadequate) backups, and therefore they aren't willing to pay the time and capital to get adequate backups.
If you want your company to get better backups, run a simulation of what would happen if something failed. What's the best recovery you could do? What business would you lose? Then calculate the probability of that failure occurring, and be generous.
Insert self-referential sig here.
Mod me down for trolling all you want, he deserved the pun after not making backups for 15 years consecutively.
I was promised a flying car. Where is my flying car?
Then a few weeks ago another unit on the industrial was torched -- arson. I have finally pursuaded them ...
Ahhh yes, the old "Nice data you have there, be a shame if something happened to it" trick.
No need to explain, friend, we all know what happened there.
I am curious if you did the deed yourself or contracted it out to a professional, though. ;)
I hope you're a troll, because if you're not, this is just about the most insanely fucked up attitude to data protection I've ever seen.
A blind "Let's just backup the whole server" isn't an effective backup strategy ...
If I was your boss I'd fire you on the spot for being that monumentally stupid. The cost ratio of an additional ~20GB of tape compared the enormous cost to the business if the server can't be restored quickly and reliably is staggering. Think $1 saved while risking millions of dollars of potential lost work! (1.6TB LTO5 tape = $80)
a) "what if you upgrade to a larger disk" -- there is no backup system on Earth that can't restore to bigger disks. Most systems can restore to smaller disks too.
b) "what if the server is slower than others and people start moving their data to something" -- you back up both of them. Restoring too much is almost never as bad as restoring too little.
c) "just blanket-backing-up is likely to lead to problems later on" -- no, it doesn't. Achieving 100% coverage ensures that no matter where you data was on a server (or which server), it's on a tape somewhere.
d) "notifying IT of new things that need to be backed up" -- have you met humans? This never happens reliably, and can't ever be made reliable.
Back in the real world, a 100% complete backup of a typical Windows server can be restored without knowing the password, to dissimilar hardware (even virtual machines), and without needing the "original install disks". When it's done, it'll boot up, maybe reboot once or twice to fix up its drivers, and then your server is back, working as it did before. Compare that to a "data only" or partial backup. Now suddenly you're chasing down design documentation, passwords, IP addresses, software, serial numbers, and you haven't even started to restore anything yet. The clock is ticking, and the customer is breathing down your neck.
A week's work should take no more than two weeks at ABSOLUTE maximum to recreate
Recreate from what? Memory? Including data that was 100% electronic, and never seen by a human? How do you recreate your emails? How do you recreate your audit logs? How do you type back in non-textual data like digital images or audio recordings? How would you even know what's missing?
I'd rather have a decent monthly, than an imperfect daily
That's a false dichotomy. The total data stored is the same, you're just altering the frequency. The same amount of storage is needed, the same bandwidth is needed, and it ends up costing the same.
I'd rather have three backups a day than monthly backups. Losing a day of work could mean a contract fails to go through. I've been in a position twice now where users have come to me literally crying and begging to retrieve a document they only started working on that morning that they had deleted accidentally... at 8pm, minutes before a deadline for a multi million dollar deal. After experiences like those I've often set up incremental backup frequencies as rapid as 15 minutes.
So lets recap... your sum total DR experience is you once walked into a poorly supported environment, and gave them some even worse advice, without ever being in a position to be responsible for an actual real world recovery.
Well, take some advice from someone who's restored terabytes of data, and was responsible for the protection of over a petabyte spread across thousands of servers at over a dozen organisations:
#1 There are no time machines -- you cannot go back in time to fix a mistake in your backup strategy after a disaster. It's too late. You've fucked up, it's your fault, and you can never, ever, fix it.
#2 Back up everything -- I love genius IT folk who like to shave 1% off their backup times by excluding those useless temp and log files, also excluding 'useless junk' like their database transaction logs in the process.