dumping mounted file systems with insufficient space...
modulok at gmail.com
Fri Aug 1 13:31:28 UTC 2008
>> 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: http://www.infracaninophile.co.uk/pgpkey Ramsgate
> Kent, CT11 9PW
Thank you for the clarification about snapshots, Matthew. I went with
a dump to another disk and it worked out without any problems :)
More information about the freebsd-questions