Using dm-integrity to enable integrity checks to external backup drive filesystems without checksums

I am setting up a home server with two internal and two external drives, all of them with the same capacity. One internal drive is the main drive which will be accessed through SMB/CIFS and NFSv4. The other internal drive is a backup drive. The two external drives are additional backup drives. I have two to be able to have one external drive at home and the other one off-site.

The internal drives both shall use btrfs, and backups will be done via btrfs snapshots and btrfs send/receive through btrbk. This allows me to do incremental backups very efficiently, without having to do scans over all files (which is what needs to be done when using rsync for example). Also, btrfs snapshots are atomic, which can sometimes be a big help.

The external drives however should ideally not use btrfs. The reason is additional safety. If I use the same filesystem everywhere, then issues like FS related bugs could affect all drives. If the external drives use other filesystems though this is migitated. For this reason, I’d like to use ext4 for one external drive and XFS for the other.

All four drives shall use encryption through dm-crypt and LUKS2.

However, one remaining issue is that only btrfs and ZFS have built-in data checksums and scrub functionality. ext4 and XFS do not. For this reason, I’ve been looking at dm-integrity. I am primarily interested in using it for checksumming (authenticated encryption is a side benefit). I saw that these days, cryptsetup luksFormat allows for combining dm-integrity and dm-crypt by using the --integrity switch. The manpage warns though that this switch is still experimental. But … it has been experimental for several years by now? Is it still unstable and dangerous to use?

And, what do you think about this strategy? Would you do this multi-filesystem setup, or stick to btrfs everywhere? (ZFS is not an option for various reasons.) And if you wouldn’t use the --integrity switch, how would you preserve data integrity?

.(a bit sleepy, apologies for brevity)

You may want to consider snapraid in addition to whatever device mapper or filesystem checksum flags you enable.

I’ve been wondering something similar. In another thread (Integrity validation for offline backups - #5 by CWin), a user suggested using gpg to sign the backup archive as one possible alternative to dm-integrity.

But I do think that dm-integrity is a reasonable way to go, the only downsides are:

  • dm-integrity does not save the hashing algorithm used on the actual integrity header block :roll_eyes: so if you use something other than the default, you’ll need to also write that down somewhere and store that information with the backup.
  • dm-integrity is only readable from Linux

Both of those may or may not matter to you.

I anyway only access those disks from Linux. My main worry is that the manpage marks the --integrity switch as experimental. However, it seems to me that the experimental status is in place not because of stability but because of potential security concerns.