Design Guidelines

Here are some guidelines I used when writing these scripts.

Use tools already available on the target operating systems. Don't require installation of other tools. The Microsoft Windows XP version of these scripts is written for cmd.exe. The backup application is ntbackup.exe. The Unix version is written for bash. The backup application is tar. The bash script used to generate the RSS feed uses xsltproc to transform the results of each backup procedure into an RSS item. I've chosen to use PowerShell to transform the results for Microsoft Windows users. I did this, in part, to demonstrate how easy it is to utilize the .NET framework with PowerShell. If you do not wish to use PowerShell and .NET, you could write a cmd.exe script that uses an external XSLT processor like msxsl.

Provide enough information so you can modify these scripts to fit your needs.

Provide a test mode that produces the XML output but does not run the commands associated with the steps.

The inclusion of the checkpoint restore and test steps contradicts this guideline. The checkpoint restore and test results are logged but the backup is done even if these steps fail. These steps could be moved to separate scripts because their results are not needed here. This move would enable off–line restore and test. I've put these steps here because they are relatively fast and simple and I really want this information. Perhaps these steps will be split off in a later version of these scripts.

Keep the scripts as simple as possible. Defer non–essential tasks to downstream tools which could be run on a system other than the server (perhaps using a different tool set).

Keep the scripts structurally similar so parallel changes can be made more easily. This screenshot shows portions of the Microsoft Windows script on the left and the Unix script on the right.

Backup Procedure source comparison

The XML output structure also reflects the structure of the scripts. For example:

Backup Procedure XML multiple step example

Don't vary XML output. As suggested in the preceding screenshots, the dates and times are saved in the same format on both platforms.

Insure integrity of the configuration by deriving as much information as possible from that already supplied in the environment. The Perforce client settings are used specify the Perforce server port. From this, the server root directory, current checkpoint number and depot versioned file tree locations are obtained from the output of the p4 info, p4 counter and p4 depots commands.

Gather useful data as we go. File sizes and start and end times are saved in the XML log file. Full verification output is saved (the –q switch is not used) so that we can extract the most information. I want to make the most of running this command since it is one of the longer running commands in the script.