I keep all my backups on an LUKS-encrypted external RAID 1 setup. I have to make some changes to the partitioning which I expect to take a few days (~10TB of data), so I purchased a UPS and set up hibernation to be safe. (Don’t worry I’ll take a backup prior)
Hibernation seems to work great with everthing except the single thing actually I need it for. Upon rebooting, everything is in the same state in which it was left. However, the second I interact with anything which attempts to re-mount the encrypted RAID setup, the entire system freezes and requires a full reboot. There is a small unencrypted partition on this drive, and it is not affected by the issue. Both of these partitions are set up as nofail in fstab with a static mount point.
Anyone got any ideas to solve this? Or is this an inherent limitation of hibernation with external LUKS drives?
For the time being, I will configure apcupsd to suspend, rather than hibernate my computer. I did some testing: the RAID array and my computer on suspend pull a combined 1w load according to my UPS, meaning I should theoretically get plenty of time for the power to come back on and for my hard drive operations to resume. In practice the difference between 1w and 0 shouldn’t make a real difference for my use case.
I’m still open to any suggestions for the original problem. It may help someone in the future if there is a solution that can be found.
I would not rely on hibernation with an external encrypted RAID mounted. The device-mapper state is restored from RAM, but the USB/SATA bridge and the drives have gone through their own power/reset cycle, so the first real I/O after resume can be the ugly part.
For this job I would keep your suspend + UPS plan, and if you want to test hibernate later, make the rule: unmount the filesystem, cryptsetup close the LUKS mapping, then hibernate. After resume, unlock and mount it again. Less convenient, but much safer for a 10 TB backup/partitioning operation.