On Tuesday, May 27, 2014 10:31:26 AM Rich Freeman wrote: > On Tue, May 27, 2014 at 10:09 AM, J. Roeleveld <jo...@antarean.org> wrote: > > I am still happily using LVM with snapshots. Those are instantaneous as > > well and I can then backup the snapshot, which on my server takes between > > 2 hours (incremental) and 3 weeks (full) > > When a snapshot is backed up, it is removed. > > > > The process to create the snapshots runs daily, but I could also configure > > it to run more often. This means that when I start a daily backup, the > > incrementals are piling up as snapshots. > > > > With 15 different filesystems to backup, I didn't experience any issue > > with > > this. > > > > I wonder how btrfs would deal with a situation like this? > > btrfs wouldn't have any issues with this at all. You'd have an > advantage in that you wouldn't have to unmount the filesystem to > cleanly create the snapshot (which you have to do with lvm).
That, or a "sync" prior to creating the snapshot. :) > If > you're concerned about application-level consistency you still need to > get applications to flush their writes/checkpoint/etc (which don't > have to be on disk, but they do have to be sent to the kernel). Application-level consistency, for some of the filesystems, means stopping the application, taking a backup of the database, creating a snapshot and then restarting the application. For all the applications I run, the entire nightly process takes 2 minutes in total. During this time, services become temporarily unavailable. This is acceptable. > If you want to get really crazy you could make use of btrfs send as > well - which is a filesystem-level function which tracks the actual > changes between snapshots. Think of it like librsync with full file > comparisons (a very expensive mode that few use in practice) but it > doesn't need to actually read the files or have access to the > destination files to find the differences. Doing this does require > keeping around a snapshot until all backups incrementally created > against it are done (if there are going to be any). I have a yearly (full), monthly, weekly and daily. Each incremental is against the most recent one of itself or longer period. That means having to keep multiple snapshots active, which I prefer to avoid. But, it is a good idea for backing up desktops and laptops. > But, you can always just create a snapshot, write it to backup with > your favorite tool (it is just a directory tree), and then remove it > as soon as you're done with it. Creating a snapshot is atomic at the > filesystem level, though again if you want application level > consistency you need to deal with that until somebody comes up with a > transactional way to store files on Linux that is more elegant that > fsyncing on every write. That would require a method to keep database and filesystem perfectly in sync when they are not necessarily on the same machine.
