I am keen on privacy and security. Whenever i format a disk I format it encrypted.
I have a new drive to use with Pika (borg based) backup utility. My default process is to format the drive encrypted, but in Pika it offers to ‘encrypt backups’.
Am i wasting time encrypting the disk AND choosing to encrypt backups? Does it add any extra security to do both?
No. With an encrypted disk, you need to enter the password once when you startup, and thereafter the decryption is transparent - all the processes running on your system just read decrypted data in the same way as if they were reading from an unencrypted device.
So if you had an encrypted disk:
The LUKS encryption would never carry through to the backup, so Pika / Borg’s encryption is indeed adding security.
Thank you. But I was asking more the other way around. I will always choose to encrypt backups in Pika, but am I wasting time encrypting the disk when formatting before using with Pika?
Ah I see, sorry I misinterpreted your question (I was thinking about LUKS encryption on your “source” disk rather than the backup target).
In this case I don’t think it adds much to do disk-level encryption on the backup disk, as long as you’re encrypting in Pika.
Ah, yes sorry. I bought a 2TB toshiba USB HDD for backups. I needed a second one (bigger). So it just arrived. I format it for use on Linux, and (being unsure) I always lean towards encrypting because 'why not’! It’s an external drive that will live in a fire safe when not running backups.
So I was just wondering (after doing so for years) if my ignorance is causing me to waste time encrypting the external drive when the backups themselves are encrypted anyway. I don’t mind doing it, and will continue to do it IF there is the slightest modiocum of additional security/privacy by doing it. But if not, I guess I can stop doing it!
that was the point of the post 
My bad for not reading closely enough 
To nuance what I said before, you could argue that there is a slight security gain.
If the disk is unencrypted, then an attacker can see the structure of your backups (directory structure, file sizes etc[1]), even though the files that contain your backed-up data are encrypted. It’s conceivable that that information could make an attack easier. (This attack is an example of that kind of thing, loosely speaking - but it needs more than the attacker just having access to your Borg backups, they’d need to have prior knowledge of some of that data in your backup.)
If the backup is on an encrypted disk, then the attacker can’t see the files that make up your encrypted backup. Without the disk encryption password, all they see is an encrypted volume that gives them essentially no information (other than the size of your disk or partition I guess).
Personally though, I use Restic and don’t lose sleep over not encrypting the disk that the backups are on.
Not the sizes of your actual backed up files, but those of the files in which Borg, Restic etc stores the backed up data ↩︎
By encrypting the disk you prevent a bad actor from seeing meta data about what is on the drive. The meta data is things like filenames and give clues to what you are storing on a drive.
Personally I use encrypted drives and in the clear backups.
I find it is easier to work with in the clear backups when a restoring from backups.
Very interesting thanks
Hmm. That’s an angle I hadn’t thought about!
So you’re happy that JUST encrypting the disk perfectly secures everything on it (and metadata)?
I can see why it might make restoration easier (never had to do that yet). So just one password you have to enter whenever you connect the drive to any machine, and then you have full access to the data.
I am tempted to ask if that’s any LESS secure than ALSO encrypting the backups themselves, but I wont 
thanks
When the disk is at rest the luks encryption with a strong password is good enough.
Tip: test you can restore a file from your backups and takes notes on when the steps needed where. A backup you have not restored from means you do not know if the backup is valid.
I am not sure if mine have ‘LUKS’ encryption. I just choose to format it ‘for use only with Linux’ and tick encryption.
Restoring - I have never tried but I think I browsed the files. I was used to (spoiled by) TimeMachine on Mac. I guess on Pika I just browse and drag and drop the files?
I will have a go later when at machine again
You wil have LUKS encryption - that the linux standard.
WHen you have your backupo driver mounted have a look at the output of lsblk -f and you should see a luks and crypt mentioned in the output.
I’m not a pika user, I use duplicity, and cannot advise on how to test a restore.
FYI I setup duplicity to do incremental backups on the hour to get a Time Machine style of backup.
Thanks. I looked at Duplicity but it’s CLI so I will stick with Pika Thanks for the help here guys
Just make sure you set your expiration and frequency/retention parameters appropriately!
i dont use any of that, it got me in the 5hit I am in now as the drive filled up! I just have ONE backup now, full system backup, back in safe!
And yet if you had set-up an expiration timeframe you would not have been in any kind of detritus at all.
My recommendation to you, and I urge you to consider this, is ascertain what you consider to be essential and back it up daily… less essential but one could live with it, less frequently… adjust “frequently” as you see fit. Only you can decide what that is.
Your backup strategy is only good if it works for you. Looks at those pika backup expiration policies and determine if they are are useful for your use case - they are entirely useless for me but for you… perhaps perfect. Set something up bespoke for you and you have no-one to bitch at when they let you down.
Do you use Pika? If not I’d suggest you try it out. The archive retention policies firstly make very little sense, secondly don’t work properly as I tried to do exactly what you suggest, many times. It just seems to keep random numbers and fills up, or I cut it down to one and know it can’t go oversized and cause the full up problem i had.
I have of course thought through what I need. I need NO increments. I need to just know I have a full last save in case my laptop is stolen or lost etc. Nothing more necessary
There are some security benefits to the double-layer encryption, but if the passphrase to unlock both layers is the same, then it negates most of the benefits.
But a more important consideration is restoring data. When – not if – the drive experiences media errors that result in filesystem corruption, unpacking a corrupted LUKS partition (which in turn means the Pika/Borg archives are also corrupted) will be a big headache.
Thanks. The passphrases are different, and very complex. (Diceware level or thereabouts).
Your second comment is interesting but a bit beyond my understanding. Are you saying the DRIVE encryption causes that headache, or the Pika/Borg backup encryption?
I suspect you’re saying the drive level encryption adds the headache, if so I will just go without. I don’t have any nuclear secrets on the drive, I just like security if I can have it without risk/cost, and this headache sounds like a very real risk/cost making it wiser to go without encrypting the drive. Would you agree with my understanding and overall thoughts on it?
I backup to a pair of 4T USB3 drives and alternate which I use.
Then if one drive fails I have the other with a backup.