From: Theodore Tso <tytso@MIT.EDU>
Newsgroups: fa.linux.kernel
Subject: Re: The ext3 way of journalling
Date: Wed, 09 Jan 2008 12:51:05 UTC
Message-ID: <fa.oVVRC65r+Lby4+1lRcD8Np0YpIU@ifi.uio.no>

On Wed, Jan 09, 2008 at 02:55:53AM -0500, Valdis.Kletnieks@vt.edu wrote:
>
> Does this create a snapshot of the *disk* at that moment, or does it
> capture "disk plus still-to-be-written blocks in the cache"?
> (Phrased differently, does it Do The Right Thing regarding "blocks
> queued before lvcreate" and "blocks queued for write after
> lvcreate")?
>
> If the snapshot doesn't capture the blocks queued but still
> unwritten by kjournald and similar, then you're still hitting the
> same old problems that you always get when you fsck an "active
> disk".

Actually, it does better than that.  For ext3 and xfs, it will take a
snapshot of the filesystem in a quiscent state; that is, it will force
the journal transaction to close, suspend all filesystem activity,
take a snapshot of the disk as if it had been unmounted, and then
allow filesystem activity to continue.

So if you look at an ext3 filesystem taken in this way, you will see
that the NEEDS_RECOVERY flag is not set, since the ext3 journal is
empty on the snapshot.  So snapshots are also a great way of doing
stable backups.  For the purposes of stable backups, you'll also want
to quiesce your application files, particularly databases.

For example, in the case of mysql, send the server the sql commands
"flush tables with read lock; flush logs", take the snapshot, and
then after the snapshot send the server the sql command "unlock tables".
For more information, see:

    http://forums.mysql.com/read.php?26,185026,185302#msg-185302

If you do this, you will get a snapshot of your disk where *both* the
database and the filesystem is at a stable state, perfect for doing a
backup.

						- Ted