my_new_backup_solution_with_burp

Differences

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

Link to this comparison view

Next revision
Previous revision
my_new_backup_solution_with_burp [20.09.2021 21:44] – created Pascal Sutermy_new_backup_solution_with_burp [04.02.2026 11:32] (current) – [Offsite-Backup server] Pascal Suter
Line 65: Line 65:
 with this set to 1, an attacker could potentially push data to the client by forcing a restore of a tampered backup or they could simply erase data by restoring an old version of certain files. we don't want that!  with this set to 1, an attacker could potentially push data to the client by forcing a restore of a tampered backup or they could simply erase data by restoring an old version of certain files. we don't want that! 
  
-===== first start =====+====== first start ======
 start burp on the backup server start burp on the backup server
   systemctl enable --now burp    systemctl enable --now burp 
Line 81: Line 81:
   0,20,40 * * * * /usr/sbin/burp -a t -q 1200 >>/var/log/burp-client 2>&1   0,20,40 * * * * /usr/sbin/burp -a t -q 1200 >>/var/log/burp-client 2>&1
  
-===== setup a backup report script ===== +====== setup a backup report script ====== 
-i wrote a [[script to send reports on a daily basis]] listing all backups and their age. since burp does not run a backup of all machines at once, but rather lets the client machines start a new backup whenever it is due, we have to create a backup report independent of any running jobs at a fixed time of the day (or week). I personally like systems that also send an email when things are good. this assures that you will get the alert if one is needed. +i wrote a [[burp backup report generator script|script to send reports on a daily basis]] listing all backups and their age. since burp does not run a backup of all machines at once, but rather lets the client machines start a new backup whenever it is due, we have to create a backup report independent of any running jobs at a fixed time of the day (or week). I personally like systems that also send an email when things are good. this assures that you will get the alert if one is needed. 
  
 +====== offsite backup solution ======
 +theoretically one could probably use burp to create an offsite backup of another burp server. However, i wanted something different, so in case there is a security issue with burp, the offsite backup would not automatically be compromised as well. 
  
 +I chose to use a combination of rclone on the offsite machine and sftpgo on the burp server. Basically sftpgo is a dedicated sftp server daemon. It does not have the full ssh functionality such as port forwarding, shell etc, it only allows file access. It also supports a few other protocols, but we will stick to sftp for now. Another advantage over just configuring a very limited user for our normal OpenSSH server is, that it sftpgo can also create read-only file shares, which is exactly what we want. 
  
 +So set up sftpgo and then configure a new user (which should not be a sytem user, it's an internal user of sftpgo). Then share the backup directorie(s) with read-only access to this user. 
  
 +now depending on your offsite backup machine, if it has a fixed ip address, you can create a more specific rule for ufw, that allows only access from this specific IP. This is not possible if your remote server has a dynamic ip of course. 
 +  ufw allow proto tcp from 172.16.28.1 to any port 2022
 +my offsite backup wrapper script for rclone will be able to work on multiple offsite backups at the same time, so make sure you allow enough concurrent connections on the sftpgo site. The default of 20 was not enough for 4 concurrent rclone downloads, i had to set it to something above 30. went to 100 and haven't had an issue since: 
 +  sed -i 's/\("max_per_host_connections":\) .*/\1 100/' /etc/sftpgo/sftpgo.json
 +  systemctl restart sftpgo.service
 +
 +====== Offsite-Backup server ======
 +on the offsite backup server, isntall the latest version of rclone
 +
 +then run 
 +  rclone config
 +to set up a new client. 
 +
 +add the backup  host and make sure that you pass the path to the unencrypted ssh key where it asks for the ''ssh_key'' and not the ''ssh_pem'' .. it is NOT the ''Raw pem-encoded'' key, it is just the ''pem-encoded'' key which was confusing to me :) 
 +
 +  rclone lsd planb:/
 +  
 +should now show our backups
 +
 +Now download my [[rclone wrapper to create offsite backups of a burp server]] and set up a cron job for it. (currently this script is a WIP, so come back later when it's done)
 +
 +===== Disaster Recovery fron the offsite backup =====
 +this is the process after we have lost it all.. say a fire has hit our facility and everything is gone except for our offsite backup or maybe even only the tape has survived
 +
 +==== Restore the "burp" backup server ====
 +we assume that we have a backup of our former burp server and that the backup name is "backupserver"
 +=== 1.) setup temporary burp server ===
 +for this tutorial we will use an ubuntu docker container as our temporary burp server to restore the actual backup server from it. 
 +
 +first from the offsite or tape backup, copy the ''backupserver'' subfolder to a temporary directory on the machine that is going to run the docker container. let's assume it is saved to ''~/tmp/burp_restore/backup/backupserver'' 
 +
 +start the docker container: 
 +  docker run -ti --rm -p 4971:4971 --name burp-server -v ~/tmp/burp_restore//backup:/var/spool/burp ubuntu:latest
 +
 +this will open a shell inside the container. In this shell, we will install burp and get the burp server configured and running: 
 +
 +  apt update && apt install burp
 +  sed -i 's/hardlinked_archive.*$/hardlinked_archive=1/' /etc/burp/burp-server.conf
 +  echo "password = abcdefgh" > /etc/burp/clientconfdir/backupserver
 +no joke, the password set here is the default in the sample client config, because we are lazy and this is a temporary server only, we will set it on the server side to match the client so we don't need to adjust it on the clinet later on :) 
 +
 +start burp server 
 +  burp -c /etc/burp/burp-server.conf -v -F
 +
 +
 +=== restore "backupserver" server onto future burp server ===
 +boot future "backupserver" burp backup server from an ubuntu desktop live stick. choose to ''try ubuntu'' rather than install it. 
 +
 +make sure it is connected to the same network as our burp docker container above. 
 +
 +open a shell and become root 
 +  sudo su - 
 +install burp 
 +  apt update
 +  add-apt-repository universe
 +  apt insatll burp 
 +  
 +temp0raryPW
 +
 +  sed -i 's/^server = .*$/server = <ip of machine running the docker container>/' /etc/burp/burp.conf
 +  sed -i 's/^cname = .*$/cname = backupserver/' /etc/burp/burp.conf
 +  sed -i 's/.*encryption_password =.*$/encryption_password = <encryptionPassword>/' /etc/burp/burp.conf
 +replace the "<encryptionPassword>" with the actual encryption password which you got to have saved somehwere, otherwise you can't restore this server anymore. if you have the encryption passwords for your other servers, follow this tutorial for each of them and you should be able to restore them at least. 
 +
 +run burp client to list the available backup. amongst all the lines of output there should be a line that start with ''Backup: ....'' which shows the backup number which we want to restore. 
 +
 +  burp -a l | grep "^Backup:"
 +
 +this should sow something like 
 +  Backup: 0000002 2021-08-09 06:04:07 +0200 (deletable)
 +where 0000002 is the number of the backup. 
 +
 +now restore ''/etc/fstab'' to find out what the partitioning of the new OS disk should look like if you are uncertain what the partitioning was. ''fstab'' won't tell you the partition sizes, use your own judgement for that, but it will give you an idea what partitions where mounted where. 
 +  burp -a r -b 2 -r "^/etc/fstab$" -d /tmp/
 +
 +NOTE, if the backup server is still a legacy booted machine, so there is no UEFI partition to be made, instead craete a 1MB "BIOS Boot" type id 4 partition at the begining of the partition table, then simply a root partition and a swap partition, that's it. 
 +
 +now format the root partition with ext4
 +
 +mount the root partitioin to ''/mnt/'' in your live linux session. 
 +
 +and now restore the backup to the new disk: 
 +  burp -a r -b 2 -d /mnt/
 +now chroot into the restored disk to setup the rest: 
 +  for d in dev sys proc ; do mount -o bind /$d /mnt/$d; done
 +  chroot /mnt/
 +use mkswap to format the swap partition 
 +  mkswap /dev/<target>
 +update the UUID's in fstab. for example, dump the uuid's into fstab, then edit the file and move them to the right place: 
 +  blkid >> /etc/fstab
 +  nano /etc/fstab
 +now install grub 
 +  grub-install
 +  grub-mkconfig
 +finally reboot and boot from the harddisk 
 +  exit
 +  umount /mnt/*
 +  umount /mnt
 +  reboot
 +
 +finally, stop the temporary burp server docker image, just press ctrl+c and then type exit. 
  
  • my_new_backup_solution_with_burp.1632167066.txt.gz
  • Last modified: 20.09.2021 21:44
  • by Pascal Suter