Original work by Lowell Gilbert.
The first requirement in devising a backup plan is to make sure that all of the
following problems are covered:
It is perfectly possible that some systems will be best served by having each of these
problems covered by a completely different technique. Except for strictly personal
systems with very low-value data, it is unlikely that one technique would cover all of
them.
Some of the techniques in the toolbox are:
-
Archives of the whole system, backed up onto permanent media offsite. This actually
provides protection against all of the possible problems listed above, but is slow and
inconvenient to restore from. You can keep copies of the backups onsite and/or online,
but there will still be inconveniences in restoring files, especially for non-privileged
users.
-
Filesystem snapshots. This is really only helpful in the accidental file deletion
scenario, but it can be very
helpful in that case, and is quick and easy to deal with.
-
Copies of whole filesystems and/or disks (e.g. periodic
rsync(1) of the
whole machine). This is generally most useful in networks with unique requirements. For
general protection against disk failure, it is usually inferior to RAID. For restoring accidentally deleted files, it can be
comparable to UFS snapshots, but that depends on your
preferences.
-
RAID. Minimizes or avoids downtime when a disk
fails. At the expense of having to deal with disk failures more often (because you have
more disks), albeit at a much lower urgency.
-
Checking fingerprints of files. The mtree(8) utility is
very useful for this. Although it is not a backup technique, it helps guarantee that you
will notice when you need to resort to your backups. This is particularly important for
offline backups, and should be checked periodically.
It is quite easy to come up with even more techniques, many of them variations on the
ones listed above. Specialized requirements will usually lead to specialized techniques
(for example, backing up a live database usually requires a method particular to the
database software as an intermediate step). The important thing is to know what dangers
you want to protect against, and how you will handle each.