Backup 2021

Ohne konkreten Anlass überarbeite ich nach vier Jahren meine Backup-Strategie und füge ein zusätzliches NAS (mit 250GB SSD-Cache) als Primärspeicher und Medienserver hinzu. Peinlicherweise beginne ich bereits, mühsam gewonnene Erkenntnisse zu vergessen und versäume daher, den schlüsselbasierten SSH-Zugriff auf Anhieb richtig zu konfigurieren. Konkret ist das Home-Verzeichnis der SSH-Nutzerin allzu zugänglich, und nach einer halben Stunde erfolglosem Debugging erkundige ich mich etwas voreilig nach einer Lösung, die ich wenige Minuten später selbst finde, erst in einem fremden, dann in meinem eigenen Blog (chmod 700 ~). Auch die offensichtliche Tatsache, dass die Plex-Nutzerin Leserechte für die Medienordner benötigt, und dass für mein SFTP-Skript SFTP auch aktiviert sein sollte (File Services → FTP → Enable SFTP service), realisiere ich jeweils erst nach einigen Minuten. Vielleicht sollte ich meine Freizeit doch lieber damit verbringen, Sonette zu verfassen.

Immerhin stoße ich bei der Abkehr vom proprietären Hyper Backup-Format für den Abgleich von Datenständen zwischen den NAS-Systemen auf ein reales Problem, das viele Synology-Nutzerinnen nervt. Die Funktion Shared Folder Sync basiert auf rsync, ist aber sehr eigenwillig implementiert. Existierende Ordner auf dem Ziel-NAS, die zur Synchronisation förmlich einladen, werden zum Anlass genommen, neue Ordner anzulegen:

If on the destination exists a shared folder with the same name (e.g., SharedFolder) as the shared folder on the source, a new folder with a numbered name (e.g., SharedFolder_1) will be created at the destination when syncing.

Das ist nicht sehr günstig, wenn umfangreiche Ordner schon auf beiden beteiligten NAS existieren. Glücklicherweise gibt es einen Workaround:

  1. Alle zu synchronisierenden Ordner auf dem Ziel-NAS umbenennen (XXX_tmp)
  2. Einen Synchronisations-Task auf dem Quell-NAS anlegen, und für jeweils einen Quell-Ordner kurzzeitig (!) starten. Der neue Ziel-Ordner wird angelegt (mit ausgesprochen restriktiven Zugriffsrechten).
  3. Die Zugriffsrechte (Advanced Permissions) für die Ziel-Ordner anpassen (Entfernen der read only-Regel für die Admin-Gruppe, Einrichtung von Schreib-/Leserechten für die synchronisierende Benutzerin)
  4. Bewegen (Move (overwrite), nicht Copy) der Inhalte aus den umbenannten ursprünglichen Ordnern auf dem Ziel-NAS (XXX_tmp → XXX).
  5. Den Synchronisations-Task für alle Quell-Ordner konfigurieren und manuell starten.

Auf diesem Weg dauert die abschließende Synchronisation von mehr als 5 TB rund 5 Minuten.

Wenige Tage später tritt erstmals ein Problem auf, das ich schon vor Jahren erwartet hatte (und das bei anderen Nutzerinnen auch auftrat): Wie vom Security Audit anempfohlen, hatte ich im Zuge der NAS-Erstkonfiguration den allgemeinen SSH-Port (Control Panel → Terminal) geändert, nicht aber den SSH-Port für rsync (Control Panel → File Services → rsync). Nachdem meine rsync-Skripte lange Zeit trotz dieser offensichtlichen Diskrepanz funktioniert haben, wird das Thema Ports nach dem sonntäglichen DSM-Update plötzlich ernst genommen (Permission denied). Das Debugging dauert wieder etwas, die Fehlerbehebung selbst nicht. Warum aber jahrelang wohlwollend ein falscher Port akzeptiert wurde, bleibt mysteriös.

Nach der erfolgreichen Inbetriebnahme fällt mir auf, dass es bisher kein Backup der NAS-Konfiguration gab, was sich aber rasch korrigieren lässt (Update & Restore → Configuration Backup).

Erstaunlich schwierig gestaltet sich ein zusätzlicher Automatisierungsschritt für das bislang manuell ausgeführten Backup-Skript (ein Python-Wrapper, der Shortcuts für unterschiedliche rsync-Konfigurationen bereitstellt). Die Einstellung einer monatlichen Frequenz ist schon sehr viel umständlicher als ein entsprechender crontab-Eintrag, aber die entscheidende Hürde sind die Zugriffsberechtigungen für Anwendungen, die per launchd gestartet werden. Trotz vieler hilfreicher Foreneinträge, die mir raten, rsync, launchd und/oder der Shell (zsh/bash) Full Disk Access zu erteilen, verweigert das System rsync standhaft den Zugriff auf meine Ordner:

rsync: opendir "/Users/username/Backup" failed: Operation not permitted (1)

Andererseits funktioniert rsync mit derselben Konfiguration einwandfrei, wenn es direkt als LaunchAgent gestartet wird. Channing Walton bestätigt meinen Verdacht: Statt das Skript aufzurufen und auf die Shebang-Zeile zu vertrauen –

<key>ProgramArguments</key> <array> <string>/Users/jan/bin/rbackup.py</string> <string>nas1_core</string> </array>

– sollte der jeweilige Interpreter explizit in der property list für launchd genannt –

<key>ProgramArguments</key> <array> <string>/opt/homebrew/bin/python3</string> <string>/Users/jan/bin/rbackup.py</string> <string>nas1_core</string> </array>

und mindestens mit Zugriffsrechten auf ~ ausgestattet werden.

Dank launchd und Shared Folder Sync hält sich der regelmäßige Aufwand für die folgende Sicherungsmatrix in akzeptablen Grenzen:

DatenQuelleZielFrequenzMethodeScheduled
Dokumente / Konfiguration/Users/jan/Backupnas1:/Volume1/CoreBackupwöchentlich (So, 10 Uhr)rbackup.py
nas2:/Volume1/CoreBackupmonatlich (1. Sonntag, 11 Uhr)rbackup.py
nas3:/Volume1/CoreBackupmonatlich (3. Sonntag, 11 Uhr)rbackup.py
usbkey1:/CoreBackupwöchentlich (Sonntag)rbackup.py
usbkey2:/CoreBackupwöchentlich (Dienstag)rbackup.py
usbkey3:/CoreBackupwöchentlich (Donnerstag)rbackup.py
/Users/jan/CoreBackup.sparsebundlewöchentlich (Sonntag, 9 Uhr)rbackup.py
/Users/jan/CoreBackup.sparsebundleserver1:/home/backupwöchentlich (Montag, 10 Uhr)rbackup.py
server2:/home/backupwöchentlich (Mittwoch, 10 Uhr)rbackup.py
Bilder/Users/jan/Picturesnas1:/Volume1/Pictureswöchentlich (Sonntag, 12 Uhr)rbackup.py
nas2:/Volume1/Picturesmonatlich (1. Sonntag, 12 Uhr)rbackup.py
nas3:/Volume1/Picturesmonatlich (3. Sonntag, 12 Uhr)rbackup.py
Musik/Users/jan/Musicnas1:/Volume1/Musicmonatlich (1. Sonntag, 12 Uhr)rbackup.py
nas2:/Volume1/Musicmonatlich (3. Sonntag, 12 Uhr)rbackup.py
Büchernas1:/Volume1/Booksnas2:/Volume1/Booksmonatlich (1. Sonntag, 14 Uhr)Shared Folder Sync
nas3:/Volume1/Booksmonatlich (3. Sonntag, 15 Uhr)Shared Folder Sync
Zeitungennas1:/Volume1/Newsnas2:/Volume1/Newsmonatlich (1. Sonntag, 14 Uhr)Shared Folder Sync
nas3:/Volume1/Newsmonatlich (3. Sonntag, 15 Uhr)Shared Folder Sync
Filmenas1:/Volume1/Moviesnas2:/Volume1/Moviesmonatlich (1. Sonntag, 14 Uhr)Shared Folder Sync
TV-Seriennas1:/Volume1/TV Showsnas2:/Volume1/TV Showsmonatlich (1. Sonntag, 14 Uhr)Shared Folder Sync
Softwarenas1:/Volume1/Softwarenas2:/Volume1/Softwaremonatlich (1. Sonntag, 14 Uhr)Shared Folder Sync
[Data]/System/Volumes/Datahdd1:/monatlichSuperDuper!
hdd2:/monatlichSuperDuper!
hdd3:/vierteljährlichSuperDuper!
nas1:/Volume1/FullBackupwöchentlich (Sonntag)SuperDuper!

Die Fotobibliothek in /Users/jan/Pictures wird darüber hinaus in der iCloud gesichert. /Users/jan/Backup enthält hauptsächlich Symlinks auf verschiedene Verzeichnisse (~/...) und wird wöchentlich mit aktuellen Konfigurationsdateien des Webservers ergänzt.

Anders als noch vor einem Jahrzehnt nehme ich das Thema Ransomware sehr ernst und setze auf verschieden lange Backup-Zyklen, außerdem sind mittlerweile alle Backup-Medien verschlüsselt. Allerdings befinden sich die Speichermedien ausnahmslos auf dem Staatsgebiet der Bundesrepublik Deutschland – meine Daten werden also bestimmte apokalyptische Szenarien in Zentraleuropa nicht überstehen (abgesehen von den in Nordamerika gesicherten Fotos und Passwörtern).

Für eine vorwiegend nordamerikanische Apokalypse ist dagegen vorgesorgt: Der freundliche 1Password-Support hat mir für den Fall einer world catastrophe where all our servers have been wiped out den nicht ganz offensichtlichen Speicherort der lokalen 1Password-Datenbank (~/Library/Group Containers/2BUA8C4S2C.com.agilebits/Library/Application Support/1Password/Data) verraten – den ich als Symlink in mein Backup-Verzeichnis aufnehme – und zusätzlich die Ablage meiner exportierten Vaults in einem verschlüsselten Disk Image empfohlen:

Everything breaks at some point, so while it's extremely unlikely anything catastrophic would happen that you couldn't recover from, I understand where you're coming from and I can see why you'd like to manage your own backups in addition to what we do.

Das ist die richtige Einstellung.