rethinking_my_backup_strategy

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revisionBoth sides next revision
rethinking_my_backup_strategy [01.01.2021 23:23] – [First POC - Burp + rsync] Pascal Suterrethinking_my_backup_strategy [14.04.2021 05:12] – [Restic] Pascal Suter
Line 38: Line 38:
 [[https://github.com/restic/restic|Restic]] seems to be an awesome tool that does almost everything i want my new backup tool to do.. Most importantly, it creates client-side encrypted incremental backups of your servers and can then store it to a broad range of storages available including S3 compatible storages etc. This is all very nice, **BUT** it is run on the client side only, which menas, if a hacker gains control over your server and decides to encrypt or delete your date, he can simply delete all your backups and you are screwed.. so it sadly fails our security requirements.. but maybe it could be used as the client side of my backup solution, with a server that prevents deleting old backups from the client.. this will need some further research [[https://github.com/restic/restic|Restic]] seems to be an awesome tool that does almost everything i want my new backup tool to do.. Most importantly, it creates client-side encrypted incremental backups of your servers and can then store it to a broad range of storages available including S3 compatible storages etc. This is all very nice, **BUT** it is run on the client side only, which menas, if a hacker gains control over your server and decides to encrypt or delete your date, he can simply delete all your backups and you are screwed.. so it sadly fails our security requirements.. but maybe it could be used as the client side of my backup solution, with a server that prevents deleting old backups from the client.. this will need some further research
  
- +==== dar ==== 
 +[[http://dar.linux.free.fr/|dar]] is a tool i have to take a closer look at.. it is used in various other backup software as an alternative to rsync and provides backup images which means we can retain permissions in backups even with only unprivileged access to the target storage. this would allow to implement a backup script that creates a backup to a write-only share which is then made available read-only for future use, hence protecting it from a possible attacker with control over the backup target. the big question is, how do they handle incremental backups with regards to rotating old backups and restoring backups. there is a decremental backup method available too (where the full backup is always the latest and then decrements (file states before they where changed to the current state) are saved for older backups). decrementals obviously create a lot of load at the end of a backup and will probably not work when older backups are read-only.. so this might be tricky. 
 ===== possible solutions ===== ===== possible solutions =====
 ==== Burp ==== ==== Burp ====
Line 100: Line 100:
  
 ==== offsite backup file encryption ==== ==== offsite backup file encryption ====
-since all files are encrypted on the client side before they are sent to the backup server, we don't have to encrypt them again when uploading them from the backup server to the offsite backup. this basically removes all the challenges mentioned in the "self made" backup +since all files are encrypted on the client side before they are sent to the backup server, we don't have to encrypt them again when uploading them from the backup server to the offsite backup. this basically removes all the challenges mentioned in the "self made" backup solution above.  
 + 
 +==== restore from an offsite backup ==== 
 +here is how i have tested the restore-ability of an offsite backup in case we have completely lost the backup server in between.  
 +  - set up a new burp backup server with the same client config  
 +  - setup a new client or delete the certificates if the client is still there and should be re-used 
 +  - using ''burp -a l'' execute the initial connection between the client and server and let burp create all the SSL keys.  
 +  - using ''rsync -aAHhvXxR --numeric-ids'' copy the desired backup to the ''/var/spool/burp/<client name>/<backup name>'' folder where ''backup name'' is identical to the one stored on the offsite server.  
 +  - now use ''burp -a l'' again and you should see the backup listed  
 +  - restore using ''burp -a r -b 5 -d /'' or a similar command, depending on your situation to restore the specified backup 
 + 
 +this worked flawlessyl in my test, of coures as long as I still had the **encryption password** available from somewhere! .. needless to say, if you don't store your encryption password your backup is completely useless, so make sure your encryption password is saved somewhere where you will still have it, even if you loose the client, and of course, don't store it together with the backup on the backup servers :)  
  • rethinking_my_backup_strategy.txt
  • Last modified: 12.08.2021 17:42
  • by Pascal Suter