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 22:12] – [self-made collection of other tools] Pascal Suterrethinking_my_backup_strategy [01.01.2021 23:23] – [First POC - Burp + rsync] Pascal Suter
Line 73: Line 73:
     * i have found [[https://github.com/zaddach/fuse-rsync|fuse-rsync]] which allows mounting an rsync module via a fuse mount. however, this is merely a proof of concept that has not been developed any further in the past 7 years, so not really an option here.      * i have found [[https://github.com/zaddach/fuse-rsync|fuse-rsync]] which allows mounting an rsync module via a fuse mount. however, this is merely a proof of concept that has not been developed any further in the past 7 years, so not really an option here. 
  
 +===== First POC - Burp + rsync =====
 +with all the arguments above considered, I decided to proceed a burp based solution and just add off-site capabilities to burp. Here is the targeted setup: 
 +  * "Local" backup server running burp in server mode with the following key settings: 
 +    * ''hardlinked_archive = 1''
 +    * ''client_can_delete = 0''
 +    * ''user=jdoe'' and ''group=jdoe'' where ''jdoe'' is some unprivileged non-root user
 +    * one needs to make sure that all the necessary paths mentioned in ''burp-server.conf'' and ''CA.cnf'' are writable and or readable by the unprivileged user who's running burp
 +  * "Remote" backup server, running a rsyncd service which shares a single directory i.e. ''/backups/current'' 
 +  * clients run the burp client and use client-side encryption with a strong password. the following additional core settings are used: 
 +    * ''server_can_restore = 0''
 +    * ''server_can_override_includes = 0''
 +  * a script on the burp server uses ''rsync -aAhHvXxR --numeric-ids --delete ...'' sync the latest backups stored in ''/var/spool/burp/<client name>/<backup timestamp>'' where ''backup timestamp'' is the target of the ''current'' symlink in the same directory. so a script which uses something along the lines of ''readlink'' should find the ''current'' backup which was just completed and then rsync this to the offsite server's ''current directory''
 +  * on the offsite server, a script is called (somehow, haven't figured out yet how exactly this will be done) after the rsync from the burp server successfully finished. the script will use ''cp -alx /backups/current /backups/`date +%Y.%m.%d-%H%M`'' to create hardlinked copies of the current directory. by using this script, we can avoid to use the ''%%--%%link-dest'' option of rsync which in turn would make it necessary to at least include the latest completed backup also in the writable share.
  
 +to try it all out i used a bunch of [[ubuntu test docker image | ubuntu test docker containers]]
 +
 +  docker network create burp
 +to create the custom network 
 +  docker run --net burp --name burpsrv -ti ubuntu-test:latest
 +to create the container for the burp server, and similar commands for the other servers. 
 +
 +for testing i ran the burp server with this command line: 
 +  burp -v -F -c /home/jdoe/burp/etc/burp-server.conf
 +
 +which outputs any logs directly to stdout and keeps the daemon in the foreground. 
 +
 +==== 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 
  • rethinking_my_backup_strategy.txt
  • Last modified: 12.08.2021 17:42
  • by Pascal Suter