you or your business.
Your first step in formulating and learning to use an effective backup strategy
is to choose the strategy that is right for you. First, you must understand some
of the most common (and not-so-common) causes of data loss so that you can
better understand the threats your system faces. Then, you need to assess your
own system, how it is used and by whom, your available hardware and
software resources, and your budget constraints. The following sections look
at each of these issues in detail and provide some backup system examples.
Why Data Loss Occurs
Files may disappear for any number of reasons: They can be lost because
hardware fails and causes data loss; or if your attention wanders, you might
accidentally delete or overwrite a file. Some data loss occurs as a result of
natural disasters and other circumstances beyond your control. A tornado, a
flood, or an earthquake could strike; the water pipes could burst; or the
building could catch on fire. Your data, as well as the hardware, would likely
be destroyed in such a disaster. A disgruntled employee might destroy files or
hardware in an attempt at retribution. Equipment can be stolen, or it might
fail; all equipment fails at some time—most likely when it is extremely
important for it not to fail.
A CASE IN POINT
A recent Harris poll of Fortune 500 executives found that roughly two-
thirds of them had problems with their backup and disaster recovery plans.
How about you?
Data can also be lost because of malfunctions that corrupt the data as it being
written to the disk. Other applications, utilities, and drivers might be poorly
written, buggy (the phrase most often heard today is “still beta quality”), or
might suffer some corruption and fail to correctly write that all-important data
you have just created. If that happened, the contents of your data file would
be indecipherable garbage of no use to anyone.
All these accidents and other disasters offer important reasons for having a
good backup strategy; however, the most frequent cause of data loss is human
error. Who among us has not overwritten a new file with an older version or
unintentionally deleted a needed file? This applies not only to data files, but
also to configuration files and binaries. In mail lists, Usenet newsgroup
postings, and online forums, stories about deleting entire directories such as
/home, /usr, or /lib are all too common. On a stable server that is not
frequently modified or updated, you can choose to mount /usr read-only to