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 22:42] – [First POC - Burp + rsync] Pascal Suter
Line 72: Line 72:
     * it would be nice to be able to mount an entire backup, or even all backups at once, via for example sshfs. One could then remount it using gocryptfs on the client to see a decrypted representation. however, this brings another isse: the mount should be read-only, so that a hacked client can't destroy existing backups on the backup server. so either we find a way to create a read-only share using for example NFS (possibly tunnelled over ssh) or we find a way to make them read-only on the backup server already before sharing them through sshfs.      * it would be nice to be able to mount an entire backup, or even all backups at once, via for example sshfs. One could then remount it using gocryptfs on the client to see a decrypted representation. however, this brings another isse: the mount should be read-only, so that a hacked client can't destroy existing backups on the backup server. so either we find a way to create a read-only share using for example NFS (possibly tunnelled over ssh) or we find a way to make them read-only on the backup server already before sharing them through sshfs. 
     * 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 /var/spool/burp/./*/current/ rsync:%%//%%user@offsite/current0'' to write backups to the offsite server
 +  * 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.
  
  
  • rethinking_my_backup_strategy.txt
  • Last modified: 12.08.2021 17:42
  • by Pascal Suter