Differences

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

--- rethinking_my_backup_strategy [01.01.2021 23:05] – [First POC - Burp + rsync] Pascal Suter
+++ rethinking_my_backup_strategy [01.01.2021 23:32] – [offsite backup file encryption] Pascal Suter
@@ Line 84: / Line 84: @@
     * ''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
+  * 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.
@@ Line 93: / Line 93: @@
   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 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 :)