From e855310ec602bf86c42396580dfad1d0eb62dcc9 Mon Sep 17 00:00:00 2001 From: noah Date: Mon, 31 Oct 2022 01:17:12 -0500 Subject: [PATCH] Adding systemd units and notes --- README.md | 25 ++++++++++++++++++++----- borg-backup.service | 9 +++++++++ borg-backup.timer | 8 ++++++++ mnt-mountpoint-backups.mount | 10 ++++++++++ 4 files changed, 47 insertions(+), 5 deletions(-) create mode 100644 borg-backup.service create mode 100644 borg-backup.timer create mode 100644 mnt-mountpoint-backups.mount diff --git a/README.md b/README.md index b3a7afc..13724ef 100644 --- a/README.md +++ b/README.md @@ -13,8 +13,8 @@ https://borgbackup.readthedocs.io/ ## 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 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 the user. +- 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. @@ -25,9 +25,24 @@ https://borgbackup.readthedocs.io/ ### 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 pretty minimal. -- Since I'm ideally only copying config files, there should not be an issue with duplicated space or long copy times. +- 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. \ No newline at end of file +- 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/\ +- Putting the permissions in the sudoers.d file is recommended for a few reasons: + 1) Those config files stay on upgrades, while content added to /etc/sudoers may not + 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). \ No newline at end of file diff --git a/borg-backup.service b/borg-backup.service new file mode 100644 index 0000000..291bd14 --- /dev/null +++ b/borg-backup.service @@ -0,0 +1,9 @@ +[Unit] +Description=Borg Backup +RequiresMountsFor=/mnt/mountpoint/backups + +[Service] +Type=oneshot +User=gameadmin +Group=gameadmin +ExecStart=/home/gameadmin/scripts/borgBK.sh \ No newline at end of file diff --git a/borg-backup.timer b/borg-backup.timer new file mode 100644 index 0000000..0085ad0 --- /dev/null +++ b/borg-backup.timer @@ -0,0 +1,8 @@ +[Unit] +Description=Run Borg backup daily + +[Timer] +OnCalendar=*-*-* 16:00:00 + +[Install] +WantedBy=timers.target \ No newline at end of file diff --git a/mnt-mountpoint-backups.mount b/mnt-mountpoint-backups.mount new file mode 100644 index 0000000..0337452 --- /dev/null +++ b/mnt-mountpoint-backups.mount @@ -0,0 +1,10 @@ +[Unit] +Description=Backup Mount +StopWhenUnneeded=true +BindsTo=borg-backup.service + +[Mount] +What=192.168.1.21:/home/storageadmin/backups/GameSrv +Where=/mnt/mountpoint/backups +Type=nfs +Options=defaults