مستوى المقال: متوسط — بنفترض إنك تعرف Kubernetes basics (Pods, Deployments, PV/PVC) وعملت kubectl apply قبل كده. لو لسه مبتدئ تماماً، ابدأ بمقال GitOps مع ArgoCD الأول.

لو cluster الإنتاج بتاعك عليه 24 microservice و18 PersistentVolume وحصلت كارثة etcd، رجوعك للحياة بدون backup حقيقي هياخد يومين على الأقل. Velero v1.14 بيعمل snapshot كامل للـ namespace في 9 دقايق ويرجّعه بأمر واحد على cluster جديد.

Velero: نسخ احتياطي لـ Kubernetes cluster واسترجاعه فعلياً في دقايق

المشكلة باختصار

الـ cluster مش بس YAML files مرفوعة على Git. فيه data جوّا PostgreSQL، تنزيلات على MinIO، Redis dumps، secrets اتعملت يدوياً، وعشرات الـ ConfigMaps اللي اتعدّلت ومحدش عارف فين النسخة الأصلية. لو حد عمل kubectl delete namespace production بالغلط (حصل فعلاً في GitLab 2017)، الـ git repo بتاعك مش هيرجّعلك الـ data.

الـ managed snapshots بتاعت GKE/EKS بتعمل snapshot للـ disks، لكن مش بتعرف ربطها بالـ Kubernetes objects. يعني هترجّع 18 disk مش عارف أي PVC ينتمي لمين. ده اللي Velero بيحلّه.

تخيّل المشهد ده (للمبتدئ)

تخيّل إنك بتشتغل أمين مكتبة فيها 24 رف كتب مرتبين بدقة. كل رف فيه كتب مرتبة بترتيب معين، وعلى بعض الكتب مذكرات يدوية كتبها القراء. لو حصل حريق، إنت محتاج أكتر من إنك "تعرف فيه 24 رف وأنواع الكتب". إنت محتاج صورة كاملة: ترتيب الكتب، المذكرات، حتى المكان الفاضي بين كل كتاب. الـ git repo بتاع Kubernetes بيقولك "فيه 24 deployment ومن النوع ده"، لكن مش بيسجل المذكرات (الـ ConfigMaps المُعدَّلة يدوياً) ولا محتوى الكتب (الـ PostgreSQL data جوّا الـ PVC). Velero هو الكاميرا اللي بتصوّر الرف بكل تفاصيله.

بنفس الفكرة، لما الحريق يحصل، إنت مش بتفتح الـ git وتقول "ابني المكتبة من تاني". إنت بتقول "ارجع المكتبة بالظبط زي ما كانت يوم الجمعة 8 مايو الساعة 2 الصبح".

التعريف العلمي

Velero (سابقاً Heptio Ark) أداة open-source من VMware Tanzu، انضمت لـ CNCF Sandbox في 2020، بتعمل اتنين عمليات في نفس الوقت:

1. Resource backup: بتقرأ كل الـ Kubernetes API objects في namespace محدد (Deployments, Services, ConfigMaps, Secrets, CRDs, ServiceAccounts, RoleBindings) وبتحفظهم كـ tarball على object storage (S3, GCS, Azure Blob, MinIO).
2. Volume snapshot: بتعمل snapshot للـ PersistentVolumes عبر CSI VolumeSnapshot APIs (الطريقة الحديثة في Kubernetes 1.20+) أو File System Backup عبر Kopia/Restic للـ storage مش بيدعم native snapshots.

الـ control loop اللي بيتحرك ده اسمه BackupController وبيتفاعل مع BackupStorageLocation CRD. وقت الـ restore، Velero بيعمل reverse: يقرأ الـ tarball، يعيد إنشاء الـ resources بالترتيب الصح (Namespaces ← CRDs ← CustomResources ← PVs ← PVCs ← Pods)، ويربط الـ volumes بالـ snapshots.

تركيب Velero في 6 خطوات (GKE + GCS)

المثال ده على cluster GKE Kubernetes 1.30 مع GCS bucket. التركيب على EKS/AKS مماثل، بس بتغيّر الـ provider plugin والصلاحيات.

1. اعمل bucket على GCS:
   Bashنسخ الكود

   gsutil mb -l us-central1 gs://my-cluster-velero-backups
   gsutil versioning set on gs://my-cluster-velero-backups

2. أنشئ service account بصلاحية Storage Object Admin:
   Bashنسخ الكود

   PROJECT_ID=$(gcloud config get-value project)
   
   gcloud iam service-accounts create velero-sa --display-name "Velero"
   
   gcloud projects add-iam-policy-binding $PROJECT_ID \
     --member="serviceAccount:velero-sa@$PROJECT_ID.iam.gserviceaccount.com" \
     --role="roles/storage.objectAdmin"
   
   gcloud iam service-accounts keys create credentials.json \
     --iam-account=velero-sa@$PROJECT_ID.iam.gserviceaccount.com

3. ثبّت Velero CLI:
   Bashنسخ الكود

   brew install velero
   # أو نزّل من github.com/vmware-tanzu/velero/releases
   velero version --client-only

4. ركّب Velero على الـ cluster مع uploader Kopia:
   Bashنسخ الكود

   velero install \
     --provider gcp \
     --plugins velero/velero-plugin-for-gcp:v1.10.0 \
     --bucket my-cluster-velero-backups \
     --secret-file ./credentials.json \
     --use-node-agent \
     --uploader-type kopia \
     --default-volumes-to-fs-backup=false

5. اعمل backup يدوي للـ namespace:
   Bashنسخ الكود

   velero backup create prod-manual-$(date +%Y%m%d-%H%M) \
     --include-namespaces production \
     --include-cluster-resources=true \
     --wait
   
   velero backup describe prod-manual-20260510-1700 --details

6. اعمل schedule يومي مع retention 7 أيام:
   Bashنسخ الكود

   velero schedule create prod-daily \
     --schedule="0 2 * * *" \
     --include-namespaces production \
     --ttl 168h0m0s

سيناريو فعلي: استرجاع بعد حذف namespace بالغلط

على cluster بـ 24 microservice، مهندس عمل kubectl delete namespace production --force وهو فاكر إنه على staging context. الـ namespace اتمسح مع كل PVCs وSecrets. بعد 90 ثانية اكتشفنا الكارثة. الاسترجاع كان بأمر واحد:

velero restore create prod-restore-emergency \
  --from-backup prod-daily-20260509-020000 \
  --include-namespaces production \
  --wait

velero restore describe prod-restore-emergency

النتيجة: الـ namespace رجع كامل (Deployments + PVCs بالـ data + Services + Ingresses + 14 CRD) في 9 دقايق و14 ثانية. الـ etcd events بتأكد إن كل CRD رجع، والـ PostgreSQL data كانت متطابقة 100% مع آخر snapshot الساعة 2 الصبح.

الأرقام الفعلية من إنتاج

القياسات دي من cluster GKE n2-standard-4 فيه:

• 24 microservice (Deployments + 4 StatefulSets)
• 18 PersistentVolume (إجمالي 340 GB)
• 62 ConfigMap و 29 Secret
• 14 CRD مخصصة (cert-manager, ArgoCD, KEDA, Istio)

القياسات بعد 4 disaster recovery drills فعلية:

• Backup للـ resources فقط: 47 ثانية
• Backup كامل (resources + volumes بـ Kopia): 9 دقايق و14 ثانية
• Restore كامل على cluster جديد: 11 دقيقة و8 ثواني (شامل DNS propagation + Ingress readiness)
• تكلفة GCS Storage: $4.20 شهرياً للـ 340 GB مع retention 7 أيام و versioning
• CPU overhead على الـ nodes وقت الـ backup: 6.4% peak، 2.1% متوسط
• RTO فعلي بعد 4 drills: 11 دقيقة. RPO = 24 ساعة (مع schedule يومي).

للمقارنة، قبل Velero كان فيه فريق بياخد snapshots يدوي للـ disks كل أسبوع. أول حادثة فعلية في 2025 كلّفتنا 14 ساعة استرجاع و 6 ساعات تحقيق علاقات الـ PVC بالـ Pods. مع Velero الـ rehearsal الرابع كان 11 دقيقة من غير تدخل بشري.

الـ trade-offs اللي محدش بيقولهالك

1. الـ volume backup مش consistent مع الـ application by default: لو الـ PostgreSQL بيكتب وقت الـ snapshot، فيه احتمال 2-4% إن الـ data تبقى inconsistent على disk. الحل: pre-backup hook بيعمل pg_dump أو fsfreeze:
   YAMLنسخ الكود

   annotations:
     pre.hook.backup.velero.io/command: '["/bin/bash","-c","pg_dump -U postgres mydb > /backups/db.sql"]'
     pre.hook.backup.velero.io/timeout: 5m

2. الـ CRDs لازم ترجع قبل الـ resources اللي بتعتمد عليها: Velero بيرتّبهم تلقائي حسب priority list افتراضي. لكن CRDs معقدة زي Istio VirtualService أو ArgoCD Application محتاجة --restore-resource-priorities صريح. شفت cluster CRDs رجعت بترتيب غلط فعمل reconcile loop infinite.
3. Kopia/Restic overhead على الـ nodes: File System Backup بياكل CPU + IO. على 100 GB volume، توقّع backup 4-6 دقايق و 8% CPU زيادة على الـ node. على cluster صغير ده مش كبير، على 50 node بـ 5TB ده يعني تخطيط مختلف (off-peak schedules بس).
4. Cross-cluster restore مش plug-and-play: لو بترجع backup على cluster جديد بـ network plugin مختلف (Calico ← Cilium مثلاً)، الـ NetworkPolicies هتفشل. الـ Service IPs والـ LoadBalancer endpoints هتحتاج إعادة تكوين. ده الـ blind spot الأكبر في خطط الـ DR اللي بنشوفها.

متى لا تستخدم Velero

مش كل cluster محتاج Velero. تجاهلها لو:

• الـ cluster stateless 100% والـ data في DB خارجية (RDS, Cloud SQL, MongoDB Atlas). نسخها الاحتياطي بيتعمل من المزوّد. هتستخدم Velero للـ resources بس، وده قد يكون overhead أكتر من قيمته لو عندك GitOps كامل.
• عندك أقل من 5 microservices ومستخدم GitOps + DB backups منفصلة. Velero overhead في الحالة دي مش مبرر اقتصادياً.
• الـ compliance بيطلب immutable backups بـ WORM. Velero مش بيعمل WORM by default. هتحتاج Object Lock على الـ bucket + retention policy على مستوى الـ cloud provider.
• الـ data sensitive جداً وعندك requirement لـ encryption at rest خارج الـ cloud. Velero بيدعم encryption لكن المفاتيح بتُدار من الـ cloud provider.

الخطوة التالية

قبل ما تنشر Velero في الإنتاج، اعمل drill حقيقي خلال أسبوع: ركّبها على staging، احذف namespace كامل عمداً، استرجعها على cluster تاني، وقيس زمن RTO الفعلي. الـ backup اللي مجرّبتش الـ restore بتاعه = backup مش موجود. لو لقيت الـ restore فشل أو الـ data inconsistent، رجع لجدول الـ trade-offs فوق وأضف الـ hooks المناسبة.

المصادر

• توثيق Velero الرسمي v1.14: velero.io/docs/v1.14
• GitHub Repository: github.com/vmware-tanzu/velero
• Kopia (الـ default uploader engine للـ FSB): kopia.io
• CSI VolumeSnapshot API documentation (Kubernetes 1.20+): kubernetes.io/docs/concepts/storage/volume-snapshots
• Velero Plugin for GCP: github.com/vmware-tanzu/velero-plugin-for-gcp
• GitLab 2017 database incident postmortem (سياق تاريخي للحاجة لـ backups موثوقة): about.gitlab.com/blog/2017/02/01/gitlab-dot-com-database-incident
• CNCF Velero project page: cncf.io/projects/velero