Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

What is Your Backup Policy? 124

higuita asks: "A few days ago, I was asked to check our backups policy, how they are being applied and to try to make it safer and more useful. Being new to the company, I started to check what is being done right now and found several problems. Since I don't have much experience with enterprise backups, what are the most used backup policies, software and global ideas about this issue? We have less than 1000 workstations (Windows and Macs), about 20 Oracle and Exchange servers (split between Windows, Solaris, and Linux), and it all needs to be backed up. Right now, we use the HP data protector with several tapes, where most things have a weekly full backup and daily incremental backups, and that most full backups are archived permanently in a safe we have for this purpose. We also have off-site storage for backups, as well. What practices and policies do Slashdot users implement for backups they perform at their office (home backups practices I am not interested in)?"
"I've investigated Veritas NetBackup and other solutions, and I'm also curious if Amanda could be better or at approximate the features offered by HP Data Protector. What backup software have you used that you found enjoyable with the least bit of hassle?

I've thought about using Dirvish to backup the user's homes to a cheap server with several HDs, and only backup to tapes once every 15 days or even once a month. They will lose their Windows permissions, but I don't think that matters much, since this is just for safekeeping the users' work. I thought about making full backups of the servers every 15 days with daily incremental backups. This way I will free up tape drives' time and gain more flexibility with the backup schedule.

I would love it if users worked off of file servers, but right now this just isn't possible. It's a planned addition that we still don't have the time to make."
This discussion has been archived. No new comments can be posted.

What is Your Backup Policy?

Comments Filter:
  • by georgewilliamherbert ( 211790 ) on Wednesday May 31, 2006 @09:45PM (#15441085)
    For that many systems, use a professional, enterprise grade, commercial solution. The open source stuff doesn't supply the same manageability.

    AND FOR GOD'S SAKE, REGULARLY VERIFY THAT YOU CAN READ THE TAPES BACK... More sites have been screwed by backup tapes that weren't readable than any other failure mode. Verifying every tape is best. Second best is every weekly. Random samples, but covering every single drive's tape output at least once a month, are poor third place.

    The two obvious software suggestions are Veritas/Symantec NetBackup and Legato Networker.

    Weekly fulls and daily incrementals are good. Your offsite schedule should be checked to ensure that you have a relatively recent restore point both onsite (in case of data loss) and offsite (in case of building loss).

    In terms of offsites, having a prepared plan for where and how to restore (Disaster Recovery and Business Continuity) is also important. But those all start with "Go get the tapes...".
  • Paper (Score:5, Informative)

    by NetDanzr ( 619387 ) on Wednesday May 31, 2006 @10:28PM (#15441319)
    My backup copy is paper. Granted, it gets a little awkward when I move, as I currently have six large file boxes of that stuff, but I know that as long as I keep it reasonably safe from humidity/mice it'll outlive all my computer media and file format changes.

    At work we do the same, only to a larger extent. We've got an on-site and off-site storage, and each piece of information is printed in two copies to be stored at each. All that in addition to your usual Veritas tape and CD-RW backups, which we do for convenience of restoring lost data, but which we don't trust enough to eliminate paper copies.

  • by Anonymous Coward on Wednesday May 31, 2006 @11:06PM (#15441524)
    I'm extremely less than impressed with 'enterprise backup solutions', regardless the endless touting they receive in the vendor-supported trade rags and by vendor-supported 'industry analysts'. The 'enterprise backup solutions' I've seen, have been so clunky and hard to use, setting up and maintaining backups is a full time job. When you think about ACTUALLY DOING A DR using these 'products' they often come up short.

    Also, sorry, but reinstalling the OS, and then restoring files from tape is NOT acceptable DR (you can thank the proliferation of bill gates OSes in all datacenters for the idea that this could be even close to OK). Datacenters with lots of pc systems have as their saving hope - vmware. Now they can actually restore from bare metal (bare metal in this case being a standard virtual machine). What is needed in this case is a simple solid backup/restore program and a good integrated tape librarian program. But brainwashed IT managers want these overpriced, overhyped, overwrought, 'enterprise backup solutions'. Oh well!

  • by mlheur ( 212082 ) on Wednesday May 31, 2006 @11:18PM (#15441578)
    I don't give two hoots for a backup policy. What you need is a data recovery policy. When will I need to recover data, and how will it that be attained.

    I've been working with Symantec (formerly Veritas) Netbackup in my workplace for the past 6 years. About 6 months ago I became one of the backup admins, and the biggest barrier I have to break with our clients is the backup mentality - I must backup everything all the time...

    Generally your data recovery will happen from two triggers:

    1. A user broke his own stuff and needs a file restored.
    2. Disaster Recovery.

    Each has different requirements, user wants the backup copy to be onsite, DR wants it to be offsite.
    User PC's typically can be rebuilt/imaged in a disaster, you're not going to have a hot-site contract for PC's. If your DR plan is to install an OS, install a backup/restore client software then recover databases/applications, then why fret about backing up the OS?

    Our policy is as follows

    NT/Unix OS and flat files
    Monthly full backups retained for 13 months
    Weekly full backups retained for 6 weeks
    Daily cumulative incremental (everything changed since the last full) retained for 15 days

    Oracle Datafiles
    Weekly cold for 13 months
    Daily hot for 6 weeks
    1-6 hour archive logs for 15 days

    Exchange Datastores
    Daily full for 6 weeks
    Weekly full for 13 months

    Every day any full backups that are more than 10 days old (not copy 0) are sent offsite.

    Any customer that has a DRP contract (banks etc) with a 4 hour recovery policy (we have 3 days to get the system back to how it was 4 hours before the disaster) we either run inline tape copies, one for onsite and one for offsite, or else we backup overnight and duplicate during the day.

    Your most important backup (for Netbackup) is your catalog. If you go to DR and all you have is a box of tapes, good luck. You need to know what data is on what tape, and the only thing that knows that is the Netbackup catalog.
    I don't know much about other backup products (HP OpenView and BackupExec are the only others I've touched), but I'm sure they'll have something similar.

    I've got lots more to say, but I don't have time to put it all down now. Send me a /. message if you want more info.
  • by Colin Smith ( 2679 ) on Thursday June 01, 2006 @05:07AM (#15443014)
    I've used Amanda, Bakula, Netbackup, Networker and by far the best of the bunch for enterprise size networks is TSM. Easily. Netbackup is something I still have cold sweats and nightmares about, ok, not quite nightmares, just the occasional cold sweat. It's really a small network system which has been kludged to "enterprise" class. TSM was designed for managing large network backups from the start.

     
  • by thempstead ( 30898 ) on Thursday June 01, 2006 @09:25AM (#15444021)
    I would agree with this, having used various of the products mentioned, with the following comments ...

    1. Be aware that TSM is quite expensive!
    2. If you go with TSM get decent training for it. I have worked with several systems which have been setup incorrectly because the person(s) setting up the TSM system had not had sufficient training in order to configure things properly.
    3. (Related to 2), make sure you know how to recover your TSM system in the event of a full DR, (not difficult if you know what you are doing but can beinteresting if you don't).

    t

Software production is assumed to be a line function, but it is run like a staff function. -- Paul Licker

Working...