172
Networking: A Beginner's Guide
TIP
If your data is extremely critical and not easily reconstructed, you can often perform full
backups every night and also squeeze in a quick incremental backup midday. This way, you can't
lose more than a half day's worth of data.
You can also choose rotation schemes that are simpler than GFS. For instance, you
may use just two or three tapes and then rotate them in sequence, overwriting the old
data each time you do so. This lets you restore any of the previous three days' data. The
shortcoming of this scheme is that you may need to go back further in time to restore
data that was erased or damaged without anyone immediately noticing. You can
combat this problem by using several tapes that you rotate weekly or monthly.
One factor to keep in mind when considering different tape rotation schemes is
the granularity of your backups. Generally, granularity refers to the flexibility that
you retain to recover data from earlier tapes. In the standard GFS scheme, where full
backups are made all the time, you could restore a file from any given day for a week's
time, for any given end of the week (Friday) for a month's time, or for any given month
for a year's time. You could not, however, restore a file that was created three months
ago in the middle of the month and erased (or damaged) before the month was over,
because a clean copy wouldn't exist on any of the backup tapes.
The best advice for choosing a rotation scheme for important data is that unless
there are reasons to do otherwise (as already discussed), use the GFS scheme with full
backups. This maximizes the safety of your data, maximizes your restoration flexibility,
and minimizes the risk of media failure. If other factors force you to choose a different
scheme, use the discussions in this chapter to arrive at the best compromise for your
situation.
Granularity and Data Corruption: A Tricky Balance
One reason to consider granularity carefully is the possibility of data becoming
corrupted and the situation not being noticed. For instance, I once worked with
a database file that had been corrupted several weeks earlier, but had continued
to function and seemed normal. After problems started to develop, however,
the database vendor's technical support staff discovered that a portion of the
database that wasn't regularly used had become lost and wasn't repairable. The
problem was caused by a bad sector on the database's hard disk. The only way
that the support people could recover the database and ensure that it was clean
was to restore backups, going further and further back in time, until they found
a copy of the database that didn't have the damage. They then reentered the
data that had been added since the nondamaged copy was made. Because of the
increasing time span between backups as the support people dug further and
further back in time, the amount of data that we needed to reenter grew rapidly.