Backup Issues
Backing up is for insurance. Just like other insurance, you hope you
never need it, but when you do, you're very glad it is there. Also
just like other insurance, it is worthless if you don't keep it
current. To be effective, backups must be performed regularly.
If you ask a computer user "Why should you keep backups?" they will normally respond "in case my system fails". Although this is the perceived reason for performing backups, user error, rather than system failure,
is the most common reason to use backups. Before designing a backup
plan you must first answer the question "What do I want
protection from?" The answer to this question, together with the
realization that, just like other insurance, the amount of protection
you receive is proportional to the amount of work or cost you
incur, will help you design a backup plan that is appropriate for you.
Design issues
Designing a good backup plan is the second most important factor in producing good backups. The most important factor is performing the backups consistently.
This seems obvious. However, any idiot can create a backup plan that
will ensure that a recent copy of your data is made. Here's one:
Backup your entire system once each hour, every hour. Save all the backups for a year.
Of course, this is silly. It does not take into account the reasons
that many user's backup plans result in nothing more than plans. In
particular
- backups take time
- backups take space
- performing backups is boring
- not everything needs to be backed up
In addition, most users of modern computer systems expect
problems to occur from time to time. (We will leave financial
institutions out of the discussion here.) They also are willing to
accept some responsibility for their data, and to accept some amount of
risk for it. How much risk they are willing to accept depends on the
application and on the expectations that you, as the system
administrator, have set. If you publish a reasonable backup plan that is
insufficient for their security, they can take additional steps on
their own. In short:
- develop a policy about backups
- inform your users about your policy and be specific about what you are responsible for. Make sure they know what to expect!
- stick to your policy!
When developing a policy, consider the following issues:
- What needs to be backed up?
Even a personal computer these days may
have hundreds of GB of data. (Possibly by the time you read this, it
will be some number of terabytes of data.) Backing up all of this data
is silly. In case of a catastrophic failure you will reinstall your
system. You would then use your backups to restore additional data and
any configuration you performed. In the simplest situation you may want
to limit the data you backup to user data that is kept beneath each
user's home directory.
- How often does the data change?
How much loss can you expect your users
to endure? If you can limit your backups to weekly or even daily
backups the task can be managed. You should always do a better job than
user expect, however. That way you can shine in a crisis, instead of
just meeting expectations. In the role of system administrator,
perception is everything!
- How quickly does the data have to be restored?
The answer to this question affects the
type and format of your backups and where you keep them. An secondary
question may be whether the data may need to be restored to somewhere
else: another system or another directory. This may affect the way your
backups are performed.
- Who performs the backups?
This sounds funny, but it is crucial.
If you can safely entrust this task to someone else, all the better.
Some people enjoy repetitive tasks! System administrators need more of them.
- How sensitive is the data?
Remember, a backup is a copy. Many
types of data are sensitive. If the primary copy of the data has
security concerns, so does the backup. Just think about it: all your
electronic mail may be sitting on a DVD in a computer room somewhere
right next to the station of a computer operator who has very little to
do in the middle of the night.
A few other considerations
- Certain failures such as fire are not limited to your computer. At least periodic backups should be moved off-site.
- Creating a backup is not the end of the
process. You should always perform at least a cursory test to ensure
the backup is valid. (After you create the DVD, can you read it?)
(There is the typical story of the computer operator who performed
backups on the same set of tapes repeatedly for some time. When it came
time to use them, the tape could not be read! "I didn't know that
tape was bad!" is not a comforting comeback in this situation.)
- Write-protect your backups if the media is rewritable.
- Consider making a duplicate copy of your backups, or at least keeping two generations.
- Ensure your backups are marked correctly and legibly and are in a known location so that someone else can find them if need be.
- Always perform your backups when the system is quiet. Open files may not be backed up correctly.
- Create your backups with relative paths if possible to enable them to be restored to another location.
| Preview question:
Design a plan to limit the amount of data you must backup. If
your plan is implemented, consider how easy it would be to recreate
your system after a total loss. How easy is it to recover a single
piece of lost user data? |
| Prev |
This page was made entirely with free software on linux:
Nvu, Kompozer and Openoffice.org |
Next |
Copyright 2008 Greg Boyd - All Rights Reserved.
