cjones/restic-automatic-backup-scheduler
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Let journalctl be the log file maintainer

Browse Source 
Fixes #3
This commit is contained in:
Erik Westrup
2018-08-26 15:54:35 +02:00
parent 8d023d0fe1
commit f50055f26a
4 changed files with 10 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
README.md
View File

@@ -51,7 +51,6 @@ Now see if the backup itself works, by running
```bash
$ /usr/local/sbin/restic_backup.sh
$ less /var/local/log/restic/*
$ restic snapshots
````
@@ -86,6 +85,14 @@ or start a backup manually
$ systemctl start restic-backup
```
You can follow the backup stdout output live as backup is running with:
```bash
$ journalctl -f -u restic-backup.service
````
(skip `-f` to see all backups that has run)
### 7. Email notification on failure

9
usr/local/sbin/restic_backup.sh
View File

@@ -5,15 +5,6 @@
# Exit on failure, pipe failure
set -e -o pipefail
# Redirect stdout ( > ) into a named pipe ( >() ) running "tee" to a file, so we can observe the status by simply tailing the log file.
me=$(basename "$0")
now=$(date +%F_%R)
log_dir=/var/local/log/restic
log_file="${log_dir}/${now}_${me}.$$.log"
test -d $log_dir || mkdir -p $log_dir
exec > >(tee -i $log_file)
exec 2>&1
# Clean up lock if we are killed.
# If killed by systemd, like $(systemctl stop restic), then it kills the whole cgroup and all it's subprocesses.
# However if we kill this script ourselves, we need this trap that kills all subprocesses manually.

9
usr/local/sbin/restic_check.sh
View File

@@ -5,15 +5,6 @@
# Exit on failure, pipe failure
set -e -o pipefail
# Redirect stdout ( > ) into a named pipe ( >() ) running "tee" to a file, so we can observe the status by simply tailing the log file.
me=$(basename "$0")
now=$(date +%F_%R)
log_dir=/var/local/log/restic
log_file="${log_dir}/${now}_${me}.$$.log"
test -d $log_dir || mkdir -p $log_dir
exec > >(tee -i $log_file)
exec 2>&1
# Clean up lock if we are killed.
# If killed by systemd, like $(systemctl stop restic), then it kills the whole cgroup and all it's subprocesses.
# However if we kill this script ourselves, we need this trap that kills all subprocesses manually.

4
usr/local/sbin/systemd-email
View File

@@ -5,14 +5,14 @@
# Usage: systemd-email <recipinent-email> <failed-systemd-unit-name>
# According to
# According to
# http://www.flashissue.com/blog/gmail-sending-limits/
# Gmail blocks your account if you send more than 500 emails per day, which is one email every
# (24 * 60 * 60) / 500 = 172.8 second => choose a min wait time which is significantly longer than this to be on the safe time to not exceed 500 emails per day.
# However this source
# https://group-mail.com/sending-email/email-send-limits-and-options/
# says the limit when not using the Gmail webinterface but going directly to the SMTP server is 100-150 per day, which yelds maximum one email every
# (24 * 60 * 60) / 100 = 864 second
# (24 * 60 * 60) / 100 = 864 second
# One option that I used with my old Axis cameras it to use my gmx.com accunt for sending emails instead, as there are (no?) higher limits there.
MIN_WAIT_TIME_S=900
SCRIPT_NAME=$(basename $0)