HOWTO - Anleitung zur vollständigen Wiederherstellung eines Restic-Serverbackups

[Florian]

Hallo,

da ja schon die Fragen aufkamen wie aus einem Restic-Backup ein Server komplett wiederhergestellt werden kann, habe ich mal die wichtigsten Punkte zusammengetragen.
Die Anleitung bezieht sich auf eine Komplett-Wiederherstellung eines Restic-Backups auf einem jungfräulich installierten Server.

Stand: 14.03.2023

[space2place]

Grossartig Florian.. Vielen Dank für Deine Arbeit
Gruß
Sascha

[mhagge]

Dem kann ich mich nur anschliessen!

[joestr]

Die Anleitung hat super funktioniert.

Folgendes ist mir im PDF in der Sektion Restore aufgefallen:

Code: Select all

cat /restore/etc/group >> /etc/group

Ich denke da ist aber die shadow-Datei gemeint, welche man wenige Zeilen zuvor editiert hat.

Nach Abschließen der Anleitung funktioniert auch alles soweit, bloß im Dashboard stehen nicht die richtigen IP-Adressen. Kann man das irgendwie aktualisieren?

[Florian]

Hi

gut aufgepasst. Ist korrigiert

Du musst die korrekten IPs unter Konfiguration -> IP Adressen aktivieren, dann stimmt auch die Anzeige

[w_2022F]

Ich habe mit dieser Anleitung versucht auf einen komplett neuen Server umzuziehen. Auf dem neuen Server wurde Ubuntu 22.04 LTS - auf dem alten Server ist Ubuntu 20.04 LTS installiert. Nach längerem Testen habe ich folgende Änderungen vorgenommen:

Punkt 3 der Vorbereitung: Nicht die Benutzer keyhelp und keyhelp_root exportieren
Backup Repository einrichten (auf altem Server ein neues Backup für die Datenübernahme eingerichtet)
Wiederherstellen von /etc nach /home/.../restore/
User anhängen an /etc/passwd /etc/shadow
Ersetzen / Anhängen an /etc/group /etc/gshadow
Wiederherstellen der Datenbanken: keyhelp, phpmyadmin, rainloop, roundcube - KEINESFALLS mysql
als Root in Konsole anmelden: mysql -u root -p ausführen
Die zuvor gespeicherten Benutzer und Berechtigungen (keyhelp@localhost und keyhelp_root@localhost wurden ja nicht exportiert; dies würde Probleme bei der automatischen Anmeldung verursachen) in die Zwischenablage einfügen und im Konsolenfenster einfügen. Nicht alle Berechtigungen werden angelegt, da jetzt die Datenbanken noch fehlen. 
dann noch flush privileges;
exit um mysql zu verlassen
Repository können jetzt nicht geändert werden, da diese nicht entschlüsselt werden können. Einträge gelöscht und nötige wieder angelegt.
Die Seite von keyhelp ist nicht erreichbar wenn die Benutzer keyhelp / keyhelp_root und Berechtigungen eingespielt wurden. (nach einiger Zeit ist auch ein Eintrag in /var/log/syslog ersichtlich: post mariadb[5000]: ... [Warning] Access denied for user 'keyhelp'@'localhost' (using password: YES)

Wie unter Restore Punkt 3) die e-mail-Konten, Datenbanken und Userverzeichnisse samt /var/spool/cron zurückgeladen.

Punkte 4 und 5 habe ich noch nicht durchgeführt, da es sich derzeit um eine "Backup"-Installation handelt um schnell umstellen zu können, falls der Produktionsserver ausfällt. Dieser Server ist von außen nicht erreichbar (nur intern über die IP-Adresse) und ist mir aufgefallen, dass bei dem Dienst MariaDB/MySQL OFFLINE steht.

[w_2022F]

Nachtrag:
Nachdem nun die Datenbanken zurückgeladen wurden können nochmals die zuvor gespeicherten Benutzer und Berechtigungen mithilfe von mysql -u root -p eingespielt werden.
dann noch flush privileges;

Mein Server ist trotz identer Konfiguration über Fernzugriff nicht erreichbar. Konfiguration - Datenbank-Server - Fernzugriff -> JA und Firewall auch korrekt gesetzt. Benutzer hat die nötigen Rechte für den Fernzugriff. Im Moment konnte ich hierfür noch nicht die Ursache ermitteln. Tipps?

[Tobi]

Tipps?

1. Nie beim Restore das OS wechseln!
2. Halte dich an die Anleitung, diese stimmt.

[Florian]

Hi,

es gibt sicher mehrere Wege um ans Ziel zu kommen. Ich verstehe zwar nicht warum man nicht alle MySQL User exportiert. Sinn des ganzen ist ja, dass man nach dem Restore der MySQL Datenbank die Passwörter dieser User wiederherstellt und somit wieder Zugriff auf Keyhelp hat.

Bei Ubuntu 22 gibt es einen kleinen Bug beim externen Zugriff. Bei bind_address wird "::" gesetzt, das nicht mehr akzeptiert wird bei der MariaDB Version. Hier muss man manuell die Einstellung korrigieren, Wird mit dem nächsten Update bereinigt.

[hausdoerfer]

Hallo Zusammen,

vielen dank für die Anleitung! Das ist damit super easy einen Server wiederherzustellen.
Wie verhalten sich denn die Backups im allgemeinen? Wenn ich jetzt eine Servermigration mache über mehrere Tage? Kann ich dann die Daten die auf dem Alten Server hinzugekommen sind (z.B. Mails) einfach nochmal auf dem neuen Server wiederherstellen? Ist das inkrementell oder wird dann alles noch einmal überschrieben?

Grüße

[Alexander]

Hallo

du kannst du beim Wiederherstellen aussuchen, welche Email-Konten du wiederherstellen möchtest.

Wenn Emails in einem bestehenden Mailkonto wiederhergestellt werden sollen, werden die Emails aus dem Backup in das bestehende Postfach kopiert.
So verlierst du in keinem Fall Emails, es kann jedoch sein, das z.b. bereits gelöschte Emails wieder auftauchen, da diese sich ggf. zum Zeitpunkt des Backups (das jetzt wiederhergestellt werden soll) noch im Posteingang befanden, etc.

[xeppel]

Mal eine blöde Frage, schritt 3 bei der Vorbereitung, das soll dann noch auf der alten Instanz gemacht werden Nehm ich an ?

[OlliTheDarkness]

Mal eine blöde Frage, schritt 3 bei der Vorbereitung, das soll dann noch auf der alten Instanz gemacht werden Nehm ich an ?

Schritt 3 bezieht sich auf die neue.

[xeppel]

Ich habe das ganze mal mit einem Testsystem getestet. System aufgesetzt, Backup erstellt, neu installiert, Backup eingespielt - hat super geklappt.

jetzt wollte ich ein Backup des Produktivsystems auf dem Testsystem einspielen, doch nach dem Wiederherstellen der 5 DBs funktioniert der SQL Server gar nicht mehr:

Code: Select all

root@keyhelp:~ # sudo service mysql restart
Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.
root@keyhelp:~ # systemctl status mariadb.service
● mariadb.service - MariaDB 10.3.36 database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2023-02-19 12:38:12 CET; 2s ago
     Docs: man:mysqld(8)
           https://mariadb.com/kb/en/library/systemd/
  Process: 8196 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
  Process: 8197 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 8199 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
  Process: 8303 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
 Main PID: 8303 (code=exited, status=1/FAILURE)

Feb 19 12:38:12 keyhelp.domain.tld systemd[1]: Starting MariaDB 10.3.36 database server...
Feb 19 12:38:12 keyhelp.domain.tld mysqld[8303]: 2023-02-19 12:38:12 0 [Note] /usr/sbin/mysqld (mysqld 10.3.36-MariaDB-0+deb10u2) starting as process 8303 ...
Feb 19 12:38:12 keyhelp.domain.tld mysqld[8303]: 2023-02-19 12:38:12 0 [Warning] Could not increase number of max_open_files to more than 32768 (request: 131304)
Feb 19 12:38:12 keyhelp.domain.tld systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
Feb 19 12:38:12 keyhelp.domain.tld systemd[1]: mariadb.service: Failed with result 'exit-code'.
Feb 19 12:38:12 keyhelp.domain.tld systemd[1]: Failed to start MariaDB 10.3.36 database server.

Woran kann das jetzt liegen ?

Edit: Oh moment, das Testsystem ist noch Debian 10, das Prod. 11...

[xeppel]

Mir sind jetzt noch 2 Dinge aufgefallen:

- Die 2FA Anmeldung funktioniert nicht nach dem restore: "Der geheime Zwei-Faktor-Authentisierungsschlüssel konnte nicht gelesen/entschlüsselt werden. Bitte wenden Sie sich an Ihren Serveradministrator, um Ihre Zwei-Faktor-Authentisierungseinstellungen zurückzusetzen.". Man muss es über keyhelp-toolbox deaktivieren. Blöd, wenn viele User 2FA nutz(t)en.
- die hinterlegten Favicon und Banner unter "White-Label" wurden nicht wiederhergestellt. In der DB "keyhelp" in der Tabelle "whit_label" steht als content-Pfad "/home/keyhelp/www/keyhelp.white_label/all/banner_intern", keyhelp.white_label existiert aber auch gar nicht (mehr). Hier muss der Pfad aus /home/keyhelp noch wiederhergestellt werden, kannst du im PDF ja anpassen

Kann man das 2FA-Thema vielleicht für die Zukunft beheben ? Inwiefern wird der 2FA Secret denn entschlüsselt, kann man diesen Schlüssel auch noch irgendwie wiederherstellen ?