backup strategy text for handbook?
Lowell Gilbert
lgusenet at be-well.ilk.org
Wed Nov 9 19:45:50 UTC 2005
I wrote the following the other day in response to a question on a
FreeBSD newsgroup. Should I adapt it for the Handbook backup section?
================================================================
My advice in devising a backup plan is to make sure that all of the
following problems are covered:
- disk failure
- accidental file deletion
- random file corruption
- complete machine destruction (e.g., fire) including destruction of
any on-site backups
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's 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 I listed, 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
there, and is quick and easy to deal with.
- copies of whole filesystems and/or disks. [e.g., periodic rsync
of the whole machine] I've seen this be most useful in networks
with unique requirements. For general protection against disk
failure, it's 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(1) program 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 I listed. Specialized requirements will
usually lead to specialized techniques (e.g., 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.
More information about the freebsd-doc
mailing list