Unix Backup and Recovery

Following Proper Development Procedures

Don’t make a new change on your backup script and then roll it out to all your machines at once. Test it on a development system, or better yet, on a system that you don’t normally back up. That way you aren’t putting any backups in jeopardy. Another good practice is to test the change in parallel with what you’re already doing. The bigger the change, the more important it is to do a parallel conversion. This is especially true if you’re using a new method, rather than just enhancing your current one. Don’t stop using your old method until you’re sure that the new one works! Follow a plan similar to this:

• Test the syntax of your new script somewhere where it really won’t hurt anybody if it does something like, oh, crash the system!

• Test the operation on a small scale on one system, using it in the same manner as you would in production. For example, if you are going to do both remote and local backups with this program, test both on a small scale.

• Try to simulate every potential error the program might encounter:

  • Eject a volume in the middle of the backup.

  • Write-protect a volume.

  • Reboot the system you are backing up while it is backing up.

  • Drop the network connection and power down a disk drive.

  • Know the program and the errors for which it is testing, and simulate each one to test that section of your program.

• Test on a small number of systems, preferably in parallel with your current method.

• When you roll it out to all systems, definitely do so in ...