Zum Inhalt springen

Projekt-Backups

Ein Projekt-Backup holt dir ein Projekt zurück, wenn eine Migration danebengeht, ein Ordner weg ist oder ein Experiment aus dem Ruder läuft. Du legst es im Bereich Backups des Projekts mit Backup erstellen an.

Der Bereich Backups mit dem täglichen Zeitplan um 02:00, der 7 Backups behält, und der Karte „Backup erstellen“ mit Häkchen für Datenbank, Projektdateien und ObjektspeicherDer Bereich Backups mit dem täglichen Zeitplan um 02:00, der 7 Backups behält, und der Karte „Backup erstellen“ mit Häkchen für Datenbank, Projektdateien und Objektspeicher

Jede Datenbank des Projekts landet als Dump im Backup: database.sql.gz für die primäre, database-<name>.sql.gz für jede weitere. Bei MongoDB bleibt der Name gleich, aber im gzip steckt ein mongodump-Archiv und kein SQL; zurück bekommst du es also mit mongorestore --archive, nicht mit einem SQL-Client. Ein Rails-Projekt bringt außerdem die Datenbanken _queue, _cache und _cable mit, die Envoryx neben seiner primären anlegt (database_queue.sql.gz und so weiter), damit wartende Solid-Queue-Jobs eine Wiederherstellung überstehen. Dazu kommt das Projektverzeichnis mit deinem Code. vendor/, node_modules/, Pythons .venv/ und __pycache__/ sowie die Build-Caches .next/, .nuxt/ und .output/ lässt Envoryx standardmäßig weg - die sind groß und lassen sich jederzeit neu bauen. Wenn du lieber alles an einem Ort hast, nimmst du sie einfach mit.

Hat das Projekt Objektspeicher, wandert der Bucket als normale Dateien in storage.tar.gz mit (standardmäßig an). Außerdem stecken die Einstellungen des Projekts drin, damit eine Wiederherstellung das Projekt so aufbauen kann, wie es war. Nicht drin sind die behaltenen Daten eines entfernten Dienstes, etwa eines Redis, das du herausgenommen und dessen Volume du behalten hast. Ebenso wenig die Daten von Redis, OpenSearch, Meilisearch, Typesense oder RabbitMQ: Caches, Suchindizes und wartende Nachrichten lohnen das Sichern nicht, die Anwendung baut sie neu auf.

Jedes Backup ist ein ganz normaler Ordner unter <backup-verzeichnis>/<projekt>/. Darin stehen Datenbank-Passwörter und Tokens - geh mit einem heruntergeladenen Archiv also um wie mit einer Passwortdatei.

Von Haus aus landen sie in /config/backups. Backups sind groß und du schaust selten hinein, deshalb lohnt sich oft ein anderer Platz - unter Unraid zum Beispiel das Array statt der Cache-SSD.

Am einfachsten hängst du einen Host-Ordner unter /backups ein: Das Unraid-Template hat dafür den optionalen Pfad Backups, mit Compose ergänzt du ein /backups-Volume. Envoryx bemerkt das und nutzt ihn. Willst du einen ganz bestimmten Ort, setzt du stattdessen ENVORYX_BACKUPS_DIR.

Vorhandene Backups ziehst du um, indem du Envoryx stoppst, den Inhalt von /config/backups/ in den neuen Ordner verschiebst und Envoryx wieder startest.

Unter Backups → Geplante Backups sichert Envoryx ein Projekt täglich oder wöchentlich zur gewünschten Stunde und behält die letzten N davon. Die Stunde ist Serverzeit - stimmt sie nicht, setz TZ am Container. Die Rotation räumt nur geplante Backups weg; die von Hand angelegten bleiben, bis du sie löschst. Schlägt ein Backup fehl, bekommst du eine Benachrichtigung.

Wundere dich nicht, wenn gleich nach dem Einschalten ein Backup auftaucht. Envoryx prüft jede Minute, ob der letzte fällige Termin schon gesichert ist, und bei einem frischen Zeitplan ist er das nicht. Das erste geplante Backup läuft also sofort, das nächste dann zur gewählten Stunde.

Ein Backup, nach dem weniger als 512 MiB frei wären, startet Envoryx gar nicht erst. Eine komplett volle Platte würde die Datenbank von Envoryx mitreißen, und das wäre der größere Schaden.

Wiederherstellen spielt zurück, was du auswählst - Datenbanken, Dateien, Bucket -, sobald du zur Bestätigung den Projekt-Bezeichner eingetippt hast. Jeder Dump, dessen Datenbank das Projekt noch hat, wird eingespielt; welche übersprungen wurden, sagt dir Envoryx. Eine Datenbank, die Envoryx betreibt, wird vorher geleert, damit Tabellen aus einer späteren Migration nicht liegen bleiben und dir die nächste Migration verhageln. Eine externe Datenbank leert Envoryx nie: Dort ersetzt der Dump nur die Tabellen, die er selbst enthält. Den Bucket kannst du vorher leeren lassen, damit nichts Neueres als das Backup übrig bleibt.

Mit Projektverzeichnis vorher leeren löscht die Wiederherstellung erst alles im Projektordner und packt dann die Dateien aus, damit auch dort nichts Neueres stehen bleibt. Denk dabei daran, was das Backup weggelassen hat: Wurde es ohne Abhängigkeiten angelegt, fehlen danach vendor/ oder node_modules/, und du führst composer install oder npm install im Bereich Aktionen aus, bevor die Seite wieder läuft.

Schreibgeschützte Dateien und Ordner wie Drupals settings.php und sites/default werden trotzdem ersetzt und bekommen danach den Modus aus dem Backup zurück, auch wenn Envoryx ohne root läuft. Lassen sich die Dateien trotzdem nicht zurückspielen, etwa wegen eines Rechteproblems auf dem Host, nennt die Meldung die Datei und sagt dir, ob die Datenbank schon wiederhergestellt war. Zurückgerollt wird nichts, also behebst du die Ursache und stellst die Dateien noch einmal wieder her.

Redis wird nach der Wiederherstellung geleert, solange Redis danach leeren angehakt bleibt (das ist es von Haus aus, und das Kästchen erscheint nur, wenn das Projekt ein Redis hat, das Envoryx betreibt). Sitzungen, Objekt-Caches und wartende Jobs darin gehören zu den Daten von vor der Wiederherstellung, und WordPress oder Shopware würden munter weiter Seiten daraus ausliefern. Ist das Projekt gestoppt, startet Envoryx Redis nur dafür und stoppt es danach wieder. Ein externes Redis fasst es nie an, OpenSearch und die anderen Dienste auch nicht: Einen Suchindex baust du selbst neu auf, in Shopware mit bin/console es:index.

Willst du den aktuellen Stand behalten, stellst du das Backup stattdessen in ein neues Projekt wieder her: Der Knopf mit Kiste und Pfeil neben Wiederherstellen fragt nach Name, Verzeichnis und den Teilen, die mitkommen sollen. Das neue Projekt bekommt die Dienste und Versionen, die Variablen mit ihren Secrets, die Worker, Cronjobs und das Repository, mit denen das Backup gemacht wurde, dazu eigene Host-Ports und Container. Eine externe Datenbank oder ein externes Redis wird dabei zu einem, das Envoryx betreibt, wie beim Duplizieren. Backups von vor Envoryx 0.25 enthalten Worker, Cronjobs, Limits, Health-Check, Proxy-Regeln und eigene Images noch nicht; ein daraus wiederhergestelltes Projekt startet ohne sie.

Der Dialog In neues Projekt wiederherstellen für ein Backup von Acme Shop: Name und Verzeichnis des neuen Projekts und Häkchen für Datenbank, Dateien, Objektspeicher und den StartDer Dialog In neues Projekt wiederherstellen für ein Backup von Acme Shop: Name und Verzeichnis des neuen Projekts und Häkchen für Datenbank, Dateien, Objektspeicher und den Start

Beim Löschen eines Projekts bleiben seine Backups erhalten. Einstellungen → Backups → Backups gelöschter Projekte listet sie auf, und In neues Projekt wiederherstellen holt das Projekt aus einem davon zurück, auch unter seinem alten Namen. Backups, die du nicht mehr brauchst, löschst du dort ebenfalls. Das alles braucht Admin-Rechte für die ganze Instanz, weil das neue Projekt die Secrets des Backups bekommt. Die Projekteinstellungen im Backup sind mit dem Secret Key der Instanz versiegelt; das klappt also auf der Instanz, die das Backup gemacht hat, oder auf einer mit demselben Schlüssel.

Die Karte Backups gelöschter Projekte mit einem Backup von Old Landing Page und dem Knopf In neues Projekt wiederherstellen, darunter der Teil für ein Offsite-ZielDie Karte Backups gelöschter Projekte mit einem Backup von Old Landing Page und dem Knopf In neues Projekt wiederherstellen, darunter der Teil für ein Offsite-Ziel

Herunterladen gibt dir pro Backup ein Archiv, ein einfaches .tar, praktisch für eine Kopie an anderer Stelle. Um eins zurückzuholen, lad es so, wie es ist, unter Neues Projekt → Bestehende Website hoch: Envoryx erkennt dort seine eigenen Backups, legt den Upload als Backup seines Projekts ab (oder bei den Backups gelöschter Projekte) und bietet direkt In neues Projekt wiederherstellen an. So kannst du auch ein Projekt zu einem anderen Envoryx umziehen, solange es denselben geheimen Schlüssel hat. Hat es einen anderen, nennt dir die Fehlermeldung die ID des Schlüssels, den das Backup braucht.

Wenn du die Version einer Datenbank änderst, legt Envoryx vorher von selbst ein Datenbank-Backup an (erkennbar an der Quelle upgrade). Geht das Upgrade schief, kommst du also zurück.

Manchmal willst du nur schnell eine einzelne Datenbank sichern, etwa direkt vor einer Migration. Das ist ein Snapshot - siehe Datenbanken → Snapshots.

Terminal-Fenster
envoryx backup list shop
envoryx backup create shop # standardmäßig Datenbank + Dateien
envoryx backup restore shop <backup> --yes
envoryx backup download shop <backup> -o shop.tar
envoryx backup delete shop <backup> --yes

Zum Schluss noch: Backups auf demselben Rechner helfen wenig, wenn genau dieser Rechner ausfällt. Nimm den Backup-Ordner in deine normale Sicherung auf einem anderen Gerät auf, oder lass Envoryx die Backups mit Offsite-Backups selbst wegkopieren.