Re: Safe fsck / consistent backup while mounted

Re: Safe fsck / consistent backup while mounted

[Tomasz Chmielewski]

> Now I thought about a way to safely backup a MySQL or other database -
> without long service interruption:
>
> - Tell DB to turn itself into consistent state and freeze there
> - sync / btrfs filesystem sync ; fsfreeze -f /mountpoint
> - btrfs subvolume snapshot
> - fsfreeze -u /mountpoint

Hmm, I don't think fsfreeze works properly with btrfs?


-- 
Tomasz Chmielewski
http://wpkg.org

Safe fsck / consistent backup while mounted

[Martin Steigerwald]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

Hi!

In mailing list debian-user-german we are discussing safe ways to do a 
fsck when mounted.

I tested with Ext4 that fsck -nf works either with mount -o remount,ro or 
fsfreeze -f while writing with:

I=0; while true ; let I=I+1 ; do touch /boot/test$I ; sleep 0.2 ; done

In the read only mount case the write application returns errors, in the 
fsfreeze case Linux kernel stacks the changes in memory, but the fsck 
reports no errors like it should.


Now I thought about a way to safely backup a MySQL or other database - 
without long service interruption:

- Tell DB to turn itself into consistent state and freeze there
- sync / btrfs filesystem sync ; fsfreeze -f /mountpoint
- btrfs subvolume snapshot
- fsfreeze -u /mountpoint
- Tell DB to continue business as usual

My questions are:

1) Would this work?

2) Is the sync needed? And if so how to avoid the race condition between 
the sync and the fsfreeze invocation? Reading from the fsfreeze manpage I 
understand that fsfreeze allows all ongoing transactions to complete. But 
does that include everything what sync would bring to disk?

3) Is the fsfreeze needed at all? Does btrfs subvolume freeze the 
filesystem prior to the snapshot? The manpage doesn´t tell it.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Safe fsck / consistent backup while mounted

[Arne Jansen]

On 04.06.2011 12:25, Martin Steigerwald wrote:
> Hi!
>
> In mailing list debian-user-german we are discussing safe ways to do =
a
> fsck when mounted.
>
> I tested with Ext4 that fsck -nf works either with mount -o remount,r=
o or
> fsfreeze -f while writing with:
>
> I=3D0; while true ; let I=3DI+1 ; do touch /boot/test$I ; sleep 0.2 ;=
 done
>
> In the read only mount case the write application returns errors, in =
the
> fsfreeze case Linux kernel stacks the changes in memory, but the fsck
> reports no errors like it should.


for online fsck you can use scrub, it checks at least partially the
consistency.


>
>
> Now I thought about a way to safely backup a MySQL or other database =
-
> without long service interruption:
>
> - Tell DB to turn itself into consistent state and freeze there
> - sync / btrfs filesystem sync ; fsfreeze -f /mountpoint
> - btrfs subvolume snapshot
> - fsfreeze -u /mountpoint
> - Tell DB to continue business as usual

I'd just take a snapshot and backup from there. As a snapshot is a
consistent image of the filesystem at the time the snapshot is taken,
and every database is required to always have an at least recoverable
state on disk, the snapshot represents a state where your DB can
recover from.

>
> My questions are:
>
> 1) Would this work?
>
> 2) Is the sync needed? And if so how to avoid the race condition betw=
een
> the sync and the fsfreeze invocation? Reading from the fsfreeze manpa=
ge I
> understand that fsfreeze allows all ongoing transactions to complete.=
 But
> does that include everything what sync would bring to disk?
>
> 3) Is the fsfreeze needed at all? Does btrfs subvolume freeze the
> filesystem prior to the snapshot? The manpage doesn=B4t tell it.
>
> Thanks,

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Safe fsck / consistent backup while mounted

[Calvin Walton]

On Sat, 2011-06-04 at 12:25 +0200, Martin Steigerwald wrote:
> Hi!
>=20
> Now I thought about a way to safely backup a MySQL or other database =
-=20
> without long service interruption:
>=20
> - Tell DB to turn itself into consistent state and freeze there
> - sync / btrfs filesystem sync ; fsfreeze -f /mountpoint
> - btrfs subvolume snapshot
> - fsfreeze -u /mountpoint
> - Tell DB to continue business as usual
>=20
> My questions are:
> 2) Is the sync needed?

I'm not sure. In some cases it might not be: E.g. If the database uses
fsync() to save the data when you tell it to go into a consistent state=
,
there would be no need to have a separate sync. It shouldn't hurt,
however.

> 3) Is the fsfreeze needed at all? Does btrfs subvolume freeze the=20
> filesystem prior to the snapshot? The manpage doesn=C2=B4t tell it.

The fsfreeze should not be needed. The btrfs subvolume snapshot command
takes an atomic snapshot of the current subvolume state.

--=20
Calvin Walton <calvin.walton@kepstin.ca>

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Safe fsck / consistent backup while mounted

[David Pottage]

On 04/06/11 11:25, Martin Steigerwald wrote:

> > Now I thought about a way to safely backup a MySQL or other database - 
> > without long service interruption:
> >
> > - Tell DB to turn itself into consistent state and freeze there
> > - sync / btrfs filesystem sync ; fsfreeze -f /mountpoint
> > - btrfs subvolume snapshot
> > - fsfreeze -u /mountpoint
> > - Tell DB to continue business as usual
> >
> > My questions are:
> >
> > 1) Would this work?
It should do, and it is common way to backup or check high availability
databases.

About a year ago I was responsible for a database backup and checking
system at a large blue chip company. The database was Informix, and it's
files where kept on a Netapp storage appliance, but the basic principle
was the same.

The database was frozen temporarily, a snapshot taken, and then the
database un-frozen. The snapshot was then made writable, and was then
mounted by the database engine and checked for errors. The live database
is only off line for a few seconds so the users don't notice, especaly
if the snapshot is taken at night when there are few users.

-- David Pottage