Modulok wrote:
Before I try this on a live server...

I can use dump(8) an active, mounted file systems via the -L flag.
According to the manual, this first creates a snapshot of the file
system, to the .snap directory of the file systems root. What if the
file system to be dumped, does not have sufficient free-space to store
a snapshot? Can I still safely dump(8) a mounted file system?

A snapshot doesn't take any significant /extra/ space itself. Rather it consists of marking the state of the system at that time and provides a view (via the .snap directory) of that state of the filesystem. Of course, subsequent modifications of the filesystem can cause more space than otherwise expected to be used up -- as both the snapshot and the latest versions of anything have to be kept around -- but how much impact this has depends entirely on the IO traffic characteristics of your particular filesystem and cannot be predicted in any useful fashion without a great
deal more information.

If snapshots won't work for you, another trick (if you can swing it) is to have the data on a RAID1 mirror. Then you can detach one of the mirrors, back it up and then reattach the mirror. Doing this with gmirror is a simple matter of writing about a 10 line shell script. Other mirroring hard/soft-ware may be less cooperative. However you do it, this will
involve an extended period while mirrors resynchronise after the backup
where your file system won't have the desired level of resilience.

If you can't use snapshots, can't split the mirror and you can't unmount
the filesystem, then the next best thing is to make the filesystem as quiescent as possible. Basically, shut down any processes using the filesystem. That's probably as unacceptable as any of the other alternatives -- in which case, you can still go ahead and dump the filesystem, but don't expect the generated dump to be 100% consistent. It will be 'good enough' for some purposes, but files actively involved in IO at the time the dump is made are likely to be corrupted.


Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                 Flat 3
PGP:     Ramsgate
                                                 Kent, CT11 9PW

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to