Speicher und Wiederherstellung
Wählen Sie den Speicher danach aus, welche Daten einen Prozessneustart, ein neues Deployment oder einen Host-Ausfall überstehen müssen. Das sind unterschiedliche Ereignisse. Persistenter Speicher bietet für sich allein weder ein Backup noch einen Wiederherstellungspunkt oder Hochverfügbarkeit.
| Daten | Wo sie gespeichert werden sollten | Grenze |
|---|---|---|
| Anwendungsdaten | Managed Postgres oder eine andere Datenbank | Ein Neustart ist etwas anderes als das Wiederherstellen gelöschter oder beschädigter Daten. Testen Sie einen separaten Export- und Wiederherstellungsweg. |
| Cache- und Queue-Daten | Managed Redis | Entscheiden Sie, ob die Workload ihren Zustand neu aufbauen kann oder einen eigenen Wiederherstellungsplan braucht. Managed Redis hat weder eine Eviction-Richtlinie noch ein Append-only-File: Wenn der Arbeitsspeicher ausgeht, startet es neu und neuere Schreibvorgänge können verloren gehen. Speichern Sie Daten, die Sie nicht verlieren dürfen, in Managed Postgres. |
| Von Anwendungen gemeinsam genutzte Dateien | Managed Object Storage | Der automatisch erstellte Bucket default ist privat. Machen Sie einen Bucket nur dann im Bucket-Browser des Dashboards öffentlich, wenn jeder seine Dateien lesen darf. |
Für Sandbox-Dateien gelten andere Regeln: Nur Dateien auf einem angehängten Volume aus Persistent Volumes unter /workspace oder in einem selbst erstellten Snapshot überdauern eine Sandbox. Siehe Speicher und Abrechnung.
Dateien nach dem Ende einer Sandbox behalten
Die Seite Volumes im Dashboard verwaltet benannte Volumes und ihre Verbindungen. Hängen Sie ein Volume bei der Erstellung an und schreiben Sie nach /workspace. Stoppen Sie die aktuelle Sandbox, bevor Sie das Volume an eine andere hängen.
Um eine ganze Sandbox samt Arbeitsspeicher zu behalten, speichern Sie sie mit lizard sandbox snapshot <id> und starten Sie später eine Kopie mit lizard sandbox restore <snapshot-id>; siehe Snapshots.
Gelöschte Ressourcen wiederherstellen
Ein gelöschtes Projekt bleibt mit seinen Apps und Datenbanken 3 Tage im Papierkorb, ebenso eine gelöschte Datenbank. Stellen Sie sie in dieser Zeit unter Gefahrenbereich in den Workspace- oder Projekteinstellungen wieder her; danach löscht Lizard sie endgültig.
- Eine einzeln gelöschte App kommt nur dann in den Papierkorb, wenn Sie sie mit
lizard upaus Dateien bereitgestellt haben; beim Wiederherstellen wird sie aus diesem Upload neu gebaut. Eine aus GitHub bereitgestellte App wird sofort gelöscht. - Sandboxes, ihre Volumes und Snapshots haben keinen Papierkorb. Wenn Sie sie oder ihr Projekt löschen, sind sie sofort weg.
- Auch für gelöschte Workspaces gibt es keinen Papierkorb.
Wiederherstellung einer Datenbank planen
Vor einer Migration oder einem Release, das Daten verändert:
- Wählen Sie eine Exportmethode für die verwendete Datenbank und Version.
- Speichern Sie den Export getrennt von der Ressource, die geändert wird.
- Stellen Sie ihn in einer separaten Testdatenbank wieder her und prüfen Sie, ob die Anwendung ihn lesen kann.
- Halten Sie die Dauer der Wiederherstellung und die neuesten im Export enthaltenen Daten fest.
Gehen Sie nicht davon aus, dass es geplante Backups, Point-in-Time-Recovery, Multi-Node-Replikation oder eine Garantie für die Wiederherstellungszeit gibt, nur weil eine Datenbank verwaltet wird. Prüfen Sie die aktuelle Servicevereinbarung und die verfügbaren Steuerungsmöglichkeiten für Ihre Ressource.
Umgebungsreferenzen
Eine Anwendung sollte ihre Datenbankverbindung aus einer Umgebungsreferenz lesen. Ein Connection String ist ein Zugangsdatengeheimnis; geben Sie ihn nicht aus, um eine Aktualisierung zu prüfen. Eine Verbindungsprüfung wie SELECT 1 belegt mehr, als die Variable nur in einer Shell zu sehen.
Verwandte Anleitungen
- Managed Postgres
- Managed Redis
- Managed Object Storage
- Persistent Volumes
- Deployment-Wiederherstellung
Aktualisiert