On Wed, Jul 8, 2009 at 9:37 AM, Laurent Blume<laurent@...
> Chris Ridd a écrit :
>> If a file's being written to while it is being backed up, the backup is
>> only going to contain some of the changes.
>> Restoring such a file from backup is straightforward, but it might
>> contain only partially valid data. That's what I meant by the
>> complication :-)
> And there is absolutely no way to protect against that, except following
> the ufsdump(1M) man to the letter: run it on an unmounted or read-only FS,
> Using a snapshot won't change that, but it will avoid an issue that has
> become prevalent those last few years: the changes on a live FS between
> the beginning and the end of running ufsdump are so big, that the backup
> simply fails at the end and is unusable.
good stuff so far. If we remember that a root disk is generally not going to
have the kind of changes that would be catastropic for transient updates,
such as would be the case with a database file, for instance, the chances
of losing something really important with a snapshot has got to be very
close to zero. If you changed the root password after you snapped, then
had to recover, the old root password would be in the backup, but that's
not catastrophic. Annoying, but not going to compromise your business.
OTOH, if you have a production database in a file system, or some other
kind of logging such as would be required for Sarbanes-Oxley (in the US)
then you have to quies the database or application so you can guarantee
there's no transients at the time of the snap. Obviously, transactional
logs from databases help recover to a point in time, and other applications
may need their own "transaction type logs" if you're really concerned
about getting back to time of the "failure".