restic-backup-suite: Restore

Wiederherstellung mit restic-restore: Snapshot wählen, Menüpunkte, temporäres Restore-Verzeichnis, SQL-Dumps einspielen, SSL-Zertifikate und bekannte Einschränkungen beim Datenbank-Import.

English Version

Zurück zur Übersicht

Restore

sudo restic-restore [--config DATEI] [--snapshot ID]

restore.sh stellt Dateien aus einem Snapshot in ein temporäres Verzeichnis wieder her. Es überschreibt nichts am laufenden System (Ausnahme: Datenbank-Import, siehe unten).

Ablauf

Snapshot wählen. Mit --snapshot ID entfällt die Abfrage, sonst zeigt das Script restic snapshots und fragt nach einer ID oder latest.
Das Script legt /tmp/restic-restore-XXXXXX an (Rechte 700).
Menüpunkt wählen. Das Script führt genau eine Aktion aus und endet danach.
Prüfe die Dateien im Restore-Verzeichnis und kopiere sie selbst an den Zielort. Das Verzeichnis löschst Du danach von Hand (rm -rf), das Script räumt es nicht auf.

Die Dateien liegen unter dem ursprünglichen Pfad im Restore-Verzeichnis, /etc/nginx also unter /tmp/restic-restore-XXXXXX/etc/nginx.

Das Restore-Verzeichnis liegt unter /tmp. Bei großen Restores brauchst Du dort entsprechend Platz.

Menü

Auswahl	Aktion
`1`	Komplettes Snapshot wiederherstellen
`2`	`/var/www`
`3`	`/etc`
`4`	`/home`
`5`	Datenbank-Dumps auswählen und einspielen
`6`	`/etc/letsencrypt`, danach zeigt das Script Schritte zum Einspielen (certbot-Timer stoppen, kopieren, Rechte setzen, certbot-Timer starten, Webserver neu laden)
`7`	Frei gewählter Pfad
`q`	Abbrechen, das leere Restore-Verzeichnis wird gelöscht

Die Menüpunkte 2 bis 4 und 6 sind fest verdrahtete Pfade. Sie funktionieren nur, wenn dieser Pfad im Snapshot enthalten ist (also in BACKUP_PATHS lag).

Datenbank-Dumps einspielen

Menüpunkt 5 sucht im Snapshot das Verzeichnis /tmp/restic-db-dump-* (alternativ /tmp/mysql_backup), stellt es wieder her und listet die .sql-Dateien. Du wählst eine oder mehrere Nummern oder a für alle. Pro Datei fragt das Script nach, in welche Datenbank importiert werden soll, legt sie bei Bedarf mit CREATE DATABASE IF NOT EXISTS an und importiert den Dump mit dem lokalen Client mysql.

Der Import läuft direkt gegen den lokalen MySQL/MariaDB-Server und nutzt den mysql-Client ohne Zugangsdaten. Das ist nicht der Datenbank-Container, aus dem der Dump stammt.

Der Import ersetzt vorhandene Tabellen der Ziel-Datenbank. Die mit mysqldump oder mariadb-dump erzeugten Dumps enthalten standardmäßig DROP TABLE-Anweisungen, vorhandene Tabellen gleichen Namens gehen also verloren.

Bekannte Einschränkungen:

Der vorgeschlagene Datenbankname ist der Teil des Dateinamens nach dem letzten Unterstrich. Aus wikijs-db_mm_faq.sql wird faq, nicht mm_faq. Bei a (alle) gibt es keine Möglichkeit, den Namen zu ändern. Wähle bei Namen mit Unterstrich die Einzelauswahl und gib den Namen ein.
Das Script unterscheidet nicht zwischen MySQL- und PostgreSQL-Dumps. PostgreSQL-Dumps erscheinen in der Liste, lassen sich mit mysql aber nicht importieren. Spiele sie manuell mit psql in den Container ein.
Für Container-Datenbanken ist der sichere Weg: Dump aus dem Restore-Verzeichnis nehmen und selbst in den Container einspielen, zum Beispiel docker exec -i <container> mariadb -u root -p <db> < datei.sql.

Vorbedingung SFTP

restore.sh schreibt keine SSH-Konfiguration. Bei einem sftp:-Repository muss die Konfiguration aus einem früheren Backup-Lauf (oder von Hand) bereits vorhanden sein, siehe Technische Details.

Wiederherstellung ohne Script

Das Repository ist ein normales restic-Repository. Mit RESTIC_REPOSITORY und RESTIC_PASSWORD_FILE kommst Du auch ohne die Scripts an die Daten, zum Beispiel auf einem neuen Server mit restic restore latest --target /wiederherstellung. Du brauchst dafür nur das Repository und das Passwort, siehe Sicherheit.