Section 2.9. Following Proper Development Procedures

2.9. Following Proper Development Procedures

Don't make a new change on your backup system 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 backup changes somewhere where they really won't hurt anybody if they do 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 system 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 system and the errors for which it is testing, and simulate each one to test that section of your system.

• 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 parallel. One of the ways you can do this is to squeeze all your backups onto as few volumes as you can, then use the leftover drives to do the new backup in parallel. Your network guys might hate you, but it's really the only way to do a true parallel conversion. When I converted to my first commercial backup utility, I ran in this mode for almost a year.

• Only after you've tested and thoroughly documented your new system should you turn off the old method. Remember to keep documentation and programs around to restore data from the old system until all the old volumes have been recycled into the new system.

• Also consider your older backup volumes. If you have volumes that are five years old, are you going to be able to read them on a new vendor's backup solution? Will you even be able to read them in version 14 of your current software if your company began writing the archive volumes in version 2? Will the media itself even be readable?

• This gets into a whole other subject: media life. Even if you could still theoretically read the volumes 12 versions later, the volumes are probably bad. If you have long-term archives, you need to make fresh copies of them at some set interval by copying older tapes to newer tapes.