Datenbank

PostgreSQL hält den Katalog jeder Sicherung, die Job-Warteschlange und das Audit-Log. Gesicherte Inhalte liegen in den Repositories, nicht in der Datenbank, aber ohne die Datenbank weiß Restow nicht, was darin liegt: Ein voller Datenträger hält die Datenbank an und damit jede Sicherung. Diese Seite sagt, wo die Daten liegen, wie Restow den freien Platz überwacht, wie Sie die Datenbank auf einen anderen Datenträger verschieben und was der Installer tut, um eine verschobene Datenbank zu schützen.

Wo die Daten liegen

Der Dienst postgres nimmt sein Datenverzeichnis aus zwei Zeilen der .env (die docker-compose.yml von Release 0.4.0 und neuer):

`.env`	Datenverzeichnis
beide Zeilen leer (Standard)	das Docker-Volume `pgdata` (im Compose-Projekt `restow` heißt es `restow_pgdata`), im Datenverzeichnis von Docker, meist auf dem Systemdatenträger
`RESTOW_POSTGRES_DATA_TYPE=bind` und `RESTOW_POSTGRES_DATA=/mnt/…/restow-postgres-<Zeit>`	dieses Verzeichnis auf dem Host

Die .env trägt den Speicherort, nicht eine Compose-Override-Datei, weil die .env die eine Datei ist, die jede Art, den Stack zu betreiben, liest: Der Updater ändert die Compose-Datei nie, und install.sh ersetzt bei einem erneuten Lauf die docker-compose.yml durch die Datei des Releases und ruft Compose mit -f auf, was docker-compose.override.yml ignoriert. Der Updater schreibt die beiden Zeilen, wenn er die Datenbank verschiebt; Sie schreiben sie nur selbst, wenn Sie die Datenbank von Hand verschieben (unten). Beide Variablen sind optional und stehen in den Umgebungsvariablen.

Der Dienst bindet das Verzeichnis mit create_host_path: false ein. Ist der Datenträger unter dem Verzeichnis nicht eingehängt (ein Volume, das nach einem Neustart nicht angehängt wurde), weigert sich Docker, PostgreSQL zu starten, statt ein leeres Verzeichnis anzulegen, das PostgreSQL als neue, leere Datenbank initialisieren würde. Ein Verschieben legt die Daten in ein Unterverzeichnis restow-postgres-<jjjjmmtt-hhmmss> des genannten Verzeichnisses, daher ergibt selbst ein Einhängepunkt, der ausgehängt leer ist, einen fehlenden Pfad und keinen leeren.

Speicherplatz

Installation → Datenbank zeigt den Speicherort, die Größe des Datenverzeichnisses, sein Dateisystem und den freien Platz darunter, den freien Platz unter dem lokalen Standard-Repository (STORAGE_LOCAL_PATH oder ein lokaler Standard, der unter Installation → Standard-Repository & Netzlaufwerke gespeichert ist) und was das nächste Update auf dem Datenträger braucht (Updates). Der Datenträger der Datenbank wird über den Updater gelesen; ohne ihn wird nur der Datenträger des Repositorys überwacht, und der Speicherort lässt sich hier weder lesen noch ändern.

Warnung bei wenig Speicherplatz

Ein Datenträger gilt als knapp, wenn weniger als ein Zehntel frei ist, und immer unter 5 GiB. Alle 15 Minuten prüft die API den Datenträger unter der Datenbank und den Datenträger unter dem lokalen Standard-Repository, und seit 0.4.5 auch die Systemplatte des Servers (/, wie der API-Container sie sieht, die Platte unter dem Datenverzeichnis von Docker), deren freien Platz sie stündlich zwei Wochen lang für den Verlauf behält, den das Dashboard zeigt, wenn ein Repository auf dieser Platte liegt (Wo Sicherungen landen). Wird einer knapp, löst Restow einmal das Installationsereignis Wenig Speicherplatz (installation.disk_low) aus:

ein Hinweis in der Glocke der Provider-Administratoren und
eine E-Mail oder ein Webhook jeder Alarm-Regel, die „Wenig Speicherplatz“ nennt. Nur Provider-Administratoren können dieses Ereignis wählen, siehe Benachrichtigungen und Berichte.

Es wird erst wieder ausgelöst, nachdem sich der Datenträger dazwischen auf ein Fünftel über der Grenze erholt hat. Die Seite zeigt am Datenträger die Marke Knapp und sagt, was zu tun ist: Platz freigeben, den Datenträger vergrößern oder die Datenbank auf einen anderen Datenträger verschieben.

Die Datenbank verschieben

Installation → Datenbank → Datenbank auf einen anderen Datenträger verschieben. Es braucht den optionalen Updater und die docker-compose.yml von 0.4.0 oder neuer (liest die Datei den Speicherort nicht aus der .env, sagt die Seite das und bietet den Installer-Befehl an; siehe die Schutzprüfung des Installers). Ein Verzeichnis zu prüfen und das Verschieben sind für die Inhaberin oder den Inhaber der Installation (Provider-Owner). Verschieben und das Entfernen einer alten Kopie verlangen eine Anmeldung aus den letzten Minuten. Jede Anforderung steht im Audit-Log: database.move.requested, und vom Updater database.move.started, database.move.succeeded, database.move.failed, database.old_copy.removal_requested und database.old_copy.removed.

Hängen Sie den neuen Datenträger an und auf dem Host ein (zum Beispiel unter /mnt/volume-1, mit einem Eintrag in /etc/fstab), und legen Sie darauf ein Verzeichnis an, zum Beispiel /mnt/volume-1/restow-db.
Geben Sie das Verzeichnis unter Verzeichnis auf dem Host ein und wählen Sie Verzeichnis prüfen. Nichts ändert sich; der Updater prüft, dass:
- der Pfad ein schlichter absoluter Pfad aus Buchstaben, Ziffern und . _ - + @ und kein Systemverzeichnis ist (/etc, /usr, /var/lib/docker, /tmp und ähnliche);
- das Verzeichnis auf dem Host existiert und beschreibbar ist;
- es auf einem anderen Dateisystem liegt als die Daten jetzt;
- das Dateisystem zu PostgreSQL passt: ext4, XFS, Btrfs oder ZFS. NFS, SMB/CIFS, FUSE, tmpfs, Overlay und alles andere werden abgelehnt;
- es Platz für das Datenverzeichnis plus ein Zehntel davon hat, mindestens 2 GiB;
- die Datenbank keine Tablespaces außerhalb ihres Verzeichnisses hat;
- die .env beschreibbar ist und Compose den Speicherort aus der .env nimmt und zu dem auflöst, wo die Datenbank jetzt läuft.
Wählen Sie Datenbank verschieben…. Der Dialog nennt die Ausfallzeit und die Größe; geben Sie zur Bestätigung das Verzeichnis erneut ein. Ein Verschieben wird abgelehnt, solange ein Update angekündigt ist oder läuft, und ein Update, ein Neustart eines Dienstes und ein Start des Mounters werden abgelehnt, solange ein Verschieben läuft.

Restow ist von Schritt 1 bis Schritt 8 unten nicht erreichbar. Kopie und Vergleich lesen die Daten etwa dreimal, planen Sie daher auf gewöhnlichen Datenträgern mehrere Minuten je 10 GB ein. Laufende Sicherungen werden unterbrochen und nach dem Verschieben fortgesetzt.

Schritt	Was geschieht	Was geprüft wird
1. API, Worker und Scheduler anhalten	Der Worker sichert Checkpoints laufender Jobs; der Edge liefert weiter die Wartungsseite aus.
2. Datenbank sauber anhalten	PostgreSQL hält an (bis zu 120 Sekunden).	`pg_controldata` muss `shut down` melden.
3. Datenverzeichnis kopieren	`<Verzeichnis>/restow-postgres-<Zeit>` wird angelegt und die Daten werden mit Besitzer, Berechtigungen und Zeiten kopiert, in einem Hilfscontainer des postgres-Images, die alten Daten schreibgeschützt eingebunden.
4. Kopie mit dem Original vergleichen	Beide Bäume werden nebeneinander aufgelistet.	Dieselben Einträge, Typen, Größen, Berechtigungen, Besitzer und der SHA-256 jeder Datei.
5. Probestart auf der Kopie	PostgreSQL startet auf der Kopie in einem isolierten Container (ohne Netzwerk, als Besitzer der Daten).	Es muss mit der Zahl der angewendeten Migrationen antworten, die vor dem Anhalten gelesen wurde, und wieder sauber anhalten.
6. Umstellen	`RESTOW_POSTGRES_DATA_TYPE=bind` und `RESTOW_POSTGRES_DATA=<Kopie>` kommen in die `.env` (die bisherigen Zeilen bleiben erhalten). Die alte Kopie bekommt eine Datei `RESTOW-MOVED.txt`, und ihre `PG_VERSION` wird in `PG_VERSION.restow-moved` umbenannt.	Compose muss den neuen Speicherort auflösen.
7. Datenbank aus dem neuen Verzeichnis starten	PostgreSQL wird auf dem neuen Verzeichnis neu angelegt.	Gesund, läuft aus dem neuen Verzeichnis, dieselbe Zahl Migrationen.
8. API, Worker und Scheduler starten	Zuerst die API, dann die übrigen.	Die API antwortet bereit.

Schlägt ein Schritt fehl, kehrt Restow von selbst um. Der Updater hält an, was er gestartet hat, setzt die beiden Zeilen der .env Byte für Byte zurück, benennt PG_VERSION der alten Kopie zurück, startet PostgreSQL am alten Speicherort (es muss von dort laufen und die Zahl der Migrationen von vorher zeigen) und startet die Anwendung. Das Verschieben endet dann als Zurückgesetzt, und die Datenbank ist unverändert. Eine unvollständige Kopie wird entfernt. Eine Kopie, aus der die Datenbank schon lief (ein Fehler in Schritt 7 oder 8), bleibt erhalten und wird auf der Seite genannt, weil sie einige Minuten an Änderungen enthalten kann. Wird der Updater selbst mitten in einem Verschieben neu gestartet, nimmt er beim erneuten Start denselben Weg zurück. Schlägt auch der Weg zurück fehl, endet das Verschieben als Braucht Aufmerksamkeit, und PostgreSQL bleibt angehalten, statt an einem Speicherort zu starten, der der falsche sein könnte (siehe unten).

Die alte Kopie

Das Verschieben löscht die alte Kopie nie. Ihre umbenannte PG_VERSION sorgt dafür, dass PostgreSQL auf ihr nicht startet: PostgreSQL würde sonst auf veralteten Daten laufen, wenn die .env zurückgesetzt oder eine alte Compose-Datei verwendet würde, und der Container scheitert dann mit „directory exists but is not empty“. Sobald die Datenbank vom neuen Datenträger gut läuft, entfernen Sie die alte Kopie mit Alte Kopie entfernen (die Inhaberin oder der Inhaber der Installation, mit aktueller Anmeldung). Der Updater löscht ihren Inhalt und behält RESTOW-MOVED.txt, damit das Verzeichnis nie für eine leere Datenbank gehalten werden kann. Das Volume restow_pgdata selbst bleibt, leer bis auf diese Hinweisdatei.

Zur alten Kopie nach einem erfolgreichen Verschieben zurückzukehren, wird nicht angeboten: Sie ist eine Momentaufnahme des Zeitpunkts des Verschiebens, und jede seither erfasste Sicherung würde in ihr fehlen. Um auf den Systemdatenträger zurückzukehren, verschieben Sie die Datenbank erneut, in ein Verzeichnis dort.

Wenn ein Verschieben Aufmerksamkeit braucht

Die Seite zeigt, welcher Schritt fehlgeschlagen ist, und das Protokoll des Updaters. Die Daten liegen an einem von zwei Orten, beide intakt: am alten Speicherort (bis Schritt 6 hat ihn nichts berührt) und, ab Schritt 3, in der Kopie. Prüfen Sie die .env, dann:

cd /opt/restow
grep RESTOW_POSTGRES_DATA .env                 # wo Compose PostgreSQL starten wird
# der alte Speicherort, wenn es das Volume ist:
docker run --rm -v restow_pgdata:/old alpine ls /old
# eine unter Quarantäne gestellte alte Kopie hat PG_VERSION.restow-moved statt PG_VERSION; um sie wieder zu verwenden:
docker run --rm -v restow_pgdata:/old alpine sh -c 'cd /old && mv PG_VERSION.restow-moved PG_VERSION && rm -f RESTOW-MOVED.txt'
# mit beiden Zeilen der .env leer (alter Speicherort) oder auf die Kopie zeigend:
docker compose up -d postgres && docker compose up -d

Verwenden Sie den Speicherort, an dem der letzte erfolgreiche Zustand lief: den alten, wenn das Verschieben vor Schritt 7 endete, die Kopie, wenn es fehlschlug, nachdem die Datenbank aus ihr gelaufen war (die Seite nennt sie als erhaltene Kopie).

Von Hand verschieben

Ohne den Updater oder mit einer älteren Compose-Datei führen Sie dieselben Schritte von Hand aus, als root auf dem Host, im Installationsverzeichnis. Die Compose-Datei muss die von Release 0.4.0 oder neuer sein, weil nur sie den Speicherort aus der .env liest:

cd /opt/restow
docker compose stop api worker scheduler
docker compose stop -t 120 postgres
NEW=/mnt/volume-1/restow-db/restow-postgres-$(date -u +%Y%m%d-%H%M%S)
mkdir "$NEW"
# mit Besitzer und Berechtigungen kopieren (das cp des postgres-Images; die alten Daten schreibgeschützt)
docker run --rm -v restow_pgdata:/from:ro -v "$NEW":/to --entrypoint sh postgres:16-alpine \
  -c 'cp -a /from/. /to/ && chown "$(stat -c %u:%g /from)" /to && chmod "$(stat -c %a /from)" /to'
# vergleichen (beide Zeilen müssen identisch sein)
docker run --rm -v restow_pgdata:/a:ro -v "$NEW":/b:ro --entrypoint sh postgres:16-alpine \
  -c 'for d in /a /b; do (cd $d && find . -type f -exec sha256sum {} + | LC_ALL=C sort -k2 | sha256sum); done'
# die .env auf die Kopie zeigen lassen
printf 'RESTOW_POSTGRES_DATA_TYPE=bind\nRESTOW_POSTGRES_DATA=%s\n' "$NEW" >> .env
docker compose config --format json | grep -c "$NEW"      # muss mindestens 1 sein
# die alte Kopie am versehentlichen Starten hindern
docker run --rm -v restow_pgdata:/old alpine sh -c 'echo "moved to '"$NEW"'" > /old/RESTOW-MOVED.txt && mv /old/PG_VERSION /old/PG_VERSION.restow-moved'
docker compose up -d postgres && docker compose up -d

Entfernen Sie leere Zeilen RESTOW_POSTGRES_DATA_TYPE= und RESTOW_POSTGRES_DATA= weiter oben in der .env zuerst (die letzte Zuweisung gilt, aber je eine Zeile ist klarer). Um es zurückzunehmen, bevor die Anwendung gestartet ist, leeren Sie die beiden Zeilen wieder, benennen PG_VERSION.restow-moved zurück und starten den Stack.

Die Schutzprüfung des Installers

Wurde die Datenbank auf einen anderen Datenträger verschoben, verweigert install.sh, eine docker-compose.yml einzusetzen oder zu starten, die RESTOW_POSTGRES_DATA nicht aus der .env liest. Es bricht mit Exit-Code 8 ab und ändert nichts, damit eine ältere Release-Datei den Stack nicht ohne seine Datenbank starten kann (PostgreSQL würde auf einem leeren oder alten Verzeichnis starten). Die Meldung nennt den Speicherort und verlangt die docker-compose.yml von Release 0.4.0 oder neuer. Die Datei von 0.3.6 liest die Einstellung nicht: Behalten Sie nach einem Verschieben der Datenbank eine Compose-Datei, die RESTOW_POSTGRES_DATA liest, auch wenn Sie ein Update zurückrollen. Siehe Erneut ausführen und Update auf 0.4.0.

Aufbewahrte Datenbank-Dumps

Vor jedem Update schreibt der Updater einen Datenbank-Dump in sein Volume (restow-updater, /state/dumps) und behält die neuesten drei, dazu den, von dem ein Lauf abhängt, der Aufmerksamkeit braucht. Seit 0.4.0 listet der Reiter Updates unter Installation → Updates sie unter Datenbanksicherungen mit Größe und Erstellungszeit auf, und die Inhaberin oder der Inhaber der Installation kann einen herunterladen (ein Einmal-Link, der eine Minute gilt und an Sie und diese Datei gebunden ist, nach einer aktuellen Anmeldung, im Audit-Log als update.dump.downloaded festgehalten) oder löschen (update.dump.deleted). Die Dumps liegen auf dem Datenträger von Docker: Löschen Sie alte dort, wenn der Platz knapp wird.

Der Datenträger unter den Dumps zählt zum Platz, den ein Update braucht: siehe Updates. Wie Sie einen Dump zurückspielen, steht unter Von Hand zurückrollen.

Nicht abgedeckt

Tablespaces, ein PGDATA unterhalb des Einhängepunkts und Netzwerkdateisysteme werden abgelehnt statt behandelt.
Zur alten Kopie nach einem erfolgreichen Verschieben zurückzukehren (verschieben Sie die Datenbank stattdessen erneut).