>> 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- _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"