I’ve been using veracrypt for the past 4 years to create container files in everything from thumb drives to external hard drives. After upgrading one of my backup drives, I decided that I will switch to a different filesystem altogether, from ntfs to ext4, since I havent really used windows in those 4 years. With the reasoning behind using veracrypt and ntfs in the first place being for compatibility, should I switch to LUKS? Veracrypt is dramatically more feature rich but I dont really take advantage of those. I just encrypt my drives in case of burglars and other unwanted eyes. I do already have a disaster plan in place so I would have to do a total rehaul of things, but I’m not sure this is a wise decision.
I’m by no means a security expert, but I encrypt all my drives with LUKS on ext4 (or btrfs with the system drive on Fedora). I have a similar use case to yours, so i would be interested in your disaster plan as you call it.
Oh by disaster plan I mean incase of drive failure/my death. Its the 3,2,1 backup rule basically. 1 original backup drive and a copy of it are local in a fire resistant box within a bolted down safe, then an offsite cold copy of my backup drive is at a loved one’s home where backups are manually updated monthly. The more important data is also stored in the cloud with cryptomator just as more insurance for myself. A laminated paper with credentials needed to access the data is stored in 2 places, another loved one’s home in their safe (cloud provider account credentials opted out) with instruction in case I die, and hidden local in case I forget anything.
This is exactly my backup strategy even using cryptomator for a cloud backup. My PC and kiddos laptops are all linux so have no worries about needing a Windows machine for recovery and even if all systems died I could always use a live distro to boot elsewhere and access my files.
LUKS is a great option, but as someone who was in your exact shoes, and went from TrueCrypt to VeraCrypt to LUKS, I eventually landed on ZFS.
It’s just so, easy. Make an encrypted Zpool on your main /storage disk. Assign a /storage/documents (or whatever you want), Make another Zpool on your /backup disk, and use zfs snap and send to copy only the bit level data that changes.
So fast, so little disk access, and you can manage snapshots. There is even copy-on-write meaning file recovery is easy, too. I use it to send over SSH to a remote server, too.
The only change I would recommend looking at is using a backup tool like restic, which can encrypt and also provide snapshots. Restic (and ilk, I’m sure) also deduplicate incremental backups, can compress, and (restic, at least) can mount snapshots. That last feature has been so helpful to me, because it allows easy access to individual files in a snapshot.
Restic also supports a number of cloud storage backends, like BackBlaze, which makes offsite storage hella easier than carting physical media around.
There are a couple of these sorts of tools, and while I’m most familiar with restic, I’d guess they have similar capability. I’d suspect using one would simplify your set-up.
I’d choose LUKS over Veracrypt for simplicity. If the drive is solely for backup, depending on the backup tool you use, you might not even need encryption on the file system level. Several backup solutions support data encryption.
If this is for live disks or mirrors (not backup), LUKS is reasonable. Backup is different from mirroring since one of the things it protects you from is accidentally deleting files. If you delete a file from your main drive, it also disappears from the mirror drive, so mirrors are not backup. For encrypted backup, I’ve been using Borg backup which is quite well thought out, though confusing at first. The backups go on a remote server which is ok since they are all encrypted.
