You are here
codyzu - Wed, 2012/12/19 - 13:08
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?
Forum:
Tags:
I'm not sure to be honest
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...:)
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...
Great, thanks Nelson
You're right. One key per
You're right. One key per server works for multiple backups from the same server.
Thanks for the kind feedback.
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
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 https://www.turnkeylinux.org/faq/backup-and-migration-tklbam#t601n2384
Great!
Add new comment