The Skinny on Backups and Data Recovery, Part
Welcome once again, one and all, to another installment of Sysadmin's Corner. We start this week by visiting another of those ugly topics no one likes to talk about ... your system backups. In the next few columns, I want to discuss backup strategies, tools, and ways to make the whole process a bit less unpleasant.
You can get pretty much anyone you ask to agree that backups are a good idea. You can also pretty much guarantee that no one does their backups as often as they should. While I won't name names, I've known a number of people over the years who (despite touting the benefits of regular backups) treat their important data with bad habits such as these:
backups are done "occasionally" or "very occasionally"
backups are not verified ("They must be okay, right?")
the backup is put on a single diskette used over and over
the backup is put on a single tape used over and over
backing up to another directory on the same disk
Since there is no point in boring you with a list that goes on and on, I'll stop for now. Suffice to say that when the system crashes and data has to be recovered, it's always "important" data. So, what's the best way to protect that important data?
For a lot of people dealing with simple systems, the data that is our accounts, word processing documents, e-mails, is the only truly important part. In the world of that other operating system, most backups involved copying documents to a diskette. I know of one instance where a user had only a single diskette for all their important documents, because they were worried about the hard disk crashing! True story.
The problem with diskettes is that they hold only so much information. Backing up your whole system would take years (hours, anyway) and require sedation afterwards. Every system should have some kind of large storage capacity backup, like a tape drive. Network backups are possible if the device you need exists on some other machine, but that's a topic of its own.
Okay, I admit there are instances where you don't have a proper backup device and you need solutions. For instance ...
A number of people have taken advantage of Linux's powerful network tools and masquerading (not to mention price) to create simple mail servers and Internet gateways for the company. The company gave you this machine, because nobody else was using it and you told them Linux works for sardines. This machine is an old 486 with a 2-speed CD-ROM and no tape drive. You asked for one, but your insistence that Linux would cost them nothing and give them the world made you break one of the cardinal rules and cut corners on backups.
On this server of yours, you are probably running diald, fetchmail, IP masquerading and e-mail. Not particularly complex, and the data (the e-mail) gets transferred to the user PCs anyway. Not much to worry about there, right? Keep in mind though, that it took you several hours to properly tweak this machine, and to get just the right settings for dialing out and connecting to your ISP. Sure, Linux is stable as can be, but disks crash. You can reinstall Linux from the CD-ROM in minutes, but getting everything just right might take a little longer than that and users want their e-mail and Internet access yesterday.
It's a good idea to have everything, but everything is not always a requirement. Since this type of system is essentially the sum total of its configuration files, you can do what I call an identity backup. This script will collect all the files that make your put-together server unique among all other put-together servers. Here's what it looks like.
#!/bin/bash # # Identity backup for Linux systems # This script does a backup of important files # Marcel Gagne, 2000 # clear echo "Identity backup for Linux systems" echo "2000: Salmar Consulting Inc." echo "" # echo "Please enter a directory name for temporary image storage." echo "ie: /data1/PROTECT" # read PROTECT_dir # ##################################################### # Start by copying config files in etc mkdir -p $PROTECT_dir/etc/rc.d mkdir $PROTECT_dir/root mkdir -p $PROTECT_dir/usr/local/.Admin cd /etc for file_names in passwd group shadow profile bashrc sendmail.cw sendmail.cf hosts hosts.allow hosts.deny named.conf named.boot hosts.lpd diald.conf aliases do cp $file_names $PROTECT_dir/etc done find nsdata -print | cpio -pduvm $PROTECT_dir/etc find ppp -print | cpio -pduvm $PROTECT_dir/etc find sysconfig -print | cpio -pduvm $PROTECT_dir/etc cp rc.d/rc.local $PROTECT_dir/etc/rc.d # cd / cp /root/.fetchmailrc $PROTECT_dir/root find usr/local/.Admin -print | cpio -pduvm $PROTECT_dir/usr
The basics are this. After obtaining a temporary backup directory, I make the structure by creating the directory hierarchy that I want to recreate. (Using the -p flag on mkdir, I can save myself a few keystrokes and create the entire subdirectory I need in one pass.)
I often save little admin scripts to a directory called /usr/local/.Admin as is the case with this one. Consequently, in the script, I make sure to back up that directory as part of my identity backup. If you want to use a different directory, make sure you take this into consideration. After writing the script, I make it script-executable and run it:
# chmod 700 /usr/local/.Admin/identity_backup # /usr/local/.Admin/identity_backup
When the script runs, I give it a directory name on my server. Something I use pretty regularly is /data1/PROTECT or /something/PROTECT but you can use anything that makes sense, making sure, of course, that the filesystem you copy to has enough disk space. What I wind up with here is a kind of configuration "mirror" of my system. I can quickly pull back the files I need from a copy of the structure that originally existed.
This list of backed-up items is by no means complete. I am taking the bare minimum files and configurations to recreate a functional system as quickly as possible, should disaster strike. Now that we have this quick-identity snapshot, what should we do with it? If you created your PROTECT_dir in /data1, you would do the following:
# cd /data1 # tar -czvf hostname.identity.tar PROTECT_dir
This will create a tarred and gzipped file of your system configuration. The next step is to get it off the system and put it somewhere safe. If the file is small enough (as is sometimes the case), you can save it to a floppy. In fact, you could tar the whole thing to a floppy and save yourself a step. Alternatively, you can ftp the file to another server, a Windows PC, or (if you are a sys admin working remotely) to your own server. A few minutes ago, I tested the script as you see it on a remote Linux system that acts as a corporate e-mail/Internet gateway. The resulting file was about 35 kilobytes. You can store an awful lot of those on your own system.
If you wanted to extract this "identity" to your local system, you might do something like this:
# mkdir -p /home/remote_servers/hostname # cd /home/remote_servers/hostname # tar -xzvf hostname.identity.tar.gz
There you have it! A copy of what makes that system unique, but saved someplace other than the server itself.
Warning! This is not an all-encompassing answer to backups. For that, we need to discuss other ways of looking at your system, your data, and how you store it. That is the kind of country where I intend to take this series.
And so, we wrap up another week. Until we chat again, remember that when you're down, only a good backup will get you back up.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- LiveCode Ltd.'s LiveCode