Date: Wed, 30 Jul 2008 11:02:52 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Modulok <modulok@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: dumping mounted file systems with insufficient space... Message-ID: <48903C4C.2090902@infracaninophile.co.uk> In-Reply-To: <64c038660807300154ue4e5a0cyb792b46fd3ec6037@mail.gmail.com> References: <64c038660807300154ue4e5a0cyb792b46fd3ec6037@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF7867D4E2875AEA7FA27DBBD
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Modulok wrote:
> Before I try this on a live server...
>=20
> 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 cours=
e,=20
subsequent modifications of the filesystem can cause more space than=20
otherwise expected to be used up -- as both the snapshot and the latest=20
versions of anything have to be kept around -- but how much impact this h=
as=20
depends entirely on the IO traffic characteristics of your particular=20
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 t=
o=20
have the data on a RAID1 mirror. Then you can detach one of the mirrors,=
=20
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=20
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=20
quiescent as possible. Basically, shut down any processes using the=20
filesystem. That's probably as unacceptable as any of the other
alternatives -- in which case, you can still go ahead and dump the=20
filesystem, but don't expect the generated dump to be 100% consistent.=20
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. =20
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
--------------enigF7867D4E2875AEA7FA27DBBD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkiQPFMACgkQ8Mjk52CukIyIhQCfQI3HgoJnQFf5yUtdtPOTJcJ9
iVMAn2etwcDxCF7dqxUA0SNr6TCqCU2i
=c048
-----END PGP SIGNATURE-----
--------------enigF7867D4E2875AEA7FA27DBBD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48903C4C.2090902>