Instanz-Backups

Projekt-Backups schützen deine Projekte, Instanz-Backups schützen Envoryx selbst. Darin steckt die SQLite-Datenbank mit Konten, Sitzungen, API-Tokens, den Projekten samt Dienst-Einstellungen, Domains, Workern und Einstellungen - dazu die lokale CA, der SSH-Host-Key und die Deploy-Keys, die Benachrichtigungs-Einstellungen und die Konfiguration, die Envoryx pro Projekt erzeugt. Du findest sie unter Einstellungen → Backups → Instanz-Backups.

Nicht drin sind deine Projektdateien und Docker-Volumes - das erledigen die Projekt-Backups. Ein Instanz-Backup ist eine einzelne envoryx-<id>.tar.gz unter <backup-verzeichnis>/_instance/.

Zwei Dinge fehlen mit Absicht: der Secret Key, der die gespeicherten Geheimnisse verschlüsselt, und die Instanz-ID. Eine Wiederherstellung behält den aktuellen Schlüssel und die aktuelle ID. Deshalb brauchst du eine Kopie des Schlüssels, um ein Backup auf einem anderen Host wiederherzustellen. Welche ID es beim Anlegen hatte, merkt sich das Backup aber, und zwar für den einen Fall, in dem die Übernahme richtig ist: Du hast /config auf demselben Host verloren, und die alten Projekt-Container laufen noch (siehe unten).

Anlegen und umziehen

Mit Backup erstellen legst du jederzeit eines an; vor einem Update ist das eine gute Angewohnheit. Willst du Envoryx auf einen anderen Rechner umziehen, lädst du das Backup mit Herunterladen herunter und holst es dort mit Backup importieren herein.

Lädst du ein Instanz-Backup aus Versehen unter Neues Projekt → Bestehende Website hoch (oder mit envoryx import), hält Envoryx es nicht für eine Website: Es erkennt das Backup und legt es in diese Liste, wo du es wiederherstellen kannst.

Ein paar legt Envoryx auch von selbst an: vor jeder Änderung am Datenbankschema (pre-migrate-…) und vor jeder Wiederherstellung (pre-restore-…). Von jeder Sorte behält es die letzten fünf. Selbst angelegte und importierte bleiben, bis du sie löschst. Und mit einem Offsite-Ziel geht jeden Tag eines hoch, ohne dass du etwas tun musst.

Wiederherstellen

Wiederherstellen will, dass du restore eintippst - schließlich wird hier wirklich etwas ersetzt. Envoryx startet dann an Ort und Stelle neu und spielt das Backup ein, bevor es seine Datenbank öffnet. Vorher sichert es den aktuellen Stand als pre-restore-Backup, sodass sich selbst eine Wiederherstellung rückgängig machen lässt, und ersetzt danach Datenbank und Konfiguration.

Deine Projektdateien bleiben, wie sie sind. Container von Projekten, die du nach dem Backup angelegt hast, gehören danach zu keinem Projekt mehr; Envoryx entfernt sie etwa eine Minute später, und ihre Volumes stehen auf der Seite Docker, bis du sie selbst entfernst.

Jede Browser-Sitzung endet, auch die, die noch im Backup stecken - ein Cookie von damals wird also nicht wieder lebendig. Melde dich mit den Zugangsdaten aus dem Backup neu an. Bei API-Tokens ist das anders: Sie sind die aus dem Backup und funktionieren weiter, praktisch für Skripte und IDEs. Ein Token, das du nach dem Backup widerrufen hast, gilt damit aber wieder, also widerruf es noch einmal.

Ein Backup von einem neueren Envoryx lehnt es ab. Ein älteres geht problemlos: Envoryx bringt es beim Start auf den aktuellen Stand.

Nach verlorenem /config

Ist /config weg, laufen die Projekt-Container aber noch auf dem Host, bekommt Envoryx beim frischen Start eine neue Instanz-ID, und die alten Container gehören plötzlich „einer anderen Instanz“. Spielst du das Instanz-Backup ein, regelt sich das im Normalfall von selbst: Beim ersten Start nach der Wiederherstellung übernimmt Envoryx die ID, unter der das Backup entstanden ist, wenn die Container dieser ID für die wiederhergestellten Projekte auf dem Host sind, diese Instanz noch keine eigenen Container hat und kein anderer Envoryx-Container auf dem Host existiert, egal ob laufend oder gestoppt. Der Eintrag instance.restored im Audit-Log nennt dann die übernommene ID.

Läuft ein zweites Envoryx auf demselben Host, kann es nicht sagen, wem die Container gehören, und behält seine neue ID. Die Projekte stehen dann als fehlend da, und ein Start scheitert mit der Name gehört einer anderen Envoryx-Instanz auf diesem Docker-Host. Welche ID die Container tragen, steht im Log; wie du sie von Hand zurückholst, steht unter Fehlerbehebung.

Von der Kommandozeile

Die CLI erledigt das alles mit einem Admin-Token - praktisch vor einem Update oder beim Umzug auf einen anderen Host:

envoryx instance backup --note "vor dem Update"
envoryx instance download <backup>                     # auf dem alten Host
envoryx instance upload envoryx-<backup>.tar.gz         # auf dem neuen
envoryx instance restore <backup> --yes --wait

--wait kehrt zurück, sobald Envoryx wieder da ist. Wurde das Backup mit einem anderen geheimen Schlüssel gemacht, gibst du ihn mit --key-file DATEI mit (oder --key-file - von stdin), damit er nicht in deiner Shell-History landet. Und denk daran, dass die wiederhergestellte Datenbank ihre eigenen Tokens mitbringt: Der, den du benutzt hast, funktioniert danach vielleicht nicht mehr.

Von Hand wiederherstellen

Startet Envoryx gar nicht mehr, machst du es selbst: Container stoppen, das Archiv entpacken, envoryx.db nach /config/envoryx.db legen (vorhandene envoryx.db-wal und envoryx.db-shm löschen) und config/* über /config/ kopieren, dann wieder starten.

Auf eine ältere Version zurück

Vor der ersten Schemaänderung einer neuen Version schreibt Envoryx ein pre-migrate-Backup. Das ist dein Weg zurück, allerdings nur von Hand. Das alte Image startet nicht mit einer Datenbank, deren Schema schon neuer ist, an seine Oberfläche kommst du also nie heran. Und das Backup in der neuen Version einzuspielen bringt auch nichts: Der nächste Start würde es einfach wieder migrieren.

Stopp also den Container, spiel das pre-migrate-Backup wie oben von Hand ein und starte das alte Image. Die Fehlermeldung der alten Version nennt dir das neueste pre-migrate-Backup, du weißt also, welches du nimmst. Alles, was du nach dem Update geändert hast, ist damit weg.