tklbam local backup escrow keys

I have configured tklbam and use local storage for my backups (as described here). It is not clear to me if I need to store the keys everytime I do a backup. I use:

tklbam-escrow -P /local/storage/key

Do I need to do this everytime I execute the following? Or is doing it once enough for all backups on that machine?

tklbam-backup --address file:///local/storage/backup

In fact, it is not exceptionally clear to me what the escrow key is. Honestly, I would prefer to store my backups uncrypted (i.e. using the --no-encryption option with duplicity) because I don't need an extra layer of security on our local file server (where the backups are stored). As far as I know, there is no way to have tklbam send this parameter to duplicity. Is that correct?

Replies (7)

I'm not sure to be honest

Reply 1 2012-12-20

But the easy way to find out would be to test. Run a fresh backup without creating a new key and see if you can restore it (with the old key...) I guess I'd be a little nervious though even if it works. As is usual good practice for backups they should be regularly tested (ideally restoring to a fresh instance).

And AFAIK TKLBAM doesn't have an option to not use encryption but as it's open source you are always free to have a bit of a tinker! :) IIRC the code is in the TKL GitHub repo.

IMO though unless you have huge amounts of data and/or really slow internet then using the Hub is the go - at $0.14/GB/mth it is really cheap!

I've got pretty much the same answer as before...:)

Reply 2 2014-11-06

As I have never used TKLBAM with local storage I can't be sure... When you use the Hub you only need to use an escrow key if you password protect your backups and want to have a failsafe (in cause you forget your password). And the one key applies to all your backups. The Hub automagically takes care of the encrytion of files etc.

When running TKLBAM 'manually' (i.e. not linked to the Hub) you don't have the advantage of the Hub taking care of backup locations and encryption. So my suspicion is that you would need to create a new key each time and that they are individual keys which relate to just one backup.

But like I suggested above, why not try it? Then you'll know for sure...

You're right. One key per

Reply 3 2015-11-09

You're right. One key per server works for multiple backups from the same server.

Great, thanks Nelson

Reply 4 2015-11-07

Thanks so much for posting back. When you say "you only need to create a single key and you can use it for any of the backups you make" I assume that means that a single key covers multiple backups from the one server. I'm guessing that wouldn't cover multiple servers though?

Thanks for the kind feedback.

Reply 5 2016-08-03

Glad to hear that it's working out for you.

TBH I'm not sure if it would be an issue or not to do both local and remote backups. Seeing as the Hub only keeps track of the S3 stored backups, I don't see why it would be a problem. Although only testing will confirm for sure whether it'd be ok.

However, what you could do (that definitely wouldn't be an issue) is create your own custom cron job which does both the local and remote backups. If you check out the tklbam-backup docs you can see that the backup can be split into a backup dump ('--dump=DIR') and upload ('--raw-upload=PATH'). You could insert a step between the 2 commands to archive the directory to a local file location.

Out of interest, possibly another option

Reply 6 2016-08-04

I just stumbled across some info that you should find useful: /faq/backup-and-migration-tklbam#t601n5478

It discusses creating 2 different profiles (for a "complete" backup and a "light" backup) but you could probably apply the same logic to use different backup backends. See also /faq/backup-and-migration-tklbam#t601n2384

Great!

Reply 7 2016-08-09

Glad to hear that it appears to be working out so far and thanks for posting back! Look forward to hearing about it going live! :)