Good Backup (The basics)

Backup Blues

 

Tonight, I extol the virtue of good backups. It is not for me to say how frequently you should take a backup – that is your risk to assess. What I can say is that I believe that backups should meet a certain criteria to be considered a valid backup. I find it desperately lacking how the holistic view is missed by most backup admins who fail to consider the sum of the following as the minimum criteria for success:-

1. Was the data in a suitable state for backup prior to the backup taking place?
2. Did the backup start on-time as scheduled?
3. Did the backup complete without error within it’s defined backup window? e.g. did it finish on-time?
4. Did the backup drop any files? See dropped files
5. Did the post-backup processes (if required) succeed?

Any failure of this 5-point plan constitutes a backup failure.

Only a backup which fulfills this criteria in full can be considered a good backup.

 

Dropped Files

 

All dropped files should be investigated and excluded if not required for a successful DR in order to not encourage a culture of accepting the failure of dropped files – excluding files not required for DR also improve the backup times because excluding temporary or re-constructable data means that there is less critical data to back-up.

This is an iterative process which should tend to zero dropped files as sources of temporary files are identified.

Some files may require that the backup is run at a different scheduled time or it may require that an application based scheduled task is moved to a different time outside of the backup window if the data cannot be quiesced.