כיצד לגבות ולשחזר נתונים של אשכול DOKS באמצעות Velero

מדריכים
Backups Kubernetes

הקדמה

כמו כל הגדרה אחרת, הנתונים באשכול Kubernetes עשויים להיאבד. כדי למנוע בעיות רציניות, חיוני להכין תוכנית לשחזור נתונים. דרך פשוטה ויעילה לעשות זאת היא על ידי ביצוע גיבויים, וודאות שהנתונים שלך בטוחים במקרה של אירועים בלתי צפויים. גיבויים יכולים להיבצע כגיבוי חד-פעמי או מתוכנת. כדאי לבצע גיבויים מתוכנתים כדי לוודא שיש לך גיבוי אחרון שניתן לשחזר אליו בקלות.

Velero – כלי מקור פתוח המיועד לעזור בפעולות שחזור וגיבוי עבור אשכולות Kubernetes. הוא אידיאלי למקרי שחזור מקרי כאסון, כמו גם ליצירת צילומי מצב של היישום שלך לפני ביצוע פעולות מערכת על האשכול שלך, כמו שדרוגים. לפרטים נוספים על נושא זה, בקרו בדף הרשמי של איך עובד Velero.

במדריך זה, תלמדו איך להשיג את Velero לאשכול Kubernetes שלכם, ליצור גיבויים ולשחזר מגיבוי אם משהו הולך לא נכון. ניתן לגבות את כל האשכול שלך או לבחור באפשרות לגבות רווחה או למתווה תווית כדי לגבות את האשכול שלך.

תוכן עניינים

דרישות מוקדמות

כדי להשלים את המדריך הזה, יש לך צורך בפריטים הבאים:

  • 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 לניהול התקנות ושדרוגים של Velero.
  • Doctl לאינטראקציה עם API של DigitalOcean.
  • Kubectl לאינטראקציה עם Kubernetes.
  • לקוח Velero כדי לנהל גיבויים של Velero.

שלב 1 – התקנת Velero באמצעות Helm

בשלב זה, תמינה את Velero וכל הרכיבים הדרושים, כך שיהיה אפשרות לבצע גיבויים עבור משאבי הקשורים של האשכול שלך ב-Kubernetes (כולל PV's). נתוני הגיבוי יאוחסנו בדלי DO Spaces שנוצר בשלב הקודם בסעיף הדרישות מראש.

ראשית, שכפל את ריפוזיטורי ה-Git של קיט ההתחלה ושנה את התיקייה לעותק המקומי שלך:

git clone https://github.com/digitalocean/Kubernetes-Starter-Kit-Developers.git

cd Kubernetes-Starter-Kit-Developers

לאחר מכן, הוסף את רפוזיטורי ה-Helm ורשום את התרשיםים הזמינים:

helm repo add vmware-tanzu https://vmware-tanzu.github.io/helm-charts

helm repo update vmware-tanzu

helm search repo vmware-tanzu

הפלט דומה להבא:

NAME                    CHART VERSION   APP VERSION     DESCRIPTION
vmware-tanzu/velero     2.29.7          1.8.1           A Helm chart for velero

התרשים שסקיים הוא vmware-tanzu/velero, שיתקין את Velero על האשכול. נא לבקר בדף תרשים Velero לפרטים נוספים אודות תרשים זה.

לאחר מכן, פתח ובדוק את קובץ הערכות Helm של Velero שסופק ברפוזיטורי קיט ההתחלה באמצעות עורך שלך לבחירה (רצוי עם תמיכת YAML lint). 

VELERO_CHART_VERSION="2.29.7"

code 05-setup-backup-restore/assets/manifests/velero-values-v${VELERO_CHART_VERSION}.yaml

באמצעות תחליפה עליך להחליף את המילות <> בהתאם לדלי ה-Velero שלך ב-DO Spaces (כמו שם, אזור וסודות). ודא שסיפקת את האסימון של API שלך של DigitalOcean גם (DIGITALOCEAN_TOKEN מפתח).

לבסוף, התקן את Velero באמצעות helm:

VELERO_CHART_VERSION="2.29.7"

helm install velero vmware-tanzu/velero --version "${VELERO_CHART_VERSION}" \
  --namespace velero \
  --create-namespace \
  -f 05-setup-backup-restore/assets/manifests/velero-values-v${VELERO_CHART_VERSION}.yaml

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 \

helm ls -n velero

עכשיו, בדוק את הפיתוח של Velero שלך על ידי הרצת:

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

הפלט דומה להבא (עמודת STATUS צריכה להציג deployed):

kubectl get deployment velero -n velero

לבסוף, וודא ש-Velero פועל ופועל:

NAME     READY   UP-TO-DATE   AVAILABLE   AGE
velero   1/1     1            1           67s

הפלט דומה לזהו (קבוצות הפיתוח חייבות להיות במצב Ready):

kubectl -n velero get all

אם אתה מעוניין לחפש עוד, תוכל לצפות ברכיבי השרת של Velero:

  • עיין בעמודי העזרה של Velero CLI כדי לראות אילו פקודות ותת-פקודות זמינות. תוכל לקבל עזרה לכל אחת מהן באמצעות הדגל --help:
  • רשימת כל הפקודות הזמינות עבור Velero:

רשימת האפשרויות של פקודת backup עבור Velero:

Velero משתמשת במספר CRDs (Custom Resource Definitions) כדי לייצג את המשאבים שלה כמו גיבויים, לוחות זמנים לגיבוי וכו '. תגלה כל אחת מהן בשלבים הבאים של המדריך, ביחד עם דוגמאות בסיסיות.

שלב 2 – דוגמא לגיבוי ושחזור שם מרחב

בשלב זה, תלמד כיצד לבצע גיבוי חד-פעמי עבור מרחב שמורה מהקשת שלך של DOKS ולשחזר אותו לאחר מכן, בודקים שכל המשאבים נוצרים מחדש. המרחב שמורה המדובר הוא ambassador.

יצירת גיבוי למרחב שמור Ambassador

velero backup create ambassador-backup --include-namespaces ambassador

ראשית, התחל את הגיבוי:

velero backup get

לאחר מכן, בדוק שהגיבוי נוצר:

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>

הפלט דומה ל:

velero backup describe ambassador-backup --details

לאחר מספר רגעים, תוכל לבדוק אותו:

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>
  ...
  • הפלט דומה ל:
  • חפש את השורה Phase. היא אמורה לומר Completed.
  • ודא שאין דיווחים על שגיאות גם כן.

נוצר עצם גיבוי חדש של Kubernetes:

~ 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"
...

לבסוף, בדוק את קופסת ה-DO Spaces וודא שיש תיקייה חדשה בשם backups שמכילה את הנכסים שנוצרו עבור גיבוי ה-ambassador-backup:

מחיקת שם הנציג והמשאבים

kubectl delete namespace ambassador

ראשית, הדמיה של אסון על ידי מחיקה מכווינה של הקונספט ambassador: 

kubectl get namespaces

בשלב הבא, בדוק שהשם הנציג נמחק (רשימת השמות לא תדפיס ambassador): 

curl -Li http://quote.starter-kit.online/quote/

curl -Li http://echo.starter-kit.online/echo/

לבסוף, וודא שהנקודת קצה של השירותים האחוריים echo ו־quote היא DOWN. נא הפנה ל־יצירת שירותי נקודת הקצה של מערכת השרות של השגריר בנוגע ליישומים האחוריים המשמשים במדריך לתכנית ההתחלה. באפשרותך להשתמש ב־curl לבדיקה (או בדפדפן האינטרנט שלך):

שחזור גיבוי שם הנציג

velero restore create --from-backup ambassador-backup

שחזר את הגיבוי של ambassador-backup:

חשוב: כאשר אתה מוחק את מרחב השמות ambassador, המשאב של מאזין העומס המשויך לשירות האמבסדור יימחק גם כן. לכן, כאשר אתה משחזר את שירות הambassador, המאזין לעומס ייבנה מחדש על ידי DigitalOcean. הבעיה כאן היא שתקבל כתובת IP חדשה עבור המאזין לעומס שלך, ולכן תצטרך להתאים את הרשומות A כדי לקבל תעבורה לתחומים שלך שמארחים באשכול.

בדיקת שחזור מרחב השמות של השגריר

velero restore describe ambassador-backup

כדי לוודא את השחזור של מרחב השמות ambassador, בדוק את השורה Phase מתוך פלט הפקודה לשחזור ambassador-backup. זה צריך לומר הושלם (גם, יש לשים לב לסעיפי אזהרה – הוא מספר אם משהו השתבש):

kubectl get all --namespace ambassador

לאחר מכן, בדוק כי כל המשאבים נשחזרו עבור מרחב השמות ambassador. חפש את כל הקיימים ambassador pods, services, ו- 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

הפלט דומה ל:

kubectl get hosts -n ambassador

קבל את מארחי השגריר:

NAME         HOSTNAME                   STATE   PHASE COMPLETED   PHASE PENDING   AGE
echo-host    echo.starter-kit.online    Ready                                     11m
quote-host   quote.starter-kit.online   Ready                                     11m

הפלט דומה ל:

STATE צריך להיות Ready והעמודה HOSTNAME צריכה להפנות לשם מתמחה מלא.

kubectl get mappings -n ambassador

קבל עימודי שגריר:

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

הפלט נראה דומה ל (שים לב ל־echo-backend שממופה על המארח echo.starter-kit.online ולקידום /echo/, וכן ל־quote-backend):

curl -Li https://quote.starter-kit.online/quote/

curl -Li https://echo.starter-kit.online/echo/

לבסוף, לאחר שתקבע את ההגדרות של המאיץ הטעינה והדומיין שלך ב־DigitalOcean, אנא אמת כי נקודת הקצה של שירותי הרקע echo ו־quote היא UP. הפנה אל יצירת שירותי רקע של מאיץ הקצה של השגרה.

בשלב הבא, תדמה פגיעה על ידי מחיקת עקבי ה־DOKS שלך.

שלב 3 – דוגמת גיבוי ושחזור של עקב כולו

בשלב זה, תדמה תרחיש שחזור פגיעה. העקב כולו של DOKS ימחק ואז ישוחזר מגיבוי קודם.

יצירת גיבוי לעקב DOKS

velero backup create all-cluster-backup

ראשית, צור גיבוי עבור כל עקב DOKS:

velero backup get

הבא, בדוק שהגיבוי נוצר ואין דיווחים על שגיאות. הפקודה הבאה מפרטת את כל הגיבויים הזמינים: 

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>

הפלט דומה למראה הבא: 

velero backup describe all-cluster-backup

velero backup logs all-cluster-backup

לבסוף, בדוק את מצב הגיבוי והיומנים (ובדוק שאין שגיאות מדווחות):

שחזור את אפליקציות האשכול DOKS והחדש

חשוב: כל פעם שאתה מורס את אשכול DOKS בלי לציין את הדגל --dangerous לפקודה doctl ואז מחדש אותו, הטעינה האוטומטית עם אותו כתובת IP חוזרת ליצור. זה אומר שאין צורך לעדכן את רשומות ה-DNS של DigitalOcean שלך ב-A records.
אך כאשר הדגל --dangerous מיושם על הפקודה doctl, הטעינה הקיימת תימחק וטעינה חדשה תיווצר עם כתובת IP חיצונית חדשה כאשר Velero משחזר את בקר ה-ingress שלך. לכן, ודא שתעדכן את רשומות ה-DNS שלך ב-A records של DigitalOcean בהתאם.

למחוק את האשכול DOKS בשלמותו (ודא שאתה מחליף את המציין <> בהתאם). 

doctl kubernetes cluster delete <DOKS_CLUSTER_NAME>

כדי למחוק את אשכול ה-Kubernetes מבלי להשמיד את מאזני העומס המשויכים, הריץ: 

doctl kubernetes cluster delete <DOKS_CLUSTER_NAME> --dangerous

או כדי למחוק את אשכול ה-Kubernetes יחד עם מאזני העומס המשויכים:

אחר כך, שחזר את האשכול כפי שמתואר ב־הגדרת Kubernetes של DigitalOcean. חשוב לוודא שמספר צמתי ה־DOKS החדש שווה או גדול מהמקורי.

לאחר מכן, התקן את CLI ושרת Velero, כפי שמתואר בסעיפי הנדרשים וב־שלב 1 – התקנת Velero באמצעות Helm בהתאמה. חשוב להשתמש באותו גרסת Helm Chart.

velero restore create --from-backup all-cluster-backup

לבסוף, שחזר את הכל על ידי הרצת הפקודה הבאה:

בדיקת מצב היישומים ב־DOKS Cluster

velero restore describe all-cluster-backup-<timestamp>

בתחילה, בדוק את השורה Phase של פלט הפקודה describe של השחזור של all-cluster-backup. (החלף את התופסנות ה־<> בהתאם). צריך שיהיה כתוב Completed.

kubectl get all --all-namespaces

עכשיו, בדוק את כל המשאבים באשכול על ידי הרצת:

curl -Li http://quote.starter-kit.online/quote/

curl -Li http://echo.starter-kit.online/echo/

עכשיו, יש צריכה להיות תגובה לבקשות HTTP מצד אפליקציות האחוריות. נא להפנות ל־יצירת שירותי האחורית של סטאק ה־Ambassador Edge לגבי האפליקציות האחוריות שמשמשות במדריך להתחלה.

בשלב הבא, תלמד כיצד לבצע גיבויים מתוזמנים (או אוטומטיים) עבור יישומי קבוצת ה- DOKS שלך.

שלב 4 – גיבויים מתוזמנים

גיבויים אוטומטיים בהתבסס על לוח זמנים הוא תכונה מאוד שימושית. זה מאפשר לך לשוב אחורה בזמן ולשחזר את המערכת למצב עבודה קודם אם משהו מתפרץ.

יצירת גיבוי מתוזמן היא תהליך פשוט מאוד. דוגמה מסופקת למשך דקה אחת (נבחר ה- קובה-מערכת של שמות מרחבי השמות).

velero schedule create kube-system-minute-backup --schedule="@every 1m" --include-namespaces kube-system

ראשית, צור את הלוח זמנים:

schedule="*/1 * * * *"

פורמט cronjob של Linux נתמך גם:

velero schedule get

לאחר מכן, ודא שהלוח זמנים נוצר:

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>

הפלט דומה למראה הבא:

velero backup get

לאחר מכן, בדוק את כל הגיבויים לאחר דקה כך או כך:

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>

הפלט דומה למראה הבא:

אימות מצב הגיבוי המתוזמן

velero backup describe kube-system-minute-backup-<timestamp>

ראשית, בדוק את השורה שלב מאחד הגיבויים (אנא החלף את המציין <> בהתאם). זה צריך להצהיר הושלם.

שחזור הגיבוי המתוזמן

כדי לשחזר גיבויים מלפני דקה, נא לעקוב אחרי אותם שלבים שלמדת בשלבים הקודמים של המדריך הזה. זהו דרך טובה להתאמן ולבדוק את הניסיון שצברת עד כה.

בשלב הבא, תלמד כיצד למחוק באופן ידני או אוטומטי גיבויים מסוימים שיצרת במשך זמן.

שלב 5 – מחיקת גיבויים

אם אינך זקוק לגיבויים ישנים יותר, תוכל לשחרר משאבים מסוימים גם בקרב ה- Kubernetes וגם בסל ה- Velero DO Spaces.

מחיקת גיבוי באופן ידני

velero backup delete kube-system-minute-backup-<timestamp>

ראשית, בחר גיבוי של דקה לדוגמה, והפעל את הפקודה הבאה (נא להחליף את המקום של מיקום הפקודה <> בהתאם):

עכשיו, בדוק שהוא נעלם מתוך הפלט של פקודת velero backup get. עליו להימחק גם מתוך הדלי של DO Spaces.

בשלב הבא, תמחק מספר גיבויים בו זמנית על ידי שימוש ב־selector. התת־פקודה velero backup delete מספקת דגל בשם --selector. הוא מאפשר לך למחוק מספר גיבויים בו זמנית בהתבסס על תוויות Kubernetes. החוקים זהים ל־תוויות בורר בחירה של Kubernetes.

velero backup get

ראשית, רשום את הגיבויים הזמינים:

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>

הפלט נראה דומה ל:

velero describe backup backend-minute-backup-20210826094116

לבסוף, אמור שתרצה למחוק את כל הנכסים של backend-minute-backup-*. בחר גיבוי מהרשימה ובדוק את התוויות:

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>
...

הפלט נראה דומה ל (שים לב לערך התווית velero.io/schedule-name):

velero backup delete --selector velero.io/schedule-name=backend-minute-backup

לבסוף, תוכל למחוק את כל הגיבויים שתואמים את הערך backend-minute-backup של תווית velero.io/schedule-name:

לבסוף, בדוק כי כל הנכסים של backend-minute-backup-* התבלו מתוך פלט הפקודה velero backup get וגם מתוך הדלי של DO Spaces.

מחיקת גיבוי אוטומטית דרך TTL

  • כאשר אתה יוצר גיבוי, ניתן לציין זמן חי (TTL – Time To Live) על ידי שימוש בדגל --ttl. אם Velero רואה כי משאב הגיבוי הקיים פג תוקף, הוא מסיר:
  • משאב הגיבוי Backup
  • קובץ הגיבוי מאוחסן באובייקט האחסון בענן storage
  • כל הצילומי פלטת האחסון הקבועים PersistentVolume

כל השחזורים המקושרים

דגל ה-TTL מאפשר למשתמש לציין את תקופת השמירה של הגיבוי עם הערך שצוין בשעות, דקות ושניות בפורמט --ttl 24h0m0s. אם לא צוין, ערך TTL ברירת מחדל של 30 ימים ייושם. 

velero backup create ambassador-backup-3min-ttl --ttl 0h3m0s --include-namespaces ambassador

למעשה, יש ליצור את הגיבוי של ambassador, בשימוש בערך TTL של 3 דקות: 

velero backup describe ambassador-backup-3min-ttl

לאחר מכן, יש לבדוק את הגיבוי של ambassador: 

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.

הפלט נראה דומה לכך (שים לב לקטע ה-Namespaces -> Included – צריך להציג ambassador, והשדה TTL מוגדר ל-3ms0):

לבסוף, לאחר שלוש דקות או כך, הגיבוי והמשאבים המקושרים צריכים להימחק באופן אוטומטי. ניתן לוודא כי אובייקט הגיבוי נמחק באמצעות: velero backup describe ambassador-backup-3min-ttl. צריך לקבל הודעת שגיאה המציינת כי הגיבוי אינו קיים יותר. התיקייה המתאימה ambassador-backup-3min-ttl מדלגת תוצאת סלע Velero תימחק כן. 

velero backup delete --help

להמשך, ניתן לחקור את כל אפשרויות המחיקה של גיבויי Velero, באמצעות:

סיכום

במדריך זה, למדת כיצד לבצע גיבויים חד-פעמיים, וגם גיבויים מתוזמנים, ולשחזר הכל. יש חשיבות רבה לקיום גיבויים מתוזמנים מראש מאחר וזה מאפשר לך לשחזר לדמות קודמת בזמן אם משהו הולך לאיבוד בדרך. עברת גם דרך של מקרה שחזור אסון.

שחזור נפחות מדמויות קוביית Kubernetes

Source:
https://www.digitalocean.com/community/developer-center/how-to-backup-and-restore-data-of-a-doks-cluster-using-velero