Preparing for the Worst: Backups and Mirrors


No matter how many precautions you take, or no matter how much of a veteran you are, your system will be hacked, your hardware will fail, or something else will happen that will make your data unusable and recovery impossible. It's all but inevitable. The only defense against this is to have the tools available for a complete rebuild from the ground up. Prepare for the worst, says one of the corollaries to Murphy's Law, and the worst will never happen. If precautions are the price we pay for safety, so be it.

Creating "Seed" Files

One way you can ensure that your custom configuration will survive a catastrophic failure is to gather together a collection of "seed" files, which you can use to customize a new system that you build from scratch. These files can be preserved offline by burning them onto a CD or, in the absence of writable optical media, a floppy disk (remember, however, that floppies can be damaged and will deteriorate with time, so you need to make multiple copies and keep them fresh):

  • /etc/rc.conf The main system configuration file.

  • /etc/master.passwd The master user database. All other user databases can be generated from this one.

  • /etc/mail/freebsd.mc The Sendmail "master config" file if you have a custom Sendmail configuration. (The filename may vary according to what you have named it.)

  • /etc/fstab Important for re-creating your disk structure.

  • /usr/local/etc/* Individual config files for all the programs you've installed (the well-behaved ones, at any rate).

  • /etc/vinum.conf Your Vinum setup configuration script, if you're using Vinum (discussed in Chapter 20).

Tip

If you're in a hurry, you can simply archive your /etc and /usr/local/etc directories into tarballs and back those up, rather than picking the crucial bits out of each one. However, archiving only the bare essentials can make migrating to a new machine easier if you have to restore your system on a newly installed system whose /etc architecture is different from the one on your existing system.


These are the most critical filesthe ones that define your system and give it its identity. All told, they won't come to more than a few hundred kilobytes; those few hundred kilobytes can save you weeks of painful tuning and trial and error when rebuilding your system.

You may even want to package these files together into a tarball and mail it to yourself (at an account not on your FreeBSD machine) on a daily basis. Here's a sample command to accomplish this:

[View full width]

# tar cvfz - /etc/rc.conf /etc/master.passwd /etc/fstab /usr/local/etc | uuencode seedfiles.tar.gz | mail -s "Seed Files" me@myaccount.com


You can put this into a shell script in /etc/periodic/daily or into root's crontab file, as you prefer.

Backups

The importance of backups can hardly be overstated. Any system administrator will tell you this. Yet, it's also no secret that doing regular backups is tedious, annoying, and expensive. Many administrators will wax lyrical about how imperative it is to have a backup scheme in place while not actually having one to wax lyrical about.

At the very least, you should become familiar with the various options for doing backups. That way, if you aren't using a backup solution, it won't be because you don't know how.

Many enterprises have a standardized backup procedure for safeguarding their data, whether it's stored on Windows, UNIX, or Linux servers. This procedure can involve a central tape carousel and controller software running on a central server as well as client endpoints to that controller running on all the other machines to be backed up. The carousel controller collects data over the network from all the subscribed servers and writes tapes. The tapes can then be stored offsite so as to protect the data in the event of a fire or other catastrophic event that would render multiple onsite backups or mirrors irrelevant.

The software for these kinds of solutions is often geared toward high-end commercial platforms, and it's a rare case when a native FreeBSD client endpoint is available. Fortunately, though, many makers of such software are writing versions of their endpoints for Linux, and because FreeBSD has Linux binary compatibility, you may be able to get away with simply using the Linux software. For instance, the Legato client for Linux runs on FreeBSD, in most cases (although not without the occasional unpredictable behavior).

Tip

Linux software is often distributed in "RPM" format, which is used by the Red Hat Package Manager. As we've discussed before, the rpm utility is available for FreeBSD (in /usr/ports/archivers/rpm), but its use has some pitfalls. For instance, you might need to use non-standard flags on the command line. The flag -nodeps enables rpm to ignore missing dependencies that it expects to have in its own package database. The flag --prefix=/usr/local lets rpm put binaries into the standard FreeBSD location instead of /usr. The flag --ignoreos lets rpm ignore the fact that it's not Linux you're installing on.


In the case of Legato, native versions of the endpoint software are provided by an independent software company as part of an agreement to furnish unsupported versions of the software for platforms that Legato does not explicitly support, including FreeBSD. These packages are available in the ports at /usr/ports/sysutils/nwclient and /usr/ports/sysutils/nwclient602. These might work if the Linux version fails.

More of these specialized backup solutions are available every day, and it is becoming easier to find a commercial package that will work well with FreeBSD. However, in the event that no such option is available, you can turn to the standard venerable UNIX backup/restore tools for the backup basics.

Using dump

The built-in UNIX utility dump is the good-old standby backup method. It operates based on dump levels specified in /etc/fstab (as you saw in "Understanding the /etc/fstab File," in Chapter 12). The dump levels enable a fine-grained "delta dump" system, in which you can do one complete dump at the beginning of a backup period (for instance, a week) and then subsequently dump only new or changed files each day, thus saving tape space and backup time.

Note

Be aware that FreeBSD's support for dump and restore is filesystem-specific and only guaranteed to work on native UFS filesystems; if you're using non-native filesystems such as Ext3FS or MSDOSFS, dump and restore are not likely to work properly.


You'll need a drive to use as the backup device. You can use a tape drive (/dev/rsa0, the default), an external hard drive, or any device that can be mounted and written to during normal operations. SCSI has always been the interface of choice for backup devices such as tape drives, because of the speed and robustness of the interface and the general quality of the components. You'll need a SCSI controller for this, which will hike up the price a bit. Alternatively, you can wait until the now-popular FireWire (IEEE 1394) devices have become fully supported by FreeBSD and then use one of those (if you're lucky, it will work already). IDE/ATAPI tape drives are also available. However, make sure FreeBSD supports the tape drive you like before you buy it! The device need not be mounted for the dump operation to workit will write directly to the device specified.

The following command executes a baseline backup, a complete dump of the /home filesystem:

# dump -0u -f /dev/nrsa0 /home


The 0 option (which is a zero, not the letter O) means to perform a level-0 dump (back up everything, regardless of whether it needs to be backed up or not), and the u option tells dump to update the /etc/dumpdates file, a human-readable data file that dump reads to figure out whether incremental dumps need to back up certain files.

Note

The nrsa0 device is the same as rsa0, except it specifies a "nonrewinding" devicea confusing syntax, certainly, but it has the undeniably useful effect of telling the tape drive not to rewind when it's done. Tape drives, particularly SCSI ones, use this convention to tell dump how to handle the tape, as shown in Table 21.4.

Table 21.4. Device Meta-Names as Control Options

Device Meta-Name

Effect

/dev/sa0

The actual device name

/dev/rsa0

Tells dump to rewind the tape when it's done

/dev/nrsa0

Tells dump not to rewind the tape when it's done

/dev/ersa0

Tells dump to eject the tape when it's done


This is useful for when you're doing batch backups; specifying the nonrewinding tape device prevents it from rewinding after the first operation and overwriting the just-completed backup.


After your initial level-0 dump is done, you can do incremental dumps with the same syntax, but a higher dump level number:

# dump -1u -f /dev/nrsa0 /home


The dump levels work by dumping only the files that have changed since the last dump of any lower level. Therefore, if you do a level-3 dump and then a level-4 dump later, the level-4 dump will dump only files that have changed since the level-3 dump. If you then do a level-2 dump, everything backed up with the level-3 and level-4 dumps will be backed up again. The lower the dump level, the more backups will be "forced." Level 0 is the "ultimate" backup, dumping everything regardless of previous dump states.

The typical procedure is to do a level-0 dump at the outset and then a level-1 dump at the beginning of each week, using a different tape (or set of tapes) for each week. Each subsequent day, a higher-level dump is done, often in the staggered "Tower of Hanoi" sequence suggested in the man dump page.

Recovery

When it omes time to recover your backed-up data, you'll be using the restore utility. This can be used either in interactive or noninteractive mode. Interactive mode is helpful for specifying a particular set of files to restorefor instance, if you've accidentally deleted a file and you need it back. First, change to the directory (using cd) where you want to extract the file and then enter the interactive restore program:

# restore -if /dev/nrsa0


Within this program, you have a number of commands available to you: cd, ls, pwd, add, and delete, among others. These commands allow you to navigate among the files in the tape's backed-up directory structure, view them, and add them to a list (with the add command). You can remove files from the list (but not from the tape or disk) with the delete command. The exTRact command restores from the tape any files in the list at the time you issue it. Full syntax for each of the interactive restore commands can be found in the man restore page.

The following two commands add the directory called frank to the extraction list and then extract it from the tape back onto the disk:

restore> add frank restore> extract


Alternatively, you can simply restore everything from a tape's backup session with a noninteractive command line using the following options:

# restore -rf /dev/nrsa0


A tape often will have multiple sessions of backup data on itmultiple days' worth, for example. A single tape might have a week's worth of backups, beginning with a full backup followed by six incremental backups. If you want a file from a particular day's backup, you will need to position the tape to extract from that session. The tool that does this is mt, the "magnetic tape" manipulation utility.

When you first insert a tape into the drive, it is generally rewound automatically to the beginning. To wind it forward to the third session, use the fsf (fast forward) option with mt:

# mt -f /dev/nrsa0 fsf 2


Here, fsf 2 tells mt to fast-forward two sessions, putting it at the beginning of the third session. To move back to the second session, rewind the tape to the beginning (also using mt) and then fast-forward it again:

# mt -f /dev/nrsa0 rewind # mt -f /dev/nrsa0 fsf 1


There are a great many more details to the dump and restore procedures that need not be fully covered here. Using the -s option with restore in noninteractive mode to specify a certain backup session on the tape is one such procedure. Others include advanced usage of the mt utility, managing multiple tapes, remote backup devices, and so on. A good tutorial on dump and restore that covers these procedures can be found at http://www.nethamilton.net/dump.html. Also, read the man pages on dump, restore, and mt for documentation of all the capabilities of these tools.

Mirrors

Backups are certainly daunting, aren't they? It's a small wonder that few people actually have the patience to do them. They do require a budgetary and time consideration appropriate to a small business at the least; a personal hobbyist system might find it difficult to justify the investment and aggravation. Fortunately, there's an alternative.

For just a little more money than it would take to set up a full-fledged tape backup system, you can instead create a mirror servera second FreeBSD machine whose only purpose is to synchronize its files with the main server on a daily basis. You can swap those files into place should anything happen to the main server, or swap the entire mirror server into the failed main server's place. And the tool you use to do the mirroring? You guessed it: CVSup.

Ideally, your secondary server should be in a physically different location from the main server, so that your data is protected even in the event of a fire, flood, or burglary. CVSup's incremental backup system makes it possible to do this even if the bandwidth available between the two systems is very limited.

Setting Up a CVSup Mirroring Solution

Let's say you want to mirror four directory structures: /home, /usr/local/www, /var/mail, and /etc. (You may well want to do more than just these in your situation, but these will suffice for this example.) The first step is to set up a base directorya staging area on the main server where the configurations of the source data trees are stored. The base directory lets cvsupd (which is installed in /usr/local/sbin as part of the cvsup port or package, which you should already have installed) know what collections to serve to clients, such as your mirror machine.

Enter the following commands as root:

# cd /usr/local/etc # mkdir -p cvsup/sup # cd cvsup/sup # mkdir home www mail etc


Now, in each of these four new subdirectories, you need to create two files: the .cvs file and the releases file. These files describe a "collection" to the cvsupd server and enable it to be served. In the home subdirectory, create a file called home.cvs with the following contents:

upgrade home rsymlink *


Next, create a file called releases with the following contents:

home list=home.cvs prefix=/


Do this for each of the four subdirectories, changing the name of the .cvs file to match the name of the directory or collection as well as altering the contents accordingly (www.cvs, mail.cvs, and so on).

Running the cvsupd Server

When you have set up the base directory, you can start up the cvsupd server. The C option limits the number of simultaneous clients to 1, and l (the lowercase letter L) specifies where to send logging information:

# cvsupd -b /usr/local/etc/cvsup -C 1 -l /dev/stdout &


Now you're done with the main server, so you can move on to the secondary server, the one that will act as a client to the CVSup server you've just set up.

Create a file in /etc called mirror-supfile (or anything you like). The contents should be as shown in Listing 21.2, in which server1.example.com should be replaced with the hostname of your main server, from which you will be mirroring content. You can use simple hostnames, fully qualified domain names, or IP addresses for the host parameter.

Listing 21.2. Example CVSup Configuration File (mirror-supfile)

*default host=server1.example.com *default delete use-rel-suffix *default compress *default preserve *default base=/usr *default release=home home *default base=/usr/local *default release=www www *default base=/var *default release=mail mail *default base=/usr *default release=etc etc

Notice the final entry: It's not /etc that you're mirroring the main server's /etc into but rather /usr/etc. The reasons for this is that /etc is unique to each machine, where it is customized for that machine specifically; you want to mirror /etc into a safe and inactive location, rather than overwriting your secondary server's /etc with that of the main server. In any case, this is a good excuse to demonstrate the flexibility of CVSup, showing how you can "check out" a collection of files into any location on the second server.

Running the CVSup Mirroring Process

After the mirror-supfile is created, you're ready to do your first mirroring operation. Start up the CVSup process:

# cvsup -L 2 /etc/mirror-supfile


You'll be flooded with output, telling you exactly what is being transferred and how. You can use Ctrl+C to break out at any timeCVSup will exit cleanly and pick up where it left off the next time through. This first transfer process will take a very long timeas long as it takes to transfer all the specified data from one server to the other via any other means. It's the subsequent processes that will be fast and efficient.

After your /usr/etc has been transferred, you can copy the master.passwd file out of it and use pwd_mkdb, as you saw earlier in the "Migrating from Linux" section, to synchronize your users (this is relevant even if you don't use Linux). You may choose to do this as a daily automated task if you have a lot of users or add them regularly; CVSup will skip any file that it can determine has the same checksum and the same ownership information.

Note

The ownership information won't be the same if the users on one system don't match the ones on the other! If a file is owned by a user that doesn't exist on the secondary system, CVSup will "rsync" it every time the mirror process is run, which doesn't take anywhere near as long as transferring the entire file, but it takes much longer than simply skipping the file. Keeping the user database synchronized, and allowing CVSup to skip files whose information matches completely, can speed up the mirroring process from 4 or 5 hours down to about 15 minutes.


After the mirroring process is working smoothly each time you run it, you can add it to your /etc/periodic/daily or root's crontab, whichever you prefer. You'll get the verbose output mailed to you each night for your edification. Reduce the -L level if you want to see less output.

You can create more file collections on the server side if you want; just make more directories in /usr/local/etc/cvsup/sup and add them to mirror-supfile. You don't need to restart the cvsupd processit will pick up the new collections automatically each time a client process connects.

Note

Mirroring isn't a complete alternative to incremental backups. It's a solution for an administrator who doesn't need historical auditing, revision control, or offsite backup archives. Put simply, it isn't a perfect solution for a business using FreeBSD as its server platform. Mirroring provides a quick-and-easy solution to a sudden catastrophic failure. For business use, you really can't beat tape backups, tedious as they are.





FreeBSD 6 Unleashed
FreeBSD 6 Unleashed
ISBN: 0672328755
EAN: 2147483647
Year: 2006
Pages: 355
Authors: Brian Tiemann

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net