|
|
||
A Backup Strategy© Copyright Darrell Anderson. (Written Summer 2008) I tend to tweak a lot with my computers. The thought of losing files or data is uncomfortable. Therefore backups are important to me and I backup often. I have had a backup strategy of one kind or another going back to the 1980s. Of course, back then I could backup my data files to a handful of floppy disks. For many years I have used an external hard drive to perform my backups. With my old NT4 box, I used a drive bay through which I connected my backup disk. Being IDE, I had to reboot the box in order for the operating system to see the drive, but that was a minor inconvenience weighed against the many advantages. Being Windows, I had nothing fancy with respect to scripting. My scripts merely backed up files to my external drive. I maintained about four months worth of full backups on that one drive. I always stored that drive in a small fireproof safe. In between I performed differential backups using a second external drive. The strategy worked well for me and through the years. On occasion I had to restore files I mistakenly deleted. These days I’m using Slackware 12.1 on a spiffy new box. I have two internal hard drives installed. My primary is a 40 GB Seagate Barracuda IV IDE drive. My secondary is a 320 GB Western Digital WD3200AAKS SATA drive. The 40 GB drive houses my operating system partitions and files. The larger drive is for storing software builds, virtual disks, my Slackware current tree, and ISO images from all of the computer CDs and DVDs I own. Only a year or two ago I never dreamed of having so much storage. The old adage is true that a person tends to fill whatever storage space provided. To think my first hard drive in the 1980s was only 10 MB! On my second drive I also have a large partition where I regularly backup important files using rsnapshot. The rsnapshot backup tool is ideal for my needs and I won’t explain the utility here. There is plenty of related information available on the web. With this internal backup plan, I run 8 hourly, 7 daily, 4 weekly and 12 monthly backups. With these backups I focus on user home directories, shared data file directories, VirtualBox configuration files, my installed packages list, and system and user configuration files. With rsnapshot I save significant storage space and yet always have all important files backed up. Ignoring major catastrophes such as fire or theft, I would only lose changes I make within the last three hours. I automate the internal backups with cron. Because the internal backup drive is physically different from my primary drive but always readily available, I significantly reduced restoration times should I botch a tweaking exercise. Yes, occasionally I botch things with my experimentation. Further, because the backups are to a different drive, I am not impacting performance on my primary drive. Understand that this internal backup strategy does not protect me from a major catastrophe such as fire or theft because the backup drive is located internally in my case. However, my primary focus with this particular scheme is protecting my system from me. Because of the amount of tinkering I perform, I want a quick means of restoring important files. In addition to this internal backup plan, weekly I run a manual full backup using a slightly different rsnapshot configuration file. I seldom forget to perform this backup, but I have a KAlarm reminder to help me remember. With my old strategy under Windows, I performed a full backup monthly. With the significant space savings provided by rsnapshot, I modified that plan to weekly. My external backup drive for full backups is another Western Digital, but this one is a 750 GB WD7500AAKS SATA drive. I have a SATA drive bay that I slide the drive into, and two shell scripts that I run manually to rescan the scsi bus, mount, and perform the backup. The primary focus for the weekly full backups is the hopefully never-needed bare metal restoration. Overall, this dual strategy works for me. There remains some risk. In the event of fire or theft I would lose a week’s worth of changes on my box but no more because my weekly full backups are stored in a small fireproof safe outside the office. I could lose up to three hours of work in the event of other local failures. How well does this strategy work? About a month ago from when I am writing this, I inadvertently deleted several directories, including my /etc directory (I remain uncertain how this happened.) I shutdown with the kernel keyboard Alt-SysRq sequence. I rebooted with my System Rescue CD. I manually mounted my local system partitions and my full backup disk. I restored all system files. I then manually mounted my second internal disk and restored all of my configuration files from the last hourly snapshot. I rebooted. I lost about an hour of my time, but gained valuable experience with my new rsnapshot backup strategy and restoring files. The most important element of any backup strategy proved successful — the ability to recover and restore files. As a side note, I also have two mirrored installations that indirectly provide recovery support. One installation is on my primary disk. I have a separate set of partitions mirroring my operating system. I only boot into that location when I botch something that prevents or discourages me from booting into my normal installation. That installation mirror is not always exactly current with my primary installation, but nonetheless allows me an alternate means of booting into my system and inspecting my primary partitions. My second mirror is on my second internal drive. I use that latter location to test the Slackware current branch. The second location is expendable, of course. Another side note is I am a firm believer in using partitions as a safeguard against failures and human error. Dividing an operating system into partitions cannot prevent or cure hardware failures, but dramatically helps against various human errors. Users should seriously consider at least a separate /home partition where they store the bulk of their data files. Not only does a healthy partition scheme help avoid human errors, but can help toward reducing backup times and reinstallations. In a worst case scenario, rebuilding an operating system from the installation disks is a straightforward exercise. Restoring data files is not so easy. Storing files in a separate partition allows users to bypass that one file system during the reinstallation. Before I went full scale with this backup plan, I ran rsnapshot manually several times using a smaller sample size to get the feel of how rsnapshot functions. A few passes showed me how rsnapshot worked and then I was comfortable with going live with my new backup strategy. After initially editing my rsnapshot configuration file, I fine-tuned my backup and exclusion points over the next many weeks. Before going live with my internal backup strategy, I performed a manual backup to my external drive. I had a script from my previous old test box that basically performs a big copy using the cp command. Nothing fancy but that at least provided me some baseline protection. For several weeks I ran my new box with only the internal backup plan. Through that period I tinkered with ideas and eventually wrote two shell scripts to perform my weekly manual backup to the external drive. This backup strategy is not difficult to apply. This same strategy could be used on a single drive but using separate partitions. The first backup would require some time and much disk head movement, but each subsequent backup, even to the same drive but on a separate partition, would be much, much faster because of the way rsnapshot only creates hard links to files that have not changed. This reduces wear and tear on hard drives. Still, even with a single drive this strategy would provide a quick way to restore essential configuration files. Another option would be to use a USB flash drive or a CD/DVD to perform the hourly/daily backups. Most older boxes do not have a USB port on the front of the box, but a simple USB extender cord could connect a newer external USB hard drive or USB flash drive to the back of any computer with a USB port. Doing so would allow a person to perform full backups to those external drives much in the same manner as described here. I never have had to perform a complete bare metal restoration, but I once had a hard drive fail on me that required me to rebuild my operating system. The drive failed utterly, as swapping the controller card did not help — some sort of electrical surge went straight through to the platter. With my previous full monthly backup I restored about 80% of what I lost and with my memory I restored another 10% with respect to recent tweaks I had performed. In all, not bad, and I was glad I was rather methodical about backups. Yet I learned my lesson and realized I still lost about 10% of my work. If I had a second drive then as I do now, I easily would have restored 100%. Of course, any backup strategy requires diligence. Each person must weigh the risks versus benefits of any backup strategy they evaluate, but thereafter only determination will see the strategy succeed. Just how important are your data files? The answer to that question should provide sufficient motivation to employ any backup plan. The Nitty Gritty DetailsMy partition and mounting scheme: Primary Drive: /dev/hda10 on / Secondary Drive: /dev/sda1 on /home/public My respective (root) crontab entries for my hourly/daily backups: # Run hourly rsnapshot backup at 52 minutes after the hour: Comments: My hourly/daily backups are stored at /home/public/archives/Backups. Notice from my mounting scheme that this location is on my second drive. My weekly external backup drive is mounted at /mnt/backups. This is a temporary mount point on my primary drive. The drive, of course, and the file system, remains external to my system. In either case, backups are quick because of the nature of rsnapshot creating hard links for unchanged files, rsync backing up only the differences between files, and two separate hard drives. I run two scripts to perform my weekly manual backup. The second script can be run manually and also is called at the end of the first script. That second script allows me to unmount and remove the drive from the scsci scan list. Because the two scripts can be run independently, I store two important variables in a functions container script located in my /etc directory. Notice too that I maintain a separate partition for my /usr/local files. There I maintain all of my personal scripts and configuration files. Caveat: The rsnapshot package is not included with the stock Slackware. You can build and install the package from Slackbuilds.org. Caveat: In my rmbackup script I call the rescan-scsi-bus script, which is installed in the stock Slackware from the a/sysvinit-scripts package. The stock rescan-scsi-bus script will fail to remove devices from the lsscsi scan list unless the sg3_utils package is installed. You can build and install the sg3_utils package from www.slacky.eu. Files included: /usr/local/sbin/backup_rsnapshot I welcome any improvements to this strategy and the associated scripts. Finis. |
||