Restic Backup Nachtrag - Homedir

Veröffentlicht von

In meinem vergangenem Beitrag "Backups mit Restic" habe ich ein bisschen was zu restic erzählt und warum ich es gut finde. Mittlerweile erstelle ich damit auch das Backup meines Homedirs. Dabei übernimmt systemd im Benutzerkontext für mich das Ausführen von restic. Warum systemd?

  • Systemd Timer - Cronjob ähnlicher Task Scheduler
  • Integriertes Logging
  • Überprüft return Codes und bricht bei Misserfolg ab

Konfiguration

Es werden zwei Dateien im Order $HOME/.config/systemd/user benötigt. restic-backup.service definiert den auszuführenden Backup Task und restic-backup.timer wann der Task ausgeführt wird.

[mne@sanctuary:~]$ tree .config
.config
└── systemd
    └── user
        ├── restic-backup.service
        └── restic-backup.timer

restic-backup.service

[Unit]
Description=Restic backup service

[Service]
Type=oneshot
Environment=BACKUP_PATHS="vault.pass vault-private.pass .gtkrc-2.0 .bashrc .icons .themes .thunderbird .config .ssh/config"
Environment=BACKUP_EXCLUDES="--exclude=Code --exclude=google-chrome --exclude=VirtualBox --exclude=ImapMail"
Environment=RETENTION_HOURS=8
Environment=RETENTION_DAYS=5
Environment=RETENTION_WEEKS=0
Environment=RETENTION_MONTHS=0
Environment=RETENTION_YEARS=0
Environment=RESTIC_REPOSITORY=%h/Backup
Environment=RESTIC_PASSWORD=sup3r_s3cr3t_r3p0_p4ssw0rd
ExecStart=restic backup --tag systemd.timer $BACKUP_EXCLUDES $BACKUP_PATHS
ExecStartPost=restic forget --tag systemd.timer --group-by "paths,tags" --prune --keep-hourly $RETENTION_HOURS --keep-daily $RETENTION_DAYS 
#--keep-weekly $RETENTION_WEEKS --keep-monthly $RETENTION_MONTHS --keep-yearly $RETENTION_YEARS
ExecStartPost=rsync -aHAXx --numeric-ids --delete --stats --info=progress2 --out-format="[%%t]:%%o:%%f:Last Modified %%M" --verbose -e "ssh -o Compression=no -x" "%h/Backup/" restic@BACKUP_SERVER_FQDN:/home/restic/HOSTNAME/
  • Type=oneshot
    • Task soll nur einmal ausgeführt und dann beendet werden
  • Verschiedene Environment Variablen die in den ExecStart und ExecStartPost Statements benötigt werden und das Backup konfigurieren
  • ExecStart
    • Erstellt das Backup mit tag systemd.timer um sie von manuellen Backups unterscheiden zu können
  • ExecStartPost
    • Wird nacheinander nach ExecStart ausgeführt. Erst entfernen Retention Policies Backups, prune löscht nicht mehr verlinkte Dateien und per rsync+ssh wird das Backup Repository auf einen anderen Server geschoben

restic-backup.timer

[Unit]
Description=Backup with restic

[Timer]
OnCalendar=0/1:00:00
Persistent=true

[Install]
WantedBy=timers.target

Systemd führt das Backup zu jeder vollen Stunde aus

Backup aktivieren

systemd units neu laden:

systemctl --user daemon-reload

Timer aktivieren:

systemctl --user enable restic-backup.timer
systemctl --user start restic-backup.timer

Alle aktiven Timer auflisten und anzeigen, wann sie das nächste mal ausgeführt werden:

systemctl --user list-timers

Backup Repository wiederherstellen

Das Backup Repository kann per rsync vom Server wiederhergestellt werden:

rsync -aHAXx --numeric-ids --delete --out-format="[%t]:%o:%f:Last Modified %M" -e "ssh -o Compression=no -x" restic@BACKUP_SERVER_FQDN:/home/restic/HOSTNAME/ ~/Backup --verbose

Fazit

Abgeleitet habe ich das ganze von dem fedoramagazine.org Artikel "Automate backups wich restic and systemd". Bisher funktioniert das sehr zuverlässig und mein Backup Repository ist nicht nur lokal sondern auch auf einem anderen System gespeichert. Das andere System ist ab jetzt mein Ziel für alle meine restic Backups und beinhaltet unter /home/restic/ verschiedene Unterordner wobei jeder Unterordner ein eigenes Backup Repository ist.

Systemd kümmert sich ums ausführen und wenn was schief geht lässt sich das Problem im Journal nachsehen. Sollte doch mal was schief gehen, bricht systemd den Backupprozess ab. Somit ist ein konsistentes Backup gewährleistet und mein Remote Repository wird nicht mit einem kaputten Backup überschrieben. Alles ohne Shell Skripte bei denen jede einzelne Aktion überprüft und logging eingebaut werden müsste.

Teile diesen Beitrag

2 Kommentare

  1. Der Schritt über rsync ist doch unnötig und macht einige der Vorteile zunichte, die restic in Sachen Übertragunseffizienz hat. Warum wird als Repo nicht direkt der Server verwendet?

    1. Ziel war, das Repo lokal wie auch remote zur Verfügung zu haben. Lokal, für einen schnellen Zugriff falls z.B. eine Datei widerhergestellt werden muss. Und Remote, denn was bringt mir das Backup auf dem System wenn das System selber kaputt geht. Meines Wissens bietet restic nicht die Möglichkeit, das backup direkt an zwei verschiedenen Orten abzuspeichern.

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert