Re: dumping mounted file systems with insufficient space...
>> 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]"
Re: dumping mounted file systems with insufficient space...
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 signature.asc Description: OpenPGP digital signature
dumping mounted file systems with insufficient space...
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? -Modulok- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
