# Backup Using Borg
https://borgbackup.readthedocs.io/

## Reasons I use Borg:
- Deduplication
- Encryption (I use BLAKE2b-256)
- Multiple compression options (I use LZ4)
- Easily accessible
- FOSS
- Preserves most file types, attributes, etc.
- Can verify data integrity with CRCs and HMACs

## Script Notes
### Passphrase 
- I do NOT want the encrypted passphrase in cleartext within the script.  
- I also do NOT want to set an environment variable with env command or system() to avoid exposure in the process list.    
- Instead, I use BORG_PASSCOMMAND with a dotfile with specific permissions. 'export' in a shell script uses a process environment only accessible to that user.
### Package Lists
- At the moment I only use Arch and Ubuntu/Debian systems, so the package list dump only checks for these. This can be expanded as needed.
- Since I don't backup the entire system, I'd rather just do a quick dump of packages and script a reinstall as needed.
- This would be obsolete with Ansible (which I will ideally use later down the line).
### Backup Locations
- I generally do not care to backup the entire system, and only want things in /home or configs (usually in /etc)
- I use a case statement to add or remove things as needed per system. Probably not the most efficient and it's a bit ugly, but it's very clear/easy to read, debug, and modify as needed.
### Why do you copy files and directories to /home?
- I'd prefer to avoid using root when possible, especially since I don't want to backup the entire system.
- If I'm only copying /home and config files, I don't see a reason to use root, and would rather just use a local user.
- HOWEVER, there should not be a concern with using root. The networking is done by SSH and RPC, not Borg. If there is a security concern, it would be with SSH and RPC, which is probably an acceptable risk.
- Since I'm ideally only copying config files, there should not be an issue with duplicated space or long copy times from (example:) /etc to /home.
- I'm also using single-user systems. If these were multi-user systems, there might be another discussion since there would need to be a "/home admin" that could access all files in /home.
### Why do you use a locally mounted remote file system instead of Borg's client/server mode?
- Mixture of laziness and old habits. Borg has made it easier to use client/server mode without mounting drives, and I just haven't kept up with the times.
- I will ideally be modifying this to use client/server mode in the future.
- Nothing particularly *wrong* with using a mount, it's just slower since every operation has to go over the network.
### Sudo
- If sudo is used in the backup script (like I do when stopping/starting certain services), it is recommended to put NOPASSWD for that specific command for that specific user in a /etc/sudoers.d/\<appropriately_named_config_file>
- Putting the permissions in the sudoers.d file is recommended for a few reasons:  
&nbsp;1) Those config files stay on upgrades, while content added to /etc/sudoers may not  
&nbsp;2) PAM authentication reads and respects it. If you put the same info in just the sudoers file, PAM conversations may (and likely will) still fail
- It is recommended to not run the entire script as sudo, and it's also recommended to give nopasswd to only specific commands and not to all sudo prompts

## Automation
- Automation is done with systemd, but cron can be used if preferred.
- Change the times and users for each system. If not running as root, be sure to replace systemd unit user variables with the actual user of the system.
- I have no need to have the drive mounted full time (backups are on NFS mounts only used for backups), so I also have systemd mount the drive for the backup, then unmount when done. Be sure to change the drive mount as well for each system.
- For the mount service, the unit name and 'Where' setting MUST match. For example, for "Where=/mnt/mountpoint/backups", the unit must be named mnt-mountpoint-backups.mount
- I set specific backup times in the timer unit rather than a random time +- midnight (OnCalendar=daily with a RandomizedDelaySec) so I have predictable, known times when things may be down.
- The timer and service must have the same name (except for the .service and .timer part of course).

## Setting up
### Client
- Install borg backup
- Install nfs-common
- Obtain all systemd files, and move them to /etc/systemd/system
- Enable the timer unit
- Temporarily mount the backup folder to initialize the borg repo for first-time use (borg init --encryption repokey-blake2 /path/to/repo)
- Save the key