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 ext4
provide
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
damaged filesystem.
and recommend.
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
damaged.
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 par2
/parchive
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 parchive
supplement 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".