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