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.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Build a Skype Server for Your Home Phone System
- Tech Tip: Really Simple HTTP Server with Python
- Why Python?
- A Topic for Discussion - Open Source Feature-Richness?
- Not free anymore
3 hours 1 min ago
6 hours 48 min ago
- Reply to comment | Linux Journal
6 hours 56 min ago
- Understanding the Linux Kernel
9 hours 11 min ago
11 hours 41 min ago
- Kernel Problem
21 hours 44 min ago
- BASH script to log IPs on public web server
1 day 2 hours ago
1 day 5 hours ago
- Reply to comment | Linux Journal
1 day 6 hours ago
- All the articles you talked
1 day 8 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?