Speicher und Backups

Alles, was seine Daten über Neustarts hinweg behalten muss, etwa eine Datenbank, ein Upload-Verzeichnis oder eine Queue, bekommt ein persistentes Volume. Darauf setzt eine Engine für Backup und Wiederherstellung auf, die eine ganze App auf Anforderung per Snapshot sichert und sie in drei Modi zurückrollt. Zustandslose Apps brauchen nichts von dieser Seite.

Persistente Volumes einrichten

Das eigene Dateisystem eines Containers ist nur Arbeitsfläche. Wird der Pod neu gestartet oder neu eingeplant, ist alles weg, was nicht auf einem Volume liegt. Dauerhafter Speicher ist ein PersistentVolumeClaim, eingehängt im echten Datenverzeichnis der App. Ihr Agent fügt ihn dem Deployment hinzu, und nyxory stellt ihn aus dem Speicherkontingent Ihres Projekts bereit.

Die Standardform ist ein Deployment mit einem Replikat plus ein PVC. Brauchen Sie für Replikation oder Clustering eine stabile Identität und DNS pro Pod, nutzen Sie ein StatefulSet mit einem Headless Service (clusterIP: None) und Speicher pro Pod über volumeClaimTemplates.

Gleich bei der ersten Initialisierung richtig:

• Ab 10 GB dimensionieren. Jedes PVC braucht mindestens 10 Gi. Ein PVC lässt sich später vergrößern, aber nie verkleinern.
• Datenbanken auf ein Unterverzeichnis zeigen lassen. Ein frisches PVC enthält bereits lost+found, und die offiziellen Images von Postgres, MariaDB, MySQL, MongoDB und Elasticsearch weigern sich, in ein nicht leeres Verzeichnis zu initialisieren. Verwenden Sie einen Unterordner, z. B. PGDATA=/var/lib/postgresql/data/pgdata, oder einen subPath am Mount.
• Ein Knoten pro Volume. App-PVCs sind ReadWriteOnce, ein Pod mit PVC bleibt deshalb bei einem Replikat. Siehe Skalierung und RAM.

Volume oder Bucket, und was beim Löschen passiert

Wenn Sie eine App löschen, werden die Volumes und Buckets gelöscht, die ihr gehören. Um ein Volume zu behalten, rollen Sie es mit dem Label nyxory.com/retain-on-delete: "true" und ohne ownerReference auf die App aus. Es bleibt dann erhalten, wenn die App geht, und zählt weiter gegen Ihr Speicherkontingent, bis Sie es löschen (kubectl get pvc -l app.kubernetes.io/instance=<app>). Um einen Bucket zu behalten, setzen Sie deletionPolicy: Retain. Anders ist es bei einer Datenbank oder einem Bucket, die im Ordner deploy/ des Repos deklariert sind. Sie gehören zum Projekt und bleiben, wenn die App geht (siehe App aus dem Repo konfigurieren). Erstellen Sie ein Backup, bevor Sie etwas löschen, das Sie vielleicht zurückhaben wollen. Ein Restore im Modus full funktioniert auch dann noch, wenn die App schon gelöscht ist.

Sichern und wiederherstellen

Jede App lässt sich auf Anforderung sichern: eine crash-konsistente Momentaufnahme ihrer Volumes zu einem Zeitpunkt (CSI-Snapshots), dazu ihre Manifeste und das exakte Image, das sie ausgeführt hat. Erstellen Sie ein Backup vor einer riskanten Migration oder einem Release. Backups belegen die Keep-N-Plätze Ihres Tarifs (drei im Free-Tarif, mehr in den bezahlten Tarifen), jedes mit Auslöser, Größe, Phase und Image in der Betriebsakte.

Nutzen Sie die Console (Seite Backups oder die Backups auf der Seite einer App) oder Ihren Agenten über MCP. nyx_backup mit action: create erstellt ein Backup, nyx_backup_list listet sie auf.

Die Wiederherstellung läuft über nyx_backup mit action: restore oder über die Console, in einem von drei Modi:

• data: setzt die Volumes an Ort und Stelle zurück, die App-Definition bleibt unberührt.
• app: setzt Image und Definition zurück, die Daten bleiben, wie sie sind.
• full: die ganze App, auch nachdem die App gelöscht wurde.

Jede Wiederherstellung erstellt zuerst ein Sicherheits-Backup. Wiederherstellungen mit app und full schalten Auto-Deploy aus, damit ein Push dem Rollback nicht in die Quere kommt. Schalten Sie es im Panel Auto-deploy der App wieder ein, wenn Sie so weit sind.

Zeitgesteuerte Backups. Auf der geteilten nyxory-Plattform gibt es Backups derzeit auf Anforderung. Für eine nächtliche Kopie betreiben Sie einen eigenen Cronjob (einen nächtlichen Dump in Ihren Bucket, siehe Jobs und Cronjobs). Auf einer dedizierten Instanz lassen sich nächtliche Backups bereits für Ihre Instanz einschalten. Die Backup-Liste der App zeigt jeden Lauf mit seinem Auslöser.

Objektspeicher anbinden

Auf der geteilten nyxory-Plattform bringen Sie Ihren eigenen Bucket mit. Hinterlegen Sie die Zugangsdaten eines beliebigen S3-kompatiblen Endpunkts (AWS S3, Cloudflare R2, GCS, Backblaze B2) als Projekt- oder App-Secret und binden Sie sie mit envFrom ein. Backen Sie Schlüssel nie in ein Image oder eine ConfigMap ein. Eine Bucket-Ressource wird dort nicht bereitgestellt. nyx_deploy_manifests meldet sie als nicht unterstützt. Entfernen Sie sie deshalb aus dem Manifest und binden Sie stattdessen Ihren eigenen Bucket an.

Auf einer dedizierten Instanz mit Objektspeicher deklarieren Sie einen Bucket neben den Volumes und dem Deployment der App. Hat das App-Repo einen Ordner deploy/, gehört der Bucket dort als deploy/bucket.yaml hinein und bleibt bei jedem Push erhalten, siehe App aus dem Repo konfigurieren.

apiVersion: nyxory.com/v1alpha1
kind: Bucket
metadata:
  name: uploads
spec:
  deletionPolicy: Delete   # default; Retain keeps the bucket and its data when the resource goes
  versioning: false        # default; true keeps overwritten objects

nyxory legt den Bucket an und richtet den Zugriff im stärksten Modus ein, den die Instanz bietet (spec.credentials, Standard auto). Auf AWS erreicht die App den Bucket über die Identität ihres Pods, ganz ohne Schlüssel. Der Pod läuft unter serviceAccountName: <app>. Jede App des Projekts erreicht die Buckets des Projekts, keine App eines anderen Projekts. Bei anderen Anbietern bekommt der Bucket einen eigenen Zugangsschlüssel und eine Bucket-Policy, die jeden anderen Schlüssel ablehnt, auch die Schlüssel anderer Projekte. Die Verbindungswerte landen in einem Secret namens <bucket>-s3 im selben Projekt. Die App übernimmt das ganze Secret mit envFrom:

Schlüssel	Wert
S3_ENDPOINT, S3_REGION, S3_BUCKET	Wo der Bucket liegt
AWS_REGION, AWS_ENDPOINT_URL_S3	Dasselbe unter den Namen, die AWS-SDKs von selbst lesen
S3_ACCESS_KEY_ID, S3_SECRET_ACCESS_KEY, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY	Das eigene Schlüsselpaar dieses Buckets, nur im Schlüsselmodus
S3_FORCE_PATH_STYLE	true, wo der Endpunkt Path-Style nutzt. Stellen Sie Ihren S3-Client dann auf Path-Style, sonst schlagen Anfragen mit DNS-Fehlern fehl. false auf AWS.

Bauen Sie den Client mit der Standard-Credential-Chain des SDK, dann funktioniert derselbe Code in beiden Modi.

• Fünf Buckets pro Projekt sind der Standard. Die Kapazität ist nicht gedeckelt. Anzahl und Größe der Objekte werden etwa alle 15 Minuten gemessen und an der Ressource angezeigt.
• Versionierung ist das einzige Backup eines Buckets. App-Backups erfassen Objektspeicher nie.

MinIO selbst als App zu betreiben funktioniert ebenfalls. Es ist ein zustandsbehafteter Pod mit eigenem PVC aus Ihrem Speicherkontingent, und um seine Backups kümmern Sie sich selbst.

Daten exportieren

Auf der Seite einer App in der Console erstellt Export einen Snapshot des Volumes, legt ihn im Objektspeicher ab und gibt Ihnen einen zeitlich begrenzten Download-Link. Ein Ticket ist nicht nötig. Der Export umfasst die Volume-Daten der App. Ihre Manifeste liegen bei Ihrem Agenten und in Ihrem Repo. Export ist ab dem Starter-Tarif verfügbar.

Secret-Werte werden nach dem Speichern nicht wieder angezeigt, weder in der Console noch von nyx_set_secret. Workloads und Ihr Agent im selben Projekt können sie lesen, kein anderes Projekt kann das. Bewahren Sie eine eigene Kopie von allem auf, was Sie außerhalb von nyxory brauchen.