Snapshots and mmaped files.
I'm using lvm2 snapshots to do backups of several machines. (lvm2 2.00.33, device-mapper 1.01.00, ftp://sources.redhat.com/pub/dm/patches/2.6-unstable/2.6.9/2.6.9-udm1.tar.bz2 minus patch 13) (I've tried some newer patches, without success, but that'll be a separate mail).
The problem shows up with files that contains Berkeley databases. These files seem to be modified on both the original and the snapshot. They show up in my 'var' partition with imapd, and exim, and anything else that has a berkeley database opened, and modifies the file after the snapshot is taken.
The mtime of the file is not modified, only the contents. I suspect that if one side grew, then the size change would not be affected.
Thanks,
David Brown
If lvm2 snapshots are like most snapshots, then they aren't a panacea - they only decrease the window during which your database must be quiescent.
EG, with snapshotting:
1) Shut down database
2) bifurcate off a snapshot
3) Start up database
4) Do backup against snapshot
5) Eliminate snapshot
EG without snapshotting:
1) Shut down database
2) Do backup
3) Start up database
The first case has more steps, but it also has a lot shorter time during which your database is inactive.
Quoted 23 lines · David Brown
I'm using lvm2 snapshots to do backups of several machines. (lvm2 2.00.33, device-mapper 1.01.00, ftp://sources.redhat.com/pub/dm/patches/2.6-unstable/2.6.9/2.6.9-udm1.tar.bz2 minus patch 13) (I've tried some newer patches, without success, but that'll be a separate mail).
The problem shows up with files that contains Berkeley databases. These files seem to be modified on both the original and the snapshot. They show up in my 'var' partition with imapd, and exim, and anything else that has a berkeley database opened, and modifies the file after the snapshot is taken.
The mtime of the file is not modified, only the contents. I suspect that if one side grew, then the size change would not be affected.
Thanks,
David Brown_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
I don't think this is an issue of the database needing to be quiescent. The problem I'm seeing is that when the application modifies the database _after_ the snapshot is taken, the modifications partially appear in the snapshot as well. I'm guessing that file modification that goes through write does the right thing in the snapshot, but modifications done via mmap don't cause the snapshot to duplicate the data.
The Berkely DB code should be able to recover from a coherent snapshot taken at any point in time.
Dave
Quoted 22 lines · Dan Stromberg
If lvm2 snapshots are like most snapshots, then they aren't a panacea - they only decrease the window during which your database must be quiescent.
EG, with snapshotting:
1) Shut down database
2) bifurcate off a snapshot
3) Start up database
4) Do backup against snapshot
5) Eliminate snapshotEG without snapshotting:
1) Shut down database
2) Do backup
3) Start up databaseThe first case has more steps, but it also has a lot shorter time during which your database is inactive.