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.


Was drinsteckt
Abschnitt betitelt „Was drinsteckt“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.
Wo die Backups liegen
Abschnitt betitelt „Wo die Backups liegen“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.
Automatisch nach Zeitplan
Abschnitt betitelt „Automatisch nach Zeitplan“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 und herunterladen
Abschnitt betitelt „Wiederherstellen und herunterladen“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.


Ein gelöschtes Projekt zurückholen
Abschnitt betitelt „Ein gelöschtes Projekt zurückholen“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.


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.
Snapshots
Abschnitt betitelt „Snapshots“Manchmal willst du nur schnell eine einzelne Datenbank sichern, etwa direkt vor einer Migration. Das ist ein Snapshot - siehe Datenbanken → Snapshots.
Auf der Kommandozeile
Abschnitt betitelt „Auf der Kommandozeile“envoryx backup list shopenvoryx backup create shop # standardmäßig Datenbank + Dateienenvoryx backup restore shop <backup> --yesenvoryx backup download shop <backup> -o shop.tarenvoryx backup delete shop <backup> --yesZum 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.