| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision |
| rethinking_my_backup_strategy [01.01.2021 23:32] – [offsite backup file encryption] Pascal Suter | rethinking_my_backup_strategy [08.08.2021 00:21] – [Burp] Pascal Suter |
|---|
| [[https://www.borgbackup.org/|Borg]] is a very smart and capable backup solution with lots and lots of features and most importantly, block level deduplication. It can do a lot more than what I need, **BUT** it sadly does not allow to create a user that can only write new backups but not delete old ones as well. While there is a ''append-only'' policy available, it is impractical to rely on it, as one has to either forget about automatic purging of old backups. That's the deal breaker for me. Read more about this in the [[https://borgbackup.readthedocs.io/en/stable/faq.html#how-can-i-protect-against-a-hacked-backup-client|FAQ]] and the [[https://borgbackup.readthedocs.io/en/stable/usage/notes.html#drawbacks|Drawbacks of append-only mode]] | [[https://www.borgbackup.org/|Borg]] is a very smart and capable backup solution with lots and lots of features and most importantly, block level deduplication. It can do a lot more than what I need, **BUT** it sadly does not allow to create a user that can only write new backups but not delete old ones as well. While there is a ''append-only'' policy available, it is impractical to rely on it, as one has to either forget about automatic purging of old backups. That's the deal breaker for me. Read more about this in the [[https://borgbackup.readthedocs.io/en/stable/faq.html#how-can-i-protect-against-a-hacked-backup-client|FAQ]] and the [[https://borgbackup.readthedocs.io/en/stable/usage/notes.html#drawbacks|Drawbacks of append-only mode]] |
| ==== Burp ==== | ==== Burp ==== |
| [[https://burp.grke.org/|Burp]] is the best backup tool i know to make backups of clients that aren't available 24/7 such as workstations or even notebooks. it also supports linux, windows and Mac OS. Burp actually does pretty much anything I want and a lot more out of the box. the only draw back that i found so far is, that it seems rather difficult to create secondary backups. there is an offsite-backup script but it says in the header of the script, that it doesn't quite work.. the main issue seems to be the fact, that burp moves the full-backup always along to the youngest backup and only keeps the previous versioins of changed or deleted files stored in the previous backup's data directory. this makes it very easy do purge old backups of course, but it is a little trickier to create secondary backups.. i haven't tested if this can be overcome by using hardlinked backups ( a config option in burp ) though. burp also supports client side encryption which breaks delta uploads of modified files. At the end of the day, burp provides no real advantage to me over using a combination of some other tools and some custom scripts to glue them together, but it adds complexity mainly to the offsit backup part instead and it adds potential security risks by setting wrong configuration options. Still, it is a complete and running software and would probably save some time on my end, and it offers so many more features which i currently don't use (like windows backups) but that might come in handy in the future. | [[https://burp.grke.org/|Burp]] is the best backup tool i know to make backups of clients that aren't available 24/7 such as workstations or even notebooks. it also supports linux, windows and Mac OS. Burp actually does pretty much anything I want and a lot more out of the box. the only draw back that i found so far is, that it seems rather difficult to create secondary backups. there is an offsite-backup script but it says in the header of the script, that it doesn't quite work.. the main issue seems to be the fact, that burp moves the full-backup always along to the youngest backup and only keeps the previous versioins of changed or deleted files stored in the previous backup's data directory. this makes it very easy do purge old backups of course, but it is a little trickier to create secondary backups.. i haven't tested if this can be overcome by using hardlinked backups ( a config option in burp ) though. burp also supports client side encryption which breaks delta uploads of modified files. At the end of the day, burp seemed to provide no real advantage to me over using a combination of some other tools and some custom scripts to glue them together, but it adds complexity mainly to the offsite backup part instead and it adds potential security risks by setting wrong configuration options. Still, it is a complete and running software and would probably save some time on my end, and it offers so many more features which i currently don't use (like windows backups) but that might come in handy in the future. |
| So maybe my final solution could be writing a offsite-bakckup for burp to comlete the requried feature set for me :) | So maybe my final solution could be writing a offsite-bakckup for burp to complete the required feature set for me :) |
| ==== Restic ==== | ==== Restic ==== |
| [[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 ==== |