Miles Nordin wrote: > that SQLite2 should be equally as tolerant of snapshot backups as it > is of cord-yanking. > > The special backup features of databases including ``performing a > checkpoint'' or whatever, are for systems incapable of snapshots, > which is most of them. Snapshots are not writeable, so this ``in the > middle of a write'' stuff just does not happen.
This is correct. The general term for these sorts of point-in-time backups is "crash consistant". If the database can be recovered easily (and/or automatically) from pulling the plug (or a kill -9), then a snapshot is an instant backup of that database. In-flight transactions (ones that have not been committed) at the database level are rolled back. Applications using the database will be confused by this in a recovery scenario, since the transaction was reported as committed are gone when the database comes back. But that's the case any time a database moves "backward" in time. > Of course Toby rightly pointed out this claim does not apply if you > take a host snapshot of a virtual disk, inside which a database is > running on the VM guest---that implicates several pieces of > untrustworthy stacked software. But for snapshotting SQLite2 to clone > the currently-running machine I think the claim does apply, no? > Snapshots of a virtual disk are also crash-consistant. If the VM has not committed its transactionally-committed data and is still holding it volatile memory, that VM is not maintaining its ACID requirements, and that's a bug in either the database or in the OS running on the VM. The snapshot represents the disk state as if the VM were instantly gone. If the VM or the database can't recover from pulling the virtual plug, the snapshot can't help that. That said, it is a good idea to quiesce the software stack as much as possible to make the recovery from the crash-consistant image as painless as possible. For example, if you take a snapshot of a VM running on an EXT2 filesystem (or unlogged UFS for that matter) the recovery will require an fsck of that filesystem to ensure that the filesystem structure is consistant. Perforing a "lockfs" on the filesystem while the snapshot is taken could mitigate that, but that's still out of the scope of the ZFS snapshot. --Joe --Joe _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
