The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

Поиск:  Каталог документации

4. Creating the Stage 1 Back Up

Having made your production backups, you need to preserve your partition information so that you can rebuild your partitions.

The script make.fdisk scans a hard drive for partition information, and saves it in three files. The first is an executable script, called make.dev.x (where "x" is the name of the device file, e.g. hda). Second is mount.dev.x, which creates mount points and mounts the newly created partitions on them. The last, dev.x, is the commands necessary for fdisk to build the partitions. You specify which hard drive you want to build scripts for (and thus the file names) by naming the associated device file as the argument to make.fdisk. For example, on a typical IDE system,

bash# make.fdisk /dev/hda

spits out the scripts make.dev.hda, mount.dev.hda and the input file for fdisk, dev.hda.

In addition, if make.fdisk encounters a FAT partition, it preserves the partition's boot sector in a file named dev.xy, where x is the drive's device name (e.g. sdc, hda) and y is the partition number. The boot sector is the first sector, 512 bytes, of the partition. This sector is restored at the same time the partitions are rebuilt, in the script make.dev.hda

Fortunately, the price of hard drives is plummeting almost as fast as the public's trust in politicians after an election. So it is good that the output files are text, and allow hand editing. Right now, that's the only way to rebuild on a larger replacement drive. (See the To Do list.)

Other metadata are preserved in the script save.metadata. The script saves the partition information in the file fdisk.hda in the root of the ZIP disk. It is a good idea to print this file and your /etc/fstab so that you have hard copy should you ever have to restore the partition data manually. You can save a tree by toggling between two virtual consoles, running fdisk in one and catting /etc/fstab or /fdisk.hda as needed. However, doing so is error prone.

You will also want to preserve files relevant to your restoration method. For example, if you use nfs to save your data, you will need to preserve hosts.allow, hosts.deny, exports, etc. Also, if you are using any network-backed restoration process, such as Amanda or Quick Restore, you will need to preserve networking files like HOSTNAME, hosts, etc. and the relevant software tree.

The simplest way to handle these and similar questions is to preserve the entire etc directory.

There is no way a 100 MB ZIP drive is going to hold a server installation of a modern distribution of Linux. We have to be much more selective than simply preserving the whole kazoo. What files do we need?

To determine the directories needed at boot, we look at the boot initialization file /etc/rc.sysinit. It sets its own path like so:

PATH=/bin:/sbin:/usr/bin:/usr/sbin
export PATH

Trial and error indicated that we needed some other directories as well, such as /dev. In Linux, you can't do much without device files.

In reading the script save.metadata, note that we aren't necessarily saving files that are called with absolute paths.

We may require several iterations of back up, test the bare metal restore, re-install from CD and try again, before we have a working backup script. While I worked on this HOWTO, I made five such iterations before I had a successful restoration. That is one reason why it is essential to use scripts whenever possible. Test thoroughly!

One thing you can do on an RPM based system is use the rpm program to determine which files are where. For example, to get a complete list of the files used by the openssh package, run:

bash# rpm -ql openssh

There are somethings you don't need. like the man pages. You can inspect each one and decide whether to back it up or not.

4.1. Theme And Variations

4.1.1. No ZIP drive

This backup process requires you to have the ZIP disk drive present at each backup. You could, given a large enough hard drive, create the ZIP disk's contents in a directory, and back that up over the net. Then you only need to build a ZIP disk (with cp -rp) on the backup server when you need to restore.

The backup process will be faster, but you should check that the resulting directory will fit on your ZIP disk (with du -hs $target.zip)! You will have to edit the definition of the variable zip in save.metadata.

My laptop has problems running both a network card and a ZIP drive, so this is the process I use to back it up.

Alternatively, you could build several ZIP disks' worth of backup on the hard drive, and feed them to the system on restore.

4.1.2. Multiple ZIP disks

By splitting up the two first stage scripts, restore.metadata and save.metadata, you could spread the first stage metadata across multiple ZIP disks.

4.1.3. Excluding From First Stage Saving

There are time when you need to squeeze a few megabytes from the first stage data, expecially when you are pushing the limit of your ZIP disk. The function crunch in the script save.metadata takes multiple parameters to feed to tar. It can also take the --exclude parameter. So, for example, you can exclude emacs and gs like so:

crunch etc etc --exclude etc/samba --exclude X11

Why those two? Because they're hard drive space hogs and we don't need them at boot time.

How to find good candidates for exclusion? List the target directories with ls -alSr for individual files, and du | sort -n for directories.

4.1.4. Initrd

If your system uses an initial RAM disk, or initrd, to boot, make sure that save.metadata creates the directory /initrd. The easiest way to do this is to ensure that it is included in the list of directories used in the directory creating loop toward the end.

Your system will probably use an initrd if it boots from a SCSI drive or has root on an ext3fs partition. Check /etc/lilo.conf to see if it calls for one.


  Закладки на сайте
  Проследить за страницей
Created 1996-2018 by Maxim Chirkov  
ДобавитьПоддержатьВебмастеруГИД  
Hosting by Ihor