13.4. Backup Policy

13.4. Backup Policy

The backup speed and the extent, to which the data will be restored, depend on how you perform the backup. If your data take hundreds of gigabytes of disk space, it will take a long time to back them all up; moreover, this will put a great workload on the server. If backup copying is carried out over the networks, it will also load the network's bandwidth, reducing the server's availability for other clients .

Your task is to organize the most effective backup procedure, one that takes the minimum amount of time and preserves all necessary data.

When planning the backup process, you should keep in mind that in case of a hard drive failure, all changes made since the last backup will be lost. This means that especially important data should be backed up as often as possible, but remembering that this process is burdensome for the server.

The answers to the questions of how many media you will need for backup purposes, how often, and how to use them depends on many factors, including the following:

  • The amount of information to be backed up

  • How often this information is modified

  • Whether it is possible to restore large amounts of the lost data manually

  • How long the server can be down

  • Which data are modified most often

This list can be continued , but the items given here will suffice. I'll consider them starting with the last one. You should have a clear idea of which data in the system are modified and how often. Group these data into three categories: rarely modified, frequently modified, and those modified at certain time intervals.

The following are the main directories that should be backed up:

  • /etc Contains configuration files

  • /home Contains user files

  • Directories containing Web files

Other directories are seldom used to store documents or files. It makes no sense to back up programs from the /bin and /usr directories, because they can be easily installed anew, especially if the configuration has been saved.

13.4.1. Rarely Modified Data

Configurations files (those stored in the /etc directory) can be placed into the rarely-modified data category. They are rarely modified because in most servers the main and the most extensive configuration changes take place at the server installation stage. Afterwards, the server can work for years with the configuration changing only when the software is updated or corrections to the configuration are made.

To back up the configuration files, a slow, small rewritable medium will suffice. I use ZIP or Jaz disks to back up the configuration files, which takes only one diskette.

Because the configuration does not change often, modified files can be saved right away. Only the modified files have to be saved to the disk.

The restoration process should start with restoring the configuration files, with the /etc/passwd and /etc/shadow files being the first on the list. If these files are not restored before the other files, without the necessary users, programs will not be able to set the proper access rights.

This will lead to the rights being restored incorrectly, especially if you are using third-party right-assignment utilities. Before making the restored system available for use, you should ascertain that all files are in the same state they were in before the failure; this especially concerns their permissions.

13.4.2. Frequently Modified Data

Into the frequently modified data category can be placed databases and the main user files and documents (those in the /home directory). Most of these are modified every day. This data can and should be backed up every day. If the backup process takes too long, it should be performed after work hours or during lunch break, when the load on the server is reduced. The backup can be performed using scripts executed as scheduled tasks . Perform backup twice a day (once at lunch time and once after work) so that in case of a disk failure only half a day's worth of data will be lost.

To back up this type of data, I use seven rewritable media, one for each day of the week. Every Monday, data from all of the media is saved to a read-only media, such as a CD-R or DVD-R, and the media is reused for the daily backup.

13.4.3. Periodically Modified Selected Data

Far from all files in the /home directory are changed every day. Most of them may not be changed for years. So as not to waste your time saving these data, you can perform backup using commands that allow only the changed data to be backed up. The simplest way of doing this is to select for backup only those files modified within a certain period.

When this policy is employed, the backup procedure is as follows :

  • At the end of week, the entire /home directory is backed up.

  • Only files that have been modified are included in the daily backups .

In this case, restoring should be carried out in the same order as the backup: First, the weekly backup files are restored, and then each of the daily backups, starting with the oldest. Not following the order carries a risk of rewriting a file with its older version.

Performing backup by the file modification date is convenient but not always possible. Most backup utilities only update an existing copy, replacing the old version of the file with the new one. In this case, first all files are backed up and then the update is specified with a special key. Only files that have been modified are updated in the complete backup in this way.

This is a handy method, but it replaces all old files. This makes it impossible to roll back to the contents before the last backup. To allow rollback, every day the complete backup is updated, it is saved to a separate medium. In this way, the main backup copy reflects the state of updates up to the current date, and its daily copies allow rollback to a specific date.

Because only changed files are backed up every day and few files are modified every day, backup can be performed sufficiently rapidly and even during the regular server operation. But in the latter case, you are running a danger of corrupting files. Suppose that there are two hard-linked files, information in which has to be linked. For example, data written to one file also have to be entered into the other file. If when one file is being backed up another file is changed, the backup of the first file will not reflect the changes. This will cause serious problems after the restoration, because the integrity of the files is disrupted.

13.4.4. Other Periodically Modified Data

Data that are modified periodically have to be backed up depending on the frequency of the modifications. For example, some files can be used when monthly reports are prepared. As a rule, such files are quite large and it makes no sense to back them up regularly. It is more effective to back them up when the report-preparing activity is over and to not waste resources on backing up data that do not change.

13.4.5. Image Backup

The most reliable way to back up is to create an image of the entire hard drive. In this case, the information is saved irrespective of the disk's file system, because the file system is bypassed and the tracks are copied directly. Restoring from an image guarantees that all access rights will be restored properly and the system is ready to use right away.

This method, however, has quite a few shortcomings, such as the following:

  • It takes lots of time to create a disk image, especially of large drives .

  • It puts a great workload on the server.

  • It cannot be implemented in Linux, because most distributions do not offer the necessary tools.

  • All files, even those that are not necessary, are backed up, such as files from the /tmp directory.

Disk imaging is convenient to use for moving data to another computer or to replicate the configuration on other computers. For example, you have to set up several client computers with the same configuration. Configure one computer, create an image of its hard drive, and then replicate the image on the hard drives of the other computers. This is more reliable than simply copying files from one computer to another.

13.4.6. Backup Media

Now consider how many media you will need to store all of your backup copies. Each type of data considered previously requires its own media, because they are backed up at different frequencies. These are the following:

  • Configuration files As already mentioned, ZIP or Jaz disks can be used for backing up these data. It is a good idea to make two copies, because all diskettes are easily damaged and fail more often than hard drives.

  • Periodically modified data These backups are stored for a year or longer. I use CD-Rs to back up this type of data. CD-Rs are large enough for my data and cannot be erased accidentally or maliciously. I back up all periodically-changed data every month and keep the medium for a year. In this way, during the year I always have a backup copy of data for any reporting period.

  • Frequently modified data In this case, the decisive factor in choosing the medium is the backup speed, because most often these data are bulky. The backup should take as little time as possible, so as not to put a prolonged extra workload on the server.

As you can see, a backup policy depends on many factors. I have tried to demonstrate the main principles, on which you should base your particular backup policy. These principles may not be equally suitable for all systems, but they can be used as the foundation for a specific backup policy.



Hacker Linux Uncovered
Hacker Linux Uncovered
ISBN: 1931769508
EAN: 2147483647
Year: 2004
Pages: 141

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