I have two 4TB hard drives, which I intend to use for storing media (music, movies, etc.), and backups of my laptop. The plan is to have one which is regularly accessed, for both accessing the media and producing daily incremental backups. The other is to be used for "cold" backups - once a month or so I plan to snapshot all the media, plus the most recent backup, and then put it in a cupboard.

I would like to use btrfs on the "hot" drive, so that I don't unwittingly get corrupted data. However, this answer suggests not to use btrfs for backups, and so does their documentation. So I thought I might get the best of both worlds if I had the "hot" drive on btrfs, and the "cold" drive on ext4. I think that means the frequently used drive gets all the self-healing benefits, and if anything goes wrong I have a stable backup that I can be sure will never break due to kernel problems.

Is that a reasonable strategy, and are there any pitfalls I should be aware of?

  • I'd be tempted to mirror the (2) drives. Jan 24, 2021 at 19:23

1 Answer 1


Choosing a filesystem, apart from the obvious technical features that you want to use is still a personal preference. You should also be aware that "self-healing" can only work when a BTRFS filesystem is assigned more than one drive and the meta/data storage is set accordingly. The most BTRFS can do reliably with a single drive is detect corruptions, and avoid using the corrupted parts of data any further. In the very limited case when the corruption is in the metadata, a second copy may be used to recover it, otherwise all you get is an I/O error and a kernel log entry. Please be aware though that metadata by default is NOT duplicated on SSDs, only on traditional drives.

It's also a good practice to use different filesystems for different types of data to avoid any kernel bugs to affect both drives; but again, BTRFS is famous for being able to detect environmental factors corrupting the data in previously unrecognized ways, so this could be an argument to use BTRFS on both places.

Using two different filesystems is also wise from the point of view that BTRFS was not the easiest to use on different platforms - if all your backups are on a portable drive with ext4, chances are you can easily access them anywhere else, but just the same, you can use any modern live CD to access BTRFS data

Just about the only drawback of a BTRFS backup drive is that if something is badly messed up, recovering just to access your data might be more complicated than an fsck, but due to the error detection, I've had great luck on a 3-drive RAID5 system where two drives started acting up simultaneously, and one of them actually dropped off the bus until a poweroff. With BTRFS, I was able to copy off most of my data, flagging the few unimportant recently changes files that were corrupt.

For any BTRFS user, the most useful part of having a BTRFS filesystem is quick snapshots, but they need to be managed manually, and you can run out of disk space if you use them with no consideration.

A further advantage of the the BTRFS snapshots is the incremental backup between them - i.e. if you make snapshots on subvolumes with very large files that have only few blocks of changes (i.e. lightly used VMs, some types of database files, mailbox archives), the incremental btrfs send can be used to reconstruct the few actual changes, instead of shipping entire files over; which would happen if you used rsync to copy snapshots to the cold drive.

But again, this is only an advantage if both the source and the destination of the backups are BTRFS.

One way around this would be to use BTRFS as the work drive, with snapshots used heavily, then using an external drive as ext2/ext3/ext4 only to store btrfs send images for full and frequent incremental backups; for data integrity, using hashes on the stored btrfs send files, and using something like par2 to generate additional parity to ensure recoverability from corrupted/deleted files.

This above could sound like my dream backup system, however, it's really cold store indeed - you cannot recover any part of data without reimporting it on a new BTRFS volume with sufficient space, and testing that the procedure is safe can be quite difficult or error-prone.

You must log in to answer this question.

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