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