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
README.md
+8 -1
View File
@@ -51,7 +51,6 @@ Now see if the backup itself works, by running
```bash ```bash
$ /usr/local/sbin/restic_backup.sh $ /usr/local/sbin/restic_backup.sh
$ less /var/local/log/restic/*
$ restic snapshots $ restic snapshots
```` ````
@@ -86,6 +85,14 @@ or start a backup manually
$ systemctl start restic-backup $ 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 ### 7. Email notification on failure
usr/local/sbin/restic_backup.sh
-9
View File
@@ -5,15 +5,6 @@
# Exit on failure, pipe failure # Exit on failure, pipe failure
set -e -o pipefail 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. # 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. # 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. # However if we kill this script ourselves, we need this trap that kills all subprocesses manually.
usr/local/sbin/restic_check.sh
-9
View File
@@ -5,15 +5,6 @@
# Exit on failure, pipe failure # Exit on failure, pipe failure
set -e -o pipefail 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. # 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. # 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. # However if we kill this script ourselves, we need this trap that kills all subprocesses manually.
usr/local/sbin/systemd-email
+2 -2
View File
@@ -5,14 +5,14 @@
# Usage: systemd-email <recipinent-email> <failed-systemd-unit-name> # Usage: systemd-email <recipinent-email> <failed-systemd-unit-name>
# According to # According to
# http://www.flashissue.com/blog/gmail-sending-limits/ # 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 # 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. # (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 # However this source
# https://group-mail.com/sending-email/email-send-limits-and-options/ # 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 # 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. # 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 MIN_WAIT_TIME_S=900
SCRIPT_NAME=$(basename $0) SCRIPT_NAME=$(basename $0)