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 do not really inspire confidence in the filesystem for backups 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 wrt. 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?

  • 3
    See unix.stackexchange.com/questions/140360/…. With BTRFS you can use subvolume snapshots instead of hardlinks. – StrongBad Dec 22 '14 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 '14 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 '14 at 14:23
  • @kirill-a I did consider ZFS, but since it is not mainlined I am hesitant to use it. – Lekensteyn Dec 22 '14 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 '14 at 14:29

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.


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.