[plug] Backups
Craig Ringer
craig at postnewspapers.com.au
Tue Jul 27 15:39:13 WST 2004
James Devenish wrote:
>>Also, would I use dd or some other method for [backups]?
>
> This
> question about dd can be considered in the general case (i.e. not linked
> to DVDs), in which you'd have to ask yourself whether `dd` will produce
> a self-consistent backup. If the disk partition is in use for writing
> (e.g. databases, log files), then this is unlikely. But depending on the
> filesystem and nature of your files, it *might* still be acceptable, for
> *your* purposes, to use dd (even if a bit of `fsck`ing is necessary).
> But if you need to be careful, you'll have to take down your daemons,
> sync, take a filesystem snapshot, then do a backup using the snapshot.
> This sort of thing is mentioned in the list archives. This is in a sense
> a "grey area" and people do whatever is gives the best tradeoff between
> practicality and recoverability.
In general, I would tend to advise you NOT to use dd unless you have
good reasons to do so. For regular backups, I do not think it is a good
idea at all. Imagine if you discovered that all your recent backups had
the same subtle filesystem corruption as your main filesystem when you
when to recover a file...
dd is also very inefficient for backups, because it'll happily copy all
the space the filesystem has marked as 'free'. That space is likely to
contain old, deleted data which might well not be very compressible - or
it might contain data you'd prefer was NOT archived anywhere.
To top things off, to safely make a copy of a filesystem with dd you
must either unmount the filesystem or remount it read only. This means
you can't be doing much else with it at the time, and it's very
difficult to automate reliably. The alternative, using dd to clone the
filesystem while it's mounted read/write and in use, is a recipe for
massively corrupt backups. If you are using something like LVM, then you
can reasonably safely clone a filesystem that's mounted read/write by
using an LVM snapshot. You will still need to perform filesystem
recovery if you restore it later, but it should not need much and at
worst a few files may be corrupt if they were being written to as the
snapshot was taken. Without LVM, you've got to be crazy.
You may have guessed by now that my attitude to using dd for backups is
"just don't."
> Something like `dump` is generally
> better, because you can restore files on a arbitrary basis onto
> arbitrary partitions (whereas `dd` limits you to restoring an entire
> filesystem onto an identical partition). There are various suggestions
> and examples in the list archives.
The time honoured approach is using an archiver like tar, pax, or cpio.
This is much safer but can be somewhat slower than image based
backups. (It can also be a lot faster if you're backing up a mostly
empty volume or only doing incremental backups). In general, I think it
should be considered the default approach for backups, to be used unless
you have a good reason to choose something else.
Another increasingly common option is to use backups on large
random-access media like hard disks, storing a normal filesystem on it.
The backup is then updated periodically, rather than rewritten entirely.
IMHO this is good for rather large chunks of data that change
infrequently and don't need to be backed up too regularly.
If you're writing to DVD, I think that an archiver is the safest choice.
Creating a UDF or ISO9660 image with the files on it directly may not
preserve all file metadata. Using 'dd' to create an image to archive
isn't overly safe - one scratch, and you could potentially lose the
entire filesystem image. Unfortunately, IIRC compressed archives suffer
from the same problem to some extent, so ideally I'd archive my data
uncompressed or compress it before, rather than after, archiving. That
way an unreadable block will result in, at worst, one unusable file
instead of potentially large chunks of the archive being lost.
A quick aside: Does anybody here know of a tool that can create
compressed-then-archived archives, similar to what the Zip tool does
under DOS? I'd be looking for something that fully supported all the
UNIX file permissions, extended attributes, etc but knew how to run each
file through gzip before archiving it. I'm not too comfortable with
tar's -z option, because AFAIK gzip's compression deals very poorly with
corruption or unreadable blocks, and a bad block could render the rest
of the archive unreadable.
--
Craig Ringer
More information about the plug
mailing list