| 1 |
On Tue, May 27, 2014 at 10:09 AM, J. Roeleveld <joost@××××××××.org> wrote: |
| 2 |
> I am still happily using LVM with snapshots. Those are instantaneous as well |
| 3 |
> and I can then backup the snapshot, which on my server takes between 2 hours |
| 4 |
> (incremental) and 3 weeks (full) |
| 5 |
> When a snapshot is backed up, it is removed. |
| 6 |
> |
| 7 |
> The process to create the snapshots runs daily, but I could also configure it |
| 8 |
> to run more often. This means that when I start a daily backup, the |
| 9 |
> incrementals are piling up as snapshots. |
| 10 |
> |
| 11 |
> With 15 different filesystems to backup, I didn't experience any issue with |
| 12 |
> this. |
| 13 |
> |
| 14 |
> I wonder how btrfs would deal with a situation like this? |
| 15 |
|
| 16 |
btrfs wouldn't have any issues with this at all. You'd have an |
| 17 |
advantage in that you wouldn't have to unmount the filesystem to |
| 18 |
cleanly create the snapshot (which you have to do with lvm). If |
| 19 |
you're concerned about application-level consistency you still need to |
| 20 |
get applications to flush their writes/checkpoint/etc (which don't |
| 21 |
have to be on disk, but they do have to be sent to the kernel). |
| 22 |
|
| 23 |
If you want to get really crazy you could make use of btrfs send as |
| 24 |
well - which is a filesystem-level function which tracks the actual |
| 25 |
changes between snapshots. Think of it like librsync with full file |
| 26 |
comparisons (a very expensive mode that few use in practice) but it |
| 27 |
doesn't need to actually read the files or have access to the |
| 28 |
destination files to find the differences. Doing this does require |
| 29 |
keeping around a snapshot until all backups incrementally created |
| 30 |
against it are done (if there are going to be any). |
| 31 |
|
| 32 |
But, you can always just create a snapshot, write it to backup with |
| 33 |
your favorite tool (it is just a directory tree), and then remove it |
| 34 |
as soon as you're done with it. Creating a snapshot is atomic at the |
| 35 |
filesystem level, though again if you want application level |
| 36 |
consistency you need to deal with that until somebody comes up with a |
| 37 |
transactional way to store files on Linux that is more elegant that |
| 38 |
fsyncing on every write. |
| 39 |
|
| 40 |
Rich |
Archives