10

Right now I have a pretty traditional backup filesystem structure on top of ext4. Every time a backup is made, a new folder backup-DATE is created to which files are rsync'ed (with hardlinks made using rsync's --link-dest option).

Since I have read about bitrot, I would like to have a checksum for all files, transparently. Apparently ext4 cannot do that, but btrfs does offer support for data checksums (and even a built-in RAID1 mode). For a start, I would like to use btrfs as a "dumb" filesystem which supports data checksums without using its advanced features such as RAID, subvolume snapshots, send/receive, etc.

However, their wiki does not really inspire confidence in the filesystem for backup purposes:

"While many people use it reliably, there are still problems being found. You should keep and test backups of your data, and be prepared to use them." - Getting Started

"Is btrfs stable? Long answer: [..] Whatever you do, we recommend keeping good, tested, off-system (and off-site) backups." - FAQ.

My use case is to have an offline backup. For that reason the disk will see very little use (as in hours) and will be frequently plugged/unplugged (eSATA or USB 3.0). Having a reliable filesystem is a must. It must not be worse than ext4 with regard to power failures, unclean shutdowns, etc.

Is it actually recommended to use btrfs as filesystem for backup purposes? Are there other properties of btrfs which may make it less (or more) suitable?

Improve this question
19
  • 3
    See unix.stackexchange.com/questions/140360/…. With BTRFS you can use subvolume snapshots instead of hardlinks.
    – StrongBad
    Dec 22, 2014 at 11:40
  • 1
    You can read a good article about using of btrfs here but for backups I would recommend ZFS (which is found on BSD and Solaris systems). You can also use it on Linux wiki
    – kirill-a
    Dec 22, 2014 at 12:14
  • @StrongBad a reliable free space indicator is definitely something where btrfs does not really excel. The question is however not about replacing hardlinks with subvolume snapshots, but rather the reliability of btrfs as filesystem for a backup disk.
    – Lekensteyn
    Dec 22, 2014 at 14:23
  • @kirill-a I did consider ZFS, but since it is not mainlined I am hesitant to use it.
    – Lekensteyn
    Dec 22, 2014 at 14:24
  • @Lekensteyn I think subvolume snapshots qualifies as "Are there other properties of btrfs which may make it less (or more) suitable as backup filesystem?"
    – StrongBad
    Dec 22, 2014 at 14:29

2 Answers 2

Reset to default
5

I will just provide a short answer because I think this is being overthought.

If you read the main kernel wiki about the btrfs (sub-)commands, you will find that there are two commands for:

  1. making a "backup": btrfs-send
  2. and restore: btrfs-restore

Just in case, this means that it is not (designed to be) a backup, but to be an snapshot filesystem, with the idea of rolling back if needed, not as a backup but as "flexible".

Therefore — no, do not use it as backup — use it as a versioned filesystem where you can test things and go back. Don't rely on it.

Improve this answer
3

I recently had problems with a btrfs file system on an up-to-date kernel 4.10.0. The file system got destroyed in a virtualbox VM because TRIM doesn't seem to be correctly implemented somewhere, and AFAIK it had something to do with index numbers of sub volumes. After switching to VMware, the file system was still corrupt and surprisingly btrfs check wasn't able to find and fix the error. Finally I switched back to ext4.

The good thing: I didn't lose data. btrfs seems to be always consistent at least for reading, but it showed me it's still far away from production readiness.

Anyway, on a server I'm still using it as backup volume because there I need the feature of cow-copying for deduplication (exactly your use case). The data is just too much in size for a traditional file system.

Update

I still have the filesystem on my server (see above), but it broke right after I posted this here. Now, I have a big read-only backup volume of 700G which would expand to ~7TB on ext4 if I try to copy away everything using tar|tar. Due to lack of time, I didn't yet check if newer kernel versions can handle it. The actual problem is a "transaction abort" which occours ~2 seconds after mounting writeable and which remounts the volume read-only. The original cause is probably a broken version of btrfs-convert, which I used years ago when I created this volume, and still a limited feature set of the current btrfs check which at least should be able to find all damages on a volume which reproducibly lead to a transaction abort or any other problems, instead of just saying that my filesystem is healthy.

Update 2

I was finally able to solve this by copying over everything to a new volume using a python script (based on an oss deduplication tool). It works with a file pool on the target filesystem based on checksums and makes cow-links from there. This semi-efficient process took 2 days, but then I had a new clean btrfs-based filesystem with all my data recovered. Could publish that code if wanted, but don't expect a perfect, easy-to-use and error-proof tool.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .