dumping mounted file systems with insufficient space...

[Matthew Seaman]

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.  

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20080730/2965f382/signature.pgp