Exploring a backup strategy with Btrfs

mamr · 2016-09-08 14:21:39

Since it's been a while since I last thought about this, I'm revisiting the idea of using Btrfs for backup. I know that other solutions exist and that Btrfs is probably not the most stable one, but I want to concentrate on Btrfs for now.

Current setup

I currently backup /home/username (~ 200GB) to LUKS-encrypted external hard drives (1 TB) which are formatted with ext4. I use rsync with the -b flag so deleted files get stored separately. I don't use any incremental backup features.

Goals

I want to keep the functionality of my old setup (encrypted, keep deleted files) but also want to protect my files against bit-rot (on the source drive inside my laptop and on the backup drive). Additional snapshotting would be a bonus.

Current plan/questions

I'm currently thinking about creating two separate partitions on a single external hard drive, formatting them with Btrfs and use them with raid-1. I'm pretty much lost from there on.

Should I use rsync or Btrfs' send/receive features? Is self-healing turned on by default when using raid-1. Do I have to use raid-1 or can I use 'dup' (AFAIK dup is just for metadata)? Should I use subvolumes instead of separate partitions? Is there simpler variant of this setup?

eschwartz · 2016-09-08 19:59:03

Use btrfs subvolume snapshots on a single btrfs partition, the whole point of btrfs is that it natively supports deduping and instantaneous backup.

ratcheer · 2016-09-09 00:20:44

Here is what I do. It may not be optimal, but it has worked very well for me for a couple of years.

I take a read-only snapshot of each subvolume (for me, these are /, /home. and /mydata). I give the snapshot filenames a numerical suffix, which I increment each time I make a new backup snapshot.

For the first backup, only, I send the full backup snapshots to an external drive. I also keep the snapshot on the original drive.

For subsequent backups, I do an incremental send/receive of the previous snapshot and the most recent snapshot to the external drive. Then, I delete the previous snapshot from the original drive, but keep the most recent one.

On the external drive, I delete snapshots older than some time interval (for me, that is two months). Note that if you have incremental snapshots, e.g., 45, 46, 47, and 48, you cannot delete #47, or #48 will be incomplete. But you can delete # 45, and #'s 46, 47, and 48 will be consistent. I hope this is clear.

That's pretty much it. The incremental send/receives are much faster than the original send, because only changed blocks are written for the latest snapshot. But you have a rolling backup of each file in every snapshot as far back as you keep a complete sequence of snapshots. I hope this is clear, too.

Tim

Leonid.I · 2016-09-09 02:20:54

I think, the main question to be answered when designing a backup strategy, is how robust the data recovery is. BTRFS is still not that stable, so I'd say using it as a backup filesystem is not a good idea. And the issue is not only in the FS itself, but also in a machine used for recovery. Is that operating system guaranteed to have a recent enough kernel and be able to mount BTRFS and work with it?

That's why I think that using ext4 as a backup FS is a much better idea. Of course, in everyday work, BTRFS can be used as well. But its snapshotting capabilities are now only used to prevent inconsistent backups of a live FS.

The ideal tool would be rsnapshot, adapted to BTRFS snapshots instead of LVM ones...

HiImTye · 2016-09-09 03:54:09

I read recently that a BTRFS dev on twitter suggested using ZFS because of an easily reproducable bug (using basically the ZFS test method) that causes invalid data in a corrupt file to be striped across all copies of the file

mamr · 2016-09-09 07:46:50

Thanks for your answers. How do you guys project your files against bitrot. I'm pretty happy with my current setup. The only thing missing for me is bitrot protection.

bluewind · 2016-09-09 09:00:33

Don't use rsync, use borg. Either just use borg as described in their docs or build a more fancy script like this. You can also use a local destination instead of a remote server. Just check their docs. Also if you don't want to write the backup destination all the time, put it in a wrapper like this.

banshee28 · 2016-09-12 01:43:59

bluewind wrote:

Don't use rsync, use borg. Either just use borg as described in their docs or build a more fancy script like this. You can also use a local destination instead of a remote server. Just check their docs. Also if you don't want to write the backup destination all the time, put it in a wrapper like this.

Interesting, never heard of borg. Used rsync all the time. I will look into this as a replacement for my local and external disk backups.

R00KIE · 2016-09-12 09:26:55

From Borg's homepage:

EXPECT THAT WE WILL BREAK COMPATIBILITY REPEATEDLY WHEN MAJOR RELEASE NUMBER CHANGES (like when going from 0.x.y to 1.0.0 or from 1.x.y to 2.0.0).

Although borg seems nice, this would make me think twice. Bitrot can be a problem but using a filesystem that is not stable or a backup program that is still under development and subject to incompatible changes to do backups seems like a gamble to me.

bluewind · 2016-09-12 12:26:02

That's just a short version of semver. You can't downgrade, but upgrade are obviously supported. Upgrading from 0.9.x to 1.x was just fine and worked without loss of data.

NoSuck · 2016-09-15 01:53:06

I'm currently thinking about creating two separate partitions on a single external hard drive, formatting them with Btrfs and use them with raid-1.

What do you hope to gain by mirroring data onto the same hard drive?

fluxboxer · 2016-09-15 06:41:34

bluewind wrote:

Don't use rsync, use borg. Either just use borg as described in their docs or build a more fancy script like this. You can also use a local destination instead of a remote server. Just check their docs. Also if you don't want to write the backup destination all the time, put it in a wrapper like this.

Why not rsync?

bluewind · 2016-09-15 09:35:52

rsync doesn't support verification, deduplication, (client side) encryption, checksums. You can add some of that with other tools, but it's really not worth it. rsnapshot is horribly slow and I don't know a tool that handles the other things.

Also rsync creates tons of files (well that's how it's supposed to work) which sucks if you put backups of multiple systems on one destination box. File systems are apparently not optimized to work efficiently with many millions of files so you'll run into all kinds of problems you don't expect. Also if you make a secondary backup (which you want to be off-site and off-line ideally), you have to deal with even more files than you have to with a single backup.

Also feel free to read my thesis if you want some more theoretical background to help you reason about the features you need. Just don't take the example at the end too seriously. That uses duplicity, which is a really nice tool and all, but borg is more space efficient and faster.

fluxboxer · 2016-09-15 09:40:44

Thanks a lot for the extended explanation.

mamr · 2016-09-15 15:50:16

NoSuck wrote:

I'm currently thinking about creating two separate partitions on a single external hard drive, formatting them with Btrfs and use them with raid-1.
What do you hope to gain by mirroring data onto the same hard drive?

Because as far as I understand, the second partition is needed for the self-healing to work (provided that the second partition has the affected bit/file stored in working condition). Is it possible to "restore" an affected bit/file from an old snapshot on the same subvolume?

NoSuck · 2016-09-16 23:24:44

I asked because you gain no protection from hardware failure. Raid-1 is generally used with at least two hard drives.

hatahata50 · 2016-10-28 06:37:26

i am a newbee to btrfs .

if d >c then dd if=/dev/sdc of=/dev/sdd bs=32K (sdc & sdd is USB hard disk )

and do gparted to /dev/sdd to be full size , i finished cloning and it works well .

btrfs is too difficult for me .
this method is bad to downsizing .

Last edited by hatahata50 (2016-11-01 17:54:12)

hatahata50 · 2016-10-31 03:09:55

dd takes too long time .
so this time i use partclone .

A arch pc----------USB HARD DISK C sdc
----------USB HARD DISK D sdd

1)

dd if=/dev/sdc of=/dev/sdd bs=512

***need not end ***, becase MBR only is needed .

2)

partclone.btrfs -c -s     /dev/sdc1     -o    ~/img.pcl
partclone.btrfs -r -s     ~/img.pcl     -o    /dev/sdd1

3) i connect 'USB HARD DISK D' to another PC B (usb conect).
then
another PC B boot 'btrfs archlinux'

i have some questions .
A) 1) is ugly .

dd if=/dev/sdc of=/dev/sdd bs=446 count=1

is fail

dd if=/dev/sdc of=/dev/sdd bs=512 count=10000

is OK

what is minimal setting ?

B) boot pc B by USB HDD C and then connect USB HDD D
and

  dd if=/dev/sdc of=/dev/sda bs=512    <--- sdb is C , sdc is D

but PC B cannnot boot from sata hard disk(/dev/sda) although i try correct grub.cfg .
i think brtfs has special features .

---------
regards

Last edited by hatahata50 (2016-10-31 03:43:35)

hatahata50 · 2016-11-01 18:11:23

i uproad 2 videos .

1)cloning itself
https://youtu.be/eFfKmEh6KO8

2)and then gparted
https://youtu.be/wRpEqggWS8w

Last edited by hatahata50 (2016-11-01 18:12:12)

hatahata50 · 2016-11-15 05:18:32

i think that
if the target hard disk is smaller than the source hard disk ,
at first shtink the source hard disk by gparted then do either partclene or dd .
------
regards

Arch Linux

#1 2016-09-08 14:21:39