[rear-users] Btrfs subvolume snapshots backup and restore

Schlomo Schapiro schlomo at schapiro.org
Tue Oct 1 14:13:08 CEST 2013


On 1 October 2013 13:27, Johannes Meixner <jsmeix at suse.de> wrote:

>  I also think that the loss of snapshots could be forgiven
>> in the case of a real disaster that made you recover the
>> server on fresh hardware :-) After all all snapshot systems
>> utilize the same disks for the snapshots and don't offload
>> the snapshots to secure storage.
> I do not agree.
> Assume the admin does a major rework on his server that takes some days.
> To be safe he creates a btrfs snapshot before he starts his rework.
> At some day while the major rework is still done and while the server
> system as a whole is in a very inconsistent state a disaster happens.
> If the admin cannot also have his btrfs snapshot back after disaster
> recovery he can onyl get back the inconsistent state.

I disagree :-) ReaR is not a backup tool and does not do
historized/versioned backups (unless you pimp it with RSYNC and hardlinks,
use RBME or something like that).

If the admin needs a backup that allows him to go back in time then I would
strongly suggest to use a real backup software (e.g. Bacula/Bareos) and not
rely on the simple backup that comes with ReaR.

> Of course a really careful admin should not rely on btrfs snapshots
> but do a real backup on separated media instead.

Exactly. Snapshots are great but no help in case of a disaster. I would try
to keep things simple.


> But btrfs snapshots is so much advertised as major feature of btrfs
> that I think it is "just expected" that this "just works" even
> for disaster recovery.

IMHO with LVM snapshots nobody expects ReaR to recover the snapshots. So
why should people expect this to work for btrfs snapshots?

Regarding your restore scheme: Did you try it out? I would be curious to
know if it actually works...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pikachu.3ti.be/pipermail/rear-users/attachments/20131001/cd1c5d12/attachment.html>

More information about the rear-users mailing list