Ein Backup ist eine Frage. Eine Wiederherstellung beantwortet sie.

Halten Sie die erste Übung bewusst klein

Diese Übung legt eine Spielzeug-Notizdatenbank und einen Anhang an, erfasst beides und stellt sie dann in eine neue Datenbank und ein neues Verzeichnis wieder her. Verwenden Sie eine wegwerfbare Linux-Maschine mit PostgreSQL-17-Server und passenden Client-Werkzeugen, Bash und GNU coreutils. Sie darf keine Produktionsdaten enthalten und keine Verbindung zu Produktionsanwendungen, ausgehender Mail oder geplanten Jobs haben. Verwenden Sie nur das in dieser Übung erstellte Archiv.

Die Befehle setzen eine vorkonfigurierte Datenbankrolle ohne Superuser-Rechte namens voraus restore_lab, die Testdatenbanken erstellen darf, und einen OS-Login mit demselben Namen, der sich lokal authentifizieren kann. Der PostgreSQL-Socket ist /var/run/postgresql auf Port 5432. Lassen Sie den Administrator dieses Konto in der wegwerfbaren Umgebung vorbereiten; diese Anleitung ändert keine Datenbankzugriffsregeln. Prüfen Sie den Endpunkt, bevor Sie etwas erstellen:

psql -h /var/run/postgresql -p 5432 -U restore_lab -d postgres -c '\conninfo' &&
pg_dump --version &&
pg_restore --version

Stoppen Sie, wenn Host, Konto oder Version unerwartet sind. Halten Sie Clients und Server für diese erste Übung auf derselben Hauptversion. pg_dump kann keinen Server sichern, der neuer als seine eigene Hauptversion ist, und ein älteres Wiederherstellungsziel ist im Allgemeinen nicht garantiert kompatibel. Siehe Versionsgrenzen von pg_dump. Führen Sie jeden Block separat aus und stoppen Sie bei einem Fehler. Die && -Wächter verhindern, dass spätere Befehle in einem eingefügten Block nach einem Fehler laufen; fahren Sie nach einer fehlgeschlagenen Datenbank- oder Verzeichniserstellung niemals mit dem nächsten Block fort.

Einen Datensatz und die zugehörige Datei anlegen

Die Namen offvps_restore_source und offvps_restore_target müssen unbenutzt sein. Eine bestehende Datenbank ist ein Grund zu stoppen und eine neue isolierte Übung zu wählen, kein Grund sie zu löschen. Erstellen Sie einen frischen Dateisystem-Arbeitsbereich und die Quelldatenbank:

umask 077 &&
lab=$(mktemp -d "$PWD/offvps-restore.XXXXXX") &&
mkdir "$lab/source" "$lab/source/uploads" "$lab/bundle" "$lab/restore" &&
createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_source

Der frische Arbeitsbereich vermeidet das Überschreiben eines bestehenden Verzeichnisses. mktemp erstellt ein eindeutiges Verzeichnis; createdb erstellt eine neue Datenbank aus der ausgewählten Vorlage. Speichern Sie diese beiden Marker:

psql -X -v ON_ERROR_STOP=1 -h /var/run/postgresql -p 5432 \
  -U restore_lab -d offvps_restore_source \
  -c "CREATE TABLE notes (
        id integer PRIMARY KEY,
        body text NOT NULL,
        attachment text NOT NULL
      );
      INSERT INTO notes VALUES (1, 'restore-marker-01', 'marker.txt');" &&
printf '%s\n' 'restore-marker-01' > "$lab/source/uploads/marker.txt"

Der Datensatz sagt, welche Datei zur Notiz gehört, und beide enthalten denselben Marker. Dadurch wird ein fehlender Anhang oder eine nicht übereinstimmende Kopie sichtbar. -X vermeidet persönliche psql-Starteinstellungen und ON_ERROR_STOP stoppt bei einem SQL-Fehler; siehe psql-Skriptoptionen. Es gibt keine Anwendung, die in diesen Spielzeugdatensatz schreibt.

Datenbank und Dateien als ein Recovery-Set erfassen

pg_dump -h /var/run/postgresql -p 5432 -U restore_lab \
  --format=custom --file="$lab/bundle/notes.dump" offvps_restore_source &&
cp -a "$lab/source/uploads" "$lab/bundle/uploads" &&
pg_restore --list "$lab/bundle/notes.dump"

Das Archiv im Custom-Format wird gelesen von pg_restore; ein reiner SQL-Dump folgt einem anderen Wiederherstellungsverfahren. Das Auflisten des Archivs hilft zu bestätigen, dass die erwarteten Tabellen- und Dateneinträge vorhanden sind. Ein konsistenter Datenbank-Dump synchronisiert nicht automatisch externe Uploads. Verwenden Sie für eine echte App ihr dokumentiertes Wartungs- oder Schreibpausenverfahren, damit Dateibaum und Datenbank denselben Zeitpunkt beschreiben. Die Spielzeugübung ist bereits ruhig.

Notieren Sie Datenbankversion, Anwendungsrelease, Start/Ende der Erfassung und Dateipfad neben dem Bündel. Bewahren Sie echte Anmeldedaten separat unter angemessenen Zugriffskontrollen auf. Ein Dump pro Datenbank erfasst keine globalen Rollen und Tablespaces; ein echter Wiederherstellungsplan muss diese ebenfalls berücksichtigen. Der Umfang ist beschrieben in PostgreSQLs Leitfaden für SQL-Dumps.

In neue Ziele wiederherstellen, ohne ein bestehendes zu bereinigen

createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_target &&
pg_restore -h /var/run/postgresql -p 5432 -U restore_lab \
  --dbname=offvps_restore_target --no-owner --no-acl \
  --single-transaction "$lab/bundle/notes.dump" &&
mkdir "$lab/restore/uploads" &&
cp -a "$lab/bundle/uploads/." "$lab/restore/uploads/"

Die Zieldatenbank wird leer erstellt. Die Wiederherstellung lässt absichtlich --cleanweg, was bestehende Objekte entfernen könnte. --single-transaction lässt diese kleine Datenbankwiederherstellung als Einheit gelingen oder ohne Anwendung ihrer Teiländerungen stoppen; sie kann nicht mit parallelen Jobs kombiniert werden. --no-owner und --no-acl vereinfachen die Eigentümerschaft für diese Testrolle, daher validiert diese Übung nicht die Produktionsrollen oder Berechtigungen der Anwendung. Siehe pg_restore.

Die Dateikopie zielt auf das neue Wiederherstellungsverzeichnis und lässt die Quelle intakt. GNU cp -a versucht Dateiattribute zu erhalten; prüfen Sie Eigentümerschaft und Zugriff für das Konto, das eine echte Anwendung ausführen wird. Bytes zu kopieren ist kein Test der Anwendungsberechtigungen. Siehe cp’s Archivoption.

Die Beziehung prüfen, nicht nur Exit-Codes

psql -X -h /var/run/postgresql -p 5432 -U restore_lab \
  -d offvps_restore_target -c "SELECT id, body, attachment FROM notes;" &&
cat "$lab/restore/uploads/marker.txt"

Erwartete Ergebnisse sind eine Zeile mit ID 1, Body restore-marker-01 und Anhang marker.txt, plus eine Datei, die restore-marker-01enthält. Prüfen Sie, dass die Quelle weiterhin ihre ursprüngliche Zeile und Datei enthält. Richten Sie für Ihre echte App außerdem eine isolierte Instanz auf die wiederhergestellte Datenbank und das Upload-Verzeichnis, öffnen Sie repräsentative Datensätze, rufen Sie einen Anhang ab und testen Sie die vorgesehenen Login-Berechtigungen. Halten Sie dabei Callbacks, Mail und Jobs eingeschlossen.

Notieren, was Sie bewiesen haben und was offen bleibt

Die oben erwarteten Ausgaben sind Übungskriterien, keine bereits von OffVPS beobachteten Ergebnisse. Da die erste Übung alle Dateien auf einer Maschine hält, bietet sie keinen Schutz vor deren Verlust. Ein echter Plan braucht eine geschützte Kopie in einer separaten Fehlerdomäne, nutzbare Entschlüsselungsschlüssel, Aufbewahrung und einen getesteten Abrufpfad. Prüfen Sie die genauen wegwerfbaren Datenbanknamen und das Verzeichnis vor der späteren Bereinigung; halten Sie Produktion außerhalb dieses Prozesses.

Wiederholen Sie die Übung nach wichtigen Änderungen und dokumentieren Sie Fehler ebenso sorgfältig wie Erfolge. Ein optionaler Backup-Dienst beweist nicht die Wiederherstellungszeit Ihrer Anwendung. Fahren Sie fort mit einer geplanten Aufgabe planen wenn Sie bereit sind, die Erfassung zu automatisieren, während eine separate Restore-Übung erhalten bleibt.