i'm currently thinking about how to set up an offsite backup in a secure manner. there are essentially two options i'm considering: * encfs reverse filesystem, then rsync the encrypted files to offsite * luks encrypted offsite storage, rsync the unencrypted files (still over a secure channel obviously)
my goal is to prevent anyone except me to view my files.
encfs: + files are encrypted before they leave the onsite location + i've used it successfully before and know how it works - encfs has security issues if an attacker has repeated access to encrypted files - encryption on a per-file level - makes incremental updates difficult or impossible (?)
luks: + solid encryption (?) + encryption below filesystem level - needs password entry over network on each boot (so no fully automated boot possible) - files are only encrypted at offsite location (they are in the clear in offsite memory or with offsite OS access)
notes: * I don't need to encrypt the root partition of the offsite server, encrypting the raid disks is enough * offsite server has usb port inside case for an usb key boot partition (maybe needed for luks) * offsite server has case-open detection switch ("tamper switch") * I can't inspect the server on a regular basis, but I can do so occasionally (every 2-3 months) or when I suspect something is wrong, or when a harddisk fails
attacker model: "incompetent hardware access" * attacker can do everything on the network, but i'm planning to use ssh or vpn or something anyway * attacker has hardware access since it's offsite * attacker has access to harddisks I throw away when they fail * attacker can shutdown/disconnect server * attacker cannot open case without shutting down server (tamper switch) * attacker cannot disconnect server power without shutting down server (tamper detection) * attacker cannot disconnect/remove harddisk while server is running without triggering a warning (either because of network disconnect or because of raid degradation)
encfs additional drawbacks on attacker model: * attacker does not repeatedly read out harddisk contents and can determine file contents via encfs shortcomings (one-hit attacker only)
luks additional drawbacks on attacker model: * attacker is not byzantine, as in he would not cut open the side of the server and access the memory or hardware bus from there while server is running.
Can you recommend one setup over another? Which one makes more sense? Is there some problem with either setup i haven't taken into account? Is the attacker model realistic? Anything i should change? Something else than rsync?
And, most important to me: How have you set up your offsite backups?
My offsite backups are rather simple, I create a local PGP-encrypted backup with duply and then sync the backup data with an Amazon S3 bucket via aws-cli. My backup is only about 100G, with infrequent access storage the total cost is less than $3/month.
>>3663 >these are all encrypted filesystems yes. they are used to encrypt files. > they aren't backup programs that's what rsync does. is there a reason *against* using different tools for these two tasks? > just use duplicity maybe when they release a stable major version and are not under ongoing development anymore. For backups, some people prefer not to use software still in pre-release.
>>3671 >processes it in little chunks note that the duplicity website states that they sometimes use up a lot of temp space too.
>>3663 >duplicity does it support synchronizing filesystems, without versioning or increments? as in, just have the same data (plus/minus encryption) on two servers?
The problem is that incremental takes up same-or-more space than just a duplicate which takes up same space. Which would create the need for more diskspace on the offsite storage than on the onsite storage, and it is difficult to tell in advance how much (as in, at harddisk-buying time).