Why Do Companies Backup So Infrequently? 403
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."
Re:To Tape... (Score:5, Informative)
Indeed. My own [small place of business] does its backups this way with Acronis:
-
Every day, a drive is plugged in.
Every evening, an incremental backup is performed on that drive that is consistent with whatever the backup drive already had on it. (It just takes a few minutes for Acronis to get this done.)
After that it is removed and taken off-site. A different drive is plugged in the following day.
Fridays are special, in that the drive gets automagically erased, and a full backup is performed mid-day. But then the evening incremental ritual is the same as any other day of the week.
-
Losing a backup disk is, at most, 24 hours worth of loss, and only then if it is coincident with losing the main system.
FWIW: We use the cheapest 2.5" laptop drives available, in the cheapest bus-powered 2.5" USB enclosures we can get our hands on (I think the last round of them cost us $5, each). And we test our backups randomly, whenever the accountant decides he wants to see what things looked like last week/last year. Acronis then cheerfully does a bare-metal restore from [random backup drive] onto our spare server-box, with 100% success.
Now: We're not a media company. We don't have tens of TB of changing data to back up on a daily basis. But most other small(ish) companies don't either...
Who needs tapes?
Re:To Tape... (Score:5, Informative)
Perhaps for *very* small businesses with not much data, or where the restore time is not a critical factor.
Even with our 32Mbit connection at work it would take about 40 hours in transfer time alone to get our data "out of the cloud" in a disaster scenario. (And part of that bandwidth would still be needed to keep other operations running, so it might even take longer) You can perhaps make small, incremental backups into the cloud, but when you need the data in an emergency you need it as fast as possible. Restore from tape took two hours. (We had a chance to do it "for real" earlier this year ;-P )
Re:To Tape... (Score:5, Informative)
Re:My own backups (Score:2, Informative)
RAID is not a Backup
Re:Tape is frightening in and of itself (Score:4, Informative)
I have had SDLT tapes I recovered from the floor of a server room after sitting for 3 days under water that read just fine in a drive after being dried out.
If you get a decent tape backup it has built in redundancy, 48 tracks of data with CRC checking and redundant data written in case that CRC fails.
Granted, I'd not rely on them surviving kicked around the floor, but a real tape backup system is far, far more robust than the under $1000 garbage sold at newegg.
Re:To Tape... (Score:5, Informative)
There are many different backup strategies depending on what you are backing up and if your backups are designed for disaster recovery or archival of data.
Making some presumptions here to answer your questions:
They use a rotation of 5 or (7 drives if including weekends). Monday's drive is always the same, as is Tuesdays, Wednesday, etc. Each drive is kept offsite and only that day's drive is brought onsite while others remain offsite, or are taken back offsite.
If on Thursday the server goes down, they just request Wednesday's drive for the restore. If that backup was unsuccessful or the drive just happened to fail, then they lose Wednesday's business and go back to Tuesdays. Repeat until they get a successful restore.
Fridays basically are not an incremental backup. Well, the evening is, but the midday backup is a full backup and then is incrementally updated from the 1/2 day of business that night.
With this scheme, they can't restore a backup from a year ago. Depending on what is being backed up, they may not have to go back a year. Accounting information for instance from a year ago may be in the current backup set. If you are looking to restore something that was corrupted or deleted at an unknown point and wouldn't be in the current backup, then it would just take 1 disk out of the rotation once a month for instance and replace it with a new drive. A previous company I worked for recommend this strategy with point of sale systems we sold. We gave them a box of 10 backup tapes. 6 nightly backup tapes and 4 weekly tapes. The weekly tapes were in a 4-week rotation while the nightly were in a 1 week rotation. If they wanted to do a monthly rotation they could purchase additional tapes.
The $5 wasn't for the drive, it was for the enclosure and/or drive adapter.
Re:To Tape... (Score:4, Informative)
The most common reason for needing a restore, is accidental deletion.
It is, but the most common use for tape is compliance, Many companies, and all public companies have compliance issues, SarBox, HIPAA, GLB, etc. Most require data retention of many years. In some medical settings as much as 21 years. Do you want to keep that all on spinning disks? or on CHEAP tape sitting in a box at Iron Mountain? In my environment, and that of many large companies, we no longer measure terrabytes, except at the individual database level. We manage several petabytes.
disk based solutions are operationally ideal. Thats why products like Avamar and Data Domain do so well. But for large, long term, low access, storage, tape is still king.
Re:To Tape... (Score:4, Informative)
Yup; and note that "backup" these days often includes mirroring on other live system.
I've seen backups to tapes and external disks fail more often than I've seen them succeed. I've also over the years seen any number of estimates that around 50% of backup tapes aren't usable when they're needed. I've often been suspicious that there may be large error bars around that number, but so far I haven't seen any evidence on the topic. This makes me further suspicious that the people writing on the topic are assuming that I'm too stupid to understand anything more detailed or informative than "50%", implying to me that the reality could well be even worse than that.
OTOH, since large (whatever that means) disks became reasonably cheap and network access became inexpensive, around 10 years ago, it has become feasible to use rsync for backup. It's easy enough to install more disk than you need on several widely-separated machines, and have all of them back up all the others. This is especially easy if they happen to share a lot of the stuff that needs backing up. The data is stored in its original form, and if your backup media dies, you know about it very quickly. Restoring always works, because it's done via another rsync, which you know how to use (and is documented all over ;-).
The only real "gotcha" I've seen with this came in working on projects that had a mixture of Macs and Windows systems, together with the usual unix/linux-based servers. The hokey attempts at "caseless" file names on OS X and Windows, not quite the same on the two OSs (or on different releases ;-) causes some, uh, "interesting" name collisions and loss of files. The unix/linux systems can back up OS X and Windows files without problems, since they are agnostic about charsets, but if you try to back up their file systems on an OS X or Windows box, you tend to lose files due to multiple names being mapped to a single name.
I've actually made this work, by learning enough about the OS X and Windows file-name munging to avoid the problem. But we haven't (yet) learned how to avoid the problems with OS X and Windows attempt to mirror each others' file systems. So our rule amounts to "Do all rsyncs from OS X or Windows to/from the unix/linux servers, and don't let OS X or Windows mirror a file system from a different species of OS." (If you must do this, test the results thoroughly to make sure that neither OS is mapping two file names to the same byte string, and repeat the tests frequently to verify that new files don't trigger the problem.)
(I can already hear the shouts of "Mirroring isn't backup, you idiot!". I fully intend to ignore such comments. The term "backup" means any sort of copy that we can later use to restore our data. It doesn't mean tapes. It means anything that I can restore my data from. Nothing more or less than that. So whatever you're trying to sell - or prevent me from buying - is irrelevant. All I want to know is how good your favorite product is at keeping and restoring my data. Well, OK, I also want to know whether I can keep my data private, so I'm ignoring all "cloud" backup schemes. But data security is a different topic from data safety, so I'll ignore that here, too. ;-)