How to write a Backup&Restore tool

On Fri, 16 Jun 2006 01:09:10 -0700, Canopus

I show one method for making a "snapshot" backup of a known set of files below.

The general idea for backing up incrementally: 1. List files within file set being backed up. (save to a file, today's list) 2. Compare files in current set with previous set (today's list vs. yesterday's list). The comparison should generate 4 reports:

report 1: files which are exactly the same report 2: files which have been changed in new list report 3: files which have been deleted from new list report 4: files which have been added to new list

3. Use reports to backup; you want to select files in report two and report four for backup. buttuming you have copied file names from those reports, then you can backup with either zip or tar.

3.a. Zip

$ SRC=-mnt-somemnt $ ZF=~-backups-2006-06-14.zip $ SEL=~-backups-2006-06-14.sel

3.b. Tar

$ SRC=-mnt-somemnt $ TF=~-backups-2006-06-14.tgz $ SEL=~-backups-2006-06-14.sel

4. Write zip or tar backup to optical media for long term archiving. Before writing zip file to archive, consider combining with other earlier backups to ease restoration problem. Before writing any backup file, consider applying encryption if you are worried about the data being lost or stolen.

Final notes: 1. zip files have some advantages over tar files. One big advantage is the ability to move files between archives without recompressing (using special tools). zip files also have a size limit of 2G, which will likely affect your backups. But if you generate less than 2G of new files per day, then perhaps the zip format could work for making daily incremental backups. 2. Use names for your backup files which sort nicely. I prefer names like shown: 2006-05-31.zip 3. The 4 reports necessary in step 2 are generated by a script called comm2.scr. If you are interested in the bash listing, then let me know. I use that script to compare file lists which include the file name, the file size, and the file time (using the time format, seconds since Jan 1, 1970). 4. It is a good idea to design a procedure which is completely scripted (to avoid simple mistakes, etc.) Once your procedure is completely scripted, then it is ready to be scheduled in advance using the "at" command. The final step of writing to another media (optical or external disc) is not totally automatic; therefore, not part of the script.

-- Douglas Mayne