>> 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

Thank you for the clarification about snapshots, Matthew. I went with
a dump to another disk and it worked out without any problems :)

-Modulok-
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to