An imho very important aspect I have not seen discussed in the other answers is the stability features of the on disk layout of the filesystem (e.g. consider consulting the documentation of possible canditates ext4, btrfs)
While the codebase and amount of testing of the codebase filesystem drivers, is indeed important as other answers alrady showed, since it is the protection of the data during its reading and writing, the on disk layout/format is the protection against risks to your data at rest, which are forms of hardware deffects such as unreadable sectors, or silent bit rot.
With respect to
ext4, which is said to have good characteristics as regards is long tested codebase (https://events.static.linuxfound.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf shows it took longer to find bugs in it than for instance in the more modern and more complex
btrfs), I have looked into ext4 resistence at rest and found some imho deficiencies, of the else praised filesystem.
I would consider it prudent (if chosen
ext4 as the "rock-solid backup fs") to improve recoverability (albeit "hardening it") by using the
e2image tool the developers of
The e2image program will save critical ext2, ext3, or ext4 filesystem
metadata located on device to a file specified by image-file. The
image file may be examined by dumpe2fs and debugfs, by using the -i
option to those programs. This can assist an expert in recovering
catastrophically corrupted filesystems. In the future, e2fsck will be
enhanced to be able to use the image file to help recover a badly
It is a very good idea to create image files for all of filesystems on
a system and save the partition layout (which can be generated using
the fdisk -l command) at regular intervals --- at boot time, and/or
every week or so. The image file should be stored on some filesystem
other than the filesystem whose data it contains, to ensure that this
data is accessible in the case where the filesystem has been badly
Considering that not even all meta-data of
ext4 on disk layout are provided with redundancy (i.e. superblock is stored commenly multiple times as a copy, indoes are stored in exactly 1 place only), the
ext4 is surely inferrior with
btrfs that would provide at least checksums for all metadata + the file contents data.
To counteract this "shortcome" of
ext4 and make it a more
rock-solid thing in the aspect of on disk layout it could be reasonable to supplement this redundancy and recovery for the file contents via
Despite the question demands the focus on the filesystem solutions, I would like to bring to attention that most of what a filesystem provides (caching, journals, reclaiming of allocated space, allocating of blocks etc) is not necessarily something that backup data will benefit from much when being only writen and read in bulk and rarley. For that I would consider using a
tar backup as the more optimal backup solution, as codebase used in the process es reduced, and hence there less bugs if there are less "features".