Einführung
Genau wie bei jedem anderen Setup kann auch die Daten in einem Kubernetes-Cluster gefährdet sein, verloren zu gehen. Um ernsthafte Probleme zu vermeiden, ist es unerlässlich, einen Datenwiederherstellungsplan zur Hand zu haben. Eine einfache und effektive Möglichkeit hierfür ist die Erstellung von Backups, um sicherzustellen, dass Ihre Daten im Falle unerwarteter Ereignisse sicher sind. Backups können einmalig oder geplant ausgeführt werden. Es ist ratsam, geplante Backups durchzuführen, um sicherzustellen, dass Sie ein aktuelles Backup haben, auf das Sie leicht zurückgreifen können.
Velero – ein Open-Source-Tool, das entwickelt wurde, um Backup- und Wiederherstellungsvorgänge für Kubernetes-Cluster zu unterstützen. Es eignet sich ideal für den Katastrophenschutz sowie zum Snapshot Ihrer Anwendungsdaten vor der Durchführung von Systemvorgängen auf Ihrem Cluster, wie z. B. Upgrades. Weitere Details zu diesem Thema finden Sie auf der offiziellen Seite So funktioniert Velero.
In diesem Tutorial erfahren Sie, wie Sie Velero in Ihrem Kubernetes-Cluster bereitstellen, Backups erstellen und sich im Falle eines Problems aus einem Backup wiederherstellen können. Sie können Ihren gesamten Cluster sichern oder optional einen Namespace oder einen Label-Selektor auswählen, um Ihren Cluster zu sichern.
Inhaltsverzeichnis
- Voraussetzungen
- Schritt 1 – Installation von Velero mit Helm
- Schritt 2 – Beispiel für Namespace-Backup und -Wiederherstellung
- Schritt 3 – Beispiel für Backup und Wiederherstellung des gesamten Clusters
- Schritt 4 – Geplante Backups
- Schritt 5 – Löschen von Backups
Voraussetzungen
Um dieses Tutorial abzuschließen, benötigen Sie folgendes:
- A DO Spaces Bucket and access keys. Save the access and secret keys in a safe place for later use.
- A DigitalOcean API token for Velero to use.
- A Git client, to clone the Starter Kit repository.
- Helm zur Verwaltung von Velero-Releases und Upgrades.
- Doctl für die Interaktion mit der DigitalOcean-API.
- Kubectl für die Interaktion mit Kubernetes.
- Velero-Client zur Verwaltung von Velero-Backups.
Schritt 1 – Installation von Velero mit Helm
In diesem Schritt werden Sie Velero und alle erforderlichen Komponenten bereitstellen, damit es Backups für die Ressourcen Ihres Kubernetes-Clusters (einschließlich PVs) durchführen kann. Die Backup-Daten werden im zuvor im Abschnitt Voraussetzungen erstellten DO Spaces-Bucket gespeichert.
Zuerst klonen Sie das Starter Kit Git-Repository und wechseln in das Verzeichnis Ihrer lokalen Kopie:
Als nächstes fügen Sie das Helm-Repository hinzu und listen die verfügbaren Charts auf:
Die Ausgabe sieht ähnlich wie folgt aus:
NAME CHART VERSION APP VERSION DESCRIPTION
vmware-tanzu/velero 2.29.7 1.8.1 A Helm chart for velero
Das interessante Chart ist vmware-tanzu/velero, das Velero auf dem Cluster installieren wird. Bitte besuchen Sie die Seite velero-chart für weitere Details zu diesem Chart.
Dann öffnen und inspizieren Sie die Velero Helm-Werte-Datei, die im Starter Kit-Repository bereitgestellt wird, mit einem Editor Ihrer Wahl (vorzugsweise mit YAML-Lint-Unterstützung).
Ersetzen Sie als nächstes die Platzhalter <> entsprechend für Ihren DO Spaces Velero-Bucket (wie Name, Region und Secrets). Stellen Sie sicher, dass Sie auch Ihren DigitalOcean API-Token bereitstellen (DIGITALOCEAN_TOKEN Schlüssel).
Zum Schluss installieren Sie Velero mit helm:
A specific version of the Velero Helm chart is used. In this case 2.29.7 is picked, which maps to the 1.8.1 version of the application (see the output from Step 2.). It’s a good practice in general to lock on a specific version. This helps to have predictable results and allows versioning control via Git.
–create-namespace \
Überprüfen Sie nun Ihre Velero-Bereitstellung, indem Sie folgendes ausführen:
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
velero velero 1 2022-06-09 08:38:24.868664 +0300 EEST deployed velero-2.29.7 1.8.1
Die Ausgabe sieht ähnlich wie folgt aus (die STATUS-Spalte sollte deployed anzeigen):
Als nächstes überprüfen Sie, ob Velero betriebsbereit ist:
NAME READY UP-TO-DATE AVAILABLE AGE
velero 1/1 1 1 67s
Die Ausgabe sieht ähnlich wie folgt aus (Bereitstellungs-Pods müssen sich im Ready-Zustand befinden):
Wenn Sie weiter recherchieren möchten, können Sie die Server-seitigen Komponenten von Velero anzeigen:
- Erkunden Sie die Hilfe-Seiten der Velero-Befehlszeilenschnittstelle, um zu sehen, welche Befehle und Unterbefehle verfügbar sind. Sie können für jeden Hilfe mit dem
--help-Flag erhalten: - Liste alle verfügbaren Befehle für
Velero:
Liste die Optionen des backup-Befehls für Velero:
Velero verwendet mehrere CRDs (Custom Resource Definitions), um seine Ressourcen wie Backups, Backup-Zeitpläne usw. darzustellen. Sie werden jede im nächsten Schritt des Tutorials kennenlernen, zusammen mit einigen grundlegenden Beispielen.
Schritt 2 – Beispiel für Sicherung und Wiederherstellung im Namespace
In diesem Schritt lernen Sie, wie Sie ein einmaliges Backup für einen gesamten Namensraum von Ihrem DOKS-Cluster durchführen und es anschließend wiederherstellen, wobei sichergestellt wird, dass alle Ressourcen neu erstellt werden. Der betreffende Namensraum ist ambassador.
Erstellen des Ambassador Namensraum-Backups
Zuerst starten Sie das Backup:
Als nächstes überprüfen Sie, ob das Backup erstellt wurde:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
ambassador-backup Completed 0 0 2021-08-25 19:33:03 +0300 EEST 29d default <none>
Die Ausgabe sieht ähnlich aus wie:
Dann, nach ein paar Momenten, können Sie es inspizieren:
Name: ambassador-backup
Namespace: velero
Labels: velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: ambassador
Excluded: <none>
...
- Die Ausgabe sieht ähnlich aus wie:
- Suchen Sie nach der Zeile
Phase. Es sollteAbgeschlossensagen. - Überprüfen Sie auch, dass keine Fehler gemeldet werden.
Ein neues Kubernetes-Backup-Objekt wird erstellt:
~ kubectl get backup/ambassador-backup -n velero -o yaml
apiVersion: velero.io/v1
kind: Backup
metadata:
annotations:
velero.io/source-cluster-k8s-gitversion: v1.21.2
velero.io/source-cluster-k8s-major-version: "1"
velero.io/source-cluster-k8s-minor-version: "21"
...
Zuletzt werfen Sie einen Blick auf den DO Spaces-Bucket und überprüfen, ob ein neuer Ordner namens backups vorhanden ist, der die für Ihr ambassador-backup erstellten Assets enthält:
Löschen des Ambassador-Namensraums und der Ressourcen
Zuerst simulieren Sie eine Katastrophe, indem Sie den ambassador-Namensraum absichtlich löschen:
Anschließend überprüfen Sie, ob der Namensraum gelöscht wurde (die Auflistung der Namensräume sollte nicht ambassador ausdrucken):
Zum Schluss überprüfen Sie, ob das Endpunkt der echo– und quote-Backend-Dienste DOWN ist. Bitte beachten Sie die Anleitung zur Erstellung der Backend-Dienste des Ambassador Edge Stack bezüglich der Backend-Anwendungen, die im Starter Kit Tutorial verwendet werden. Sie können curl zum Testen verwenden (oder Ihren Webbrowser verwenden):
Wiederherstellen des Ambassador-Namensraum-Backups
Stellen Sie das ambassador-backup wieder her:
Wichtig: Wenn Sie den ambassador-Namespace löschen, wird auch die Lastenausgleichsressource, die mit dem Ambassador-Dienst verbunden ist, gelöscht. Wenn Sie den ambassador-Dienst wiederherstellen, wird der Lastenausgleich von DigitalOcean neu erstellt. Das Problem hierbei ist, dass Sie eine NEUE IP-Adresse für Ihren Lastenausgleich erhalten, sodass Sie die A-Records anpassen müssen, um den Verkehr zu den auf dem Cluster gehosteten Domänen zu leiten.
Überprüfung der Wiederherstellung des Ambassador-Namespaces
Um die Wiederherstellung des ambassador-Namespace zu überprüfen, überprüfen Sie die Zeile Phase aus der Ausgabe des Befehls ambassador-backup restore. Es sollte Abgeschlossen stehen (beachten Sie auch den Abschnitt „Warnungen“ – er gibt an, ob etwas schief gelaufen ist):
Als nächstes überprüfen Sie, ob alle Ressourcen für den ambassador-Namespace wiederhergestellt wurden. Suchen Sie nach den ambassador-Pods, Services und Deployments.
NAME READY STATUS RESTARTS AGE
pod/ambassador-5bdc64f9f6-9qnz6 1/1 Running 0 18h
pod/ambassador-5bdc64f9f6-twgxb 1/1 Running 0 18h
pod/ambassador-agent-bcdd8ccc8-8pcwg 1/1 Running 0 18h
pod/ambassador-redis-64b7c668b9-jzxb5 1/1 Running 0 18h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ambassador LoadBalancer 10.245.74.214 159.89.215.200 80:32091/TCP,443:31423/TCP 18h
service/ambassador-admin ClusterIP 10.245.204.189 <none> 8877/TCP,8005/TCP 18h
service/ambassador-redis ClusterIP 10.245.180.25 <none> 6379/TCP 18h
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ambassador 2/2 2 2 18h
deployment.apps/ambassador-agent 1/1 1 1 18h
deployment.apps/ambassador-redis 1/1 1 1 18h
NAME DESIRED CURRENT READY AGE
replicaset.apps/ambassador-5bdc64f9f6 2 2 2 18h
replicaset.apps/ambassador-agent-bcdd8ccc8 1 1 1 18h
replicaset.apps/ambassador-redis-64b7c668b9 1 1 1 18h
Die Ausgabe sieht ähnlich aus wie:
Ambassador-Hosts abrufen:
NAME HOSTNAME STATE PHASE COMPLETED PHASE PENDING AGE
echo-host echo.starter-kit.online Ready 11m
quote-host quote.starter-kit.online Ready 11m
Die Ausgabe sieht ähnlich aus wie:
STATUS sollte Bereit sein und die HOSTNAME-Spalte sollte auf den vollqualifizierten Hostnamen verweisen.
Ambassador-Mappings abrufen:
NAME SOURCE HOST SOURCE PREFIX DEST SERVICE STATE REASON
ambassador-devportal /documentation/ 127.0.0.1:8500
ambassador-devportal-api /openapi/ 127.0.0.1:8500
ambassador-devportal-assets /documentation/(assets|styles)/(.*)(.css) 127.0.0.1:8500
ambassador-devportal-demo /docs/ 127.0.0.1:8500
echo-backend echo.starter-kit.online /echo/ echo.backend
quote-backend quote.starter-kit.online /quote/ quote.backend
Die Ausgabe sieht ähnlich aus (beachten Sie das echo-backend, das auf den Host echo.starter-kit.online und das Quellpräfix /echo/ abgebildet ist, ebenso wie für quote-backend):
Zum Schluss, nachdem Sie Ihren Lastenausgleicher und die Einstellungen Ihrer DigitalOcean-Domain neu konfiguriert haben, überprüfen Sie bitte, dass der Endpunkt der Backend-Services echo und quote UP ist. Siehe Erstellen der Ambassador Edge Stack Backend-Services.
Im nächsten Schritt simulieren Sie eine Katastrophe, indem Sie Ihren DOKS-Cluster absichtlich löschen.
Schritt 3 – Beispiel für das Sichern und Wiederherstellen des gesamten Clusters
In diesem Schritt simulieren Sie ein Szenario für die Wiederherstellung nach einer Katastrophe. Der gesamte DOKS-Cluster wird gelöscht und dann aus einem vorherigen Backup wiederhergestellt.
Erstellen des Backups für den DOKS-Cluster
Zuerst erstellen Sie ein Backup für den gesamten DOKS-Cluster:
Als nächstes überprüfen Sie, ob das Backup erstellt wurde und keine Fehler gemeldet werden. Der folgende Befehl listet alle verfügbaren Backups auf:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
all-cluster-backup Completed 0 0 2021-08-25 19:43:03 +0300 EEST 29d default <none>
Die Ausgabe sieht ähnlich aus wie:
Zum Schluss überprüfen Sie den Zustand des Backups und die Protokolle (überprüfen Sie, dass keine Fehler gemeldet werden):
Wichtig: Wenn Sie einen DOKS-Cluster ohne Angabe des --dangerous-Flags an den doctl-Befehl zerstören und dann wiederherstellen, wird der gleiche Lastenausgleicher mit derselben IP-Adresse neu erstellt. Dies bedeutet, dass Sie Ihre DigitalOcean DNS-A-Datensätze nicht aktualisieren müssen.
Wenn jedoch das --dangerous-Flag auf den doctl-Befehl angewendet wird, wird der vorhandene Lastenausgleicher zerstört und ein neuer Lastenausgleicher mit einer neuen externen IP erstellt, wenn Velero Ihren Ingress-Controller wiederherstellt. Stellen Sie daher sicher, dass Sie Ihre DigitalOcean DNS-A-Datensätze entsprechend aktualisieren.
Zuerst löschen Sie den gesamten DOKS-Cluster (stellen Sie sicher, dass Sie die Platzhalter <> entsprechend ersetzen).
Um den Kubernetes-Cluster zu löschen, ohne den zugehörigen Lastenausgleicher zu zerstören, führen Sie Folgendes aus:
Oder um den Kubernetes-Cluster zusammen mit dem zugehörigen Lastenausgleicher zu löschen:
Als nächstes erstellen Sie den Cluster neu, wie in Einrichten von DigitalOcean Kubernetes beschrieben. Es ist wichtig sicherzustellen, dass die Anzahl der neuen DOKS-Clusterknoten gleich oder größer als die der Originalen ist.
Dann installieren Sie die Velero CLI und den Server gemäß den Anforderungen in Abschnitt Voraussetzungen und Schritt 1 – Installation von Velero mit Helm. Es ist wichtig, dieselbe Helm-Chart-Version zu verwenden.
Zum Schluss stellen Sie alles wieder her, indem Sie den folgenden Befehl ausführen:
Überprüfen des Zustands der DOKS-Clusteranwendungen
Zuerst überprüfen Sie die Phase-Zeile des Ausgabeergebnisses des Befehls all-cluster-backup restore describe. (Ersetzen Sie die Platzhalter <> entsprechend). Es sollte Abgeschlossen anzeigen.
Überprüfen Sie nun alle Clusterressourcen, indem Sie folgenden Befehl ausführen:
Jetzt sollten auch die Backend-Anwendungen auf HTTP-Anfragen antworten. Bitte beachten Sie Erstellen der Ambassador Edge Stack-Backend-Dienste in Bezug auf die im Starter-Kit-Tutorial verwendeten Backend-Anwendungen.
Im nächsten Schritt erfahren Sie, wie Sie geplante (oder automatische) Backups für Ihre DOKS-Cluster-Anwendungen durchführen können.
Automatische Backups basierend auf einem Zeitplan sind eine wirklich nützliche Funktion. Sie ermöglicht es Ihnen, die Zeit zurückzudrehen und das System auf einen früheren funktionierenden Zustand wiederherzustellen, wenn etwas schief geht.
Das Erstellen eines geplanten Backups ist ein sehr einfacher Vorgang. Nachfolgend wird ein Beispiel für ein Intervall von 1 Minute angegeben (der Namespace kube-system wurde ausgewählt).
Zuerst erstellen Sie den Zeitplan:
schedule="*/1 * * * *"
Das Linux-Cronjob-Format wird ebenfalls unterstützt:
Überprüfen Sie dann, ob der Zeitplan erstellt wurde:
NAME STATUS CREATED SCHEDULE BACKUP TTL LAST BACKUP SELECTOR
kube-system-minute-backup Enabled 2021-08-26 12:37:44 +0300 EEST @every 1m 720h0m0s 32s ago <none>
Die Ausgabe ähnelt dem folgenden Beispiel:
Anschließend überprüfen Sie alle Backups nach etwa einer Minute:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
kube-system-minute-backup-20210826093916 Completed 0 0 2021-08-26 12:39:20 +0300 EEST 29d default <none>
kube-system-minute-backup-20210826093744 Completed 0 0 2021-08-26 12:37:44 +0300 EEST 29d default <none>
Die Ausgabe ähnelt dem folgenden Beispiel:
Überprüfen des Zustands des geplanten Backups
Überprüfen Sie zuerst die Zeile Phase eines der Backups (ersetzen Sie bitte die Platzhalter <> entsprechend). Sie sollte Abgeschlossen anzeigen.
Schließlich, nehmen Sie mögliche Fehler und Warnungen aus der obigen Ausgabe zur Kenntnis, um zu überprüfen, ob etwas schief gelaufen ist.
Wiederherstellung des geplanten Backups
Um Backups von vor einer Minute wiederherzustellen, folgen Sie bitte den gleichen Schritten, die Sie in den vorherigen Schritten dieses Tutorials gelernt haben. Dies ist eine gute Möglichkeit, Ihre bisher gesammelte Erfahrung zu üben und zu testen.
Im nächsten Schritt erfahren Sie, wie Sie bestimmte Backups, die Sie im Laufe der Zeit erstellt haben, manuell oder automatisch löschen können.
Wenn Sie ältere Backups nicht benötigen, können Sie Ressourcen sowohl im Kubernetes-Cluster als auch im Velero DO Spaces-Bucket freigeben.
Manuelles Löschen eines Backups
Wählen Sie zunächst ein Backup von einer Minute aus, und geben Sie dann den folgenden Befehl ein (ersetzen Sie bitte die Platzhalter <> entsprechend):
Jetzt überprüfen Sie, dass es aus der Ausgabe des Befehls velero backup get verschwunden ist. Es sollte auch aus dem DO Spaces-Bucket gelöscht werden.
Als nächstes löschen Sie mehrere Backups auf einmal, indem Sie einen Selector verwenden. Der Unterbefehl velero backup delete bietet ein Flag namens --selector. Es ermöglicht Ihnen, mehrere Backups gleichzeitig basierend auf Kubernetes-Labels zu löschen. Die gleichen Regeln gelten wie für Kubernetes-Label-Selektoren.
Zuerst listen Sie die verfügbaren Backups auf:
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
ambassador-backup Completed 0 0 2021-08-25 19:33:03 +0300 EEST 23d default <none>
backend-minute-backup-20210826094116 Completed 0 0 2021-08-26 12:41:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826094016 Completed 0 0 2021-08-26 12:40:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093916 Completed 0 0 2021-08-26 12:39:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093816 Completed 0 0 2021-08-26 12:38:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093716 Completed 0 0 2021-08-26 12:37:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093616 Completed 0 0 2021-08-26 12:36:16 +0300 EEST 24d default <none>
backend-minute-backup-20210826093509 Completed 0 0 2021-08-26 12:35:09 +0300 EEST 24d default <none>
Die Ausgabe sieht ähnlich aus wie:
Dann sagen Sie, dass Sie alle backend-minute-backup-* Assets löschen möchten. Wählen Sie ein Backup aus der Liste aus und überprüfen Sie die Labels:
Name: backend-minute-backup-20210826094116
Namespace: velero
Labels: velero.io/schedule-name=backend-minute-backup
velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: backend
Excluded: <none>
...
Die Ausgabe sieht ähnlich aus wie (beachten Sie den Wert des Labels velero.io/schedule-name):
Anschließend können Sie alle Backups löschen, die mit dem Wert backend-minute-backup des Labels velero.io/schedule-name übereinstimmen:
Zum Schluss überprüfen Sie, dass alle backend-minute-backup-* Assets aus der Ausgabe des Befehls velero backup get sowie aus dem DO Spaces-Bucket verschwunden sind.
Automatische Backup-Löschung über TTL
- Beim Erstellen eines Backups können Sie eine TTL (Time To Live) angeben, indem Sie die
--ttl-Flag verwenden. Wenn Velero feststellt, dass eine vorhandene Backup-Ressource abgelaufen ist, entfernt es: - Die
Backup-Ressource - Die Backup-Datei aus dem Cloud-Objektspeicher
storage - Alle
PersistentVolume-Snapshots
Alle zugehörigen Restores
Die TTL-Flagge ermöglicht es dem Benutzer, die Aufbewahrungsdauer des Backups mit dem in Stunden, Minuten und Sekunden angegebenen Wert im Format --ttl 24h0m0s anzugeben. Wenn nicht angegeben, wird ein Standard-TTL-Wert von 30 Tagen angewendet.
Zunächst erstellen Sie das Ambassador-Backup mit einem TTL-Wert von 3 Minuten:
Als nächstes inspizieren Sie das Ambassador-Backup:
Name: ambassador-backup-3min-ttl
Namespace: velero
Labels: velero.io/storage-location=default
Annotations: velero.io/source-cluster-k8s-gitversion=v1.21.2
velero.io/source-cluster-k8s-major-version=1
velero.io/source-cluster-k8s-minor-version=21
Phase: Completed
Errors: 0
Warnings: 0
Namespaces:
Included: ambassador
Excluded: <none>
Resources:
Included: *
Excluded: <none>
Cluster-scoped: auto
Label selector: <none>
Storage Location: default
Velero-Native Snapshot PVs: auto
TTL: 3m0s
...
A new folder should be created in the DO Spaces Velero bucket as well, named ambassador-backup-3min-ttl.
Die Ausgabe sieht ähnlich aus wie folgt (achten Sie auf den Abschnitt Namespaces -> Included – er sollte ambassador anzeigen, und das TTL-Feld ist auf 3ms0 gesetzt):
Zuletzt sollten nach etwa drei Minuten das Backup und die zugehörigen Ressourcen automatisch gelöscht werden. Sie können überprüfen, ob das Backup-Objekt zerstört wurde, indem Sie verwenden: velero backup describe ambassador-backup-3min-ttl. Es sollte mit einem Fehler fehlschlagen, der besagt, dass das Backup nicht mehr existiert. Der entsprechende Ordner ambassador-backup-3min-ttl aus dem DO Spaces Velero-Bucket wird ebenfalls gelöscht.
Weiterführend können Sie alle verfügbaren velero backup delete-Optionen erkunden, über:
In diesem Tutorial haben Sie gelernt, wie Sie einmalige sowie geplante Backups durchführen und alles wiederherstellen können. Geplante Backups sind sehr wichtig, da sie es ermöglichen, zu einem früheren Zeitpunkt zurückzukehren, wenn unterwegs etwas schief geht. Sie haben auch ein Szenario zur Katastrophenwiederherstellung durchlaufen.
- Mehr erfahren
- Daten von DOKS sichern und wiederherstellen mit Velero
- Digitale Ozean verwaltete Kubernetes-Backups mit SnapShooter
Volumes aus Snapshots in Kubernetes-Clustern wiederherstellen