On Tue, May 27, 2014 at 10:09 AM, J. Roeleveld <[email protected]> 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). 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). 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). 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. Rich
