Velero لـ Kubernetes: خطة تعافي بدل الدعاء

لو مهندس جديد كتب kubectl delete namespace production بدل staging الساعة 3 الفجر، ومعندكش backup خارج الـ cluster، هتفضل 9 ساعات بتعيد بناء كل حاجة يدوي. Velero بيرجّع الموقف في 12 دقيقة من S3. المقال ده بيوريك الإعداد كامل بأرقام إنتاج حقيقية.

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

فريق بيشغّل EKS بـ 40 microservice وموقع بخدم 120 ألف user يوميًا. فيه سيناريوهات 3 بتكسر الإنتاج فورًا: مسح namespace بالخطأ، فساد volume بسبب node crash، وضياع region كامل في AWS outage. كل سيناريو منهم الحل بتاعه مختلف لو ما عندكش خطة موحّدة.

كتير من الفرق بتعتمد على etcd snapshots وبس. ده بيحفظ الـ control plane state فقط، من غير persistent volumes. يعني PostgreSQL بتاعك وصوره MinIO وملفات uploads كلها بتضيع. وزيادة على كدا، لو الـ snapshot متخزّن جوه نفس الـ region اللي وقع، فأنت بتحتفظ بالدواء جوه المستشفى اللي بتحترق.

Velero بلغة بسيطة: أمين مكتبة بينسخ كل كتاب

تخيّل مكتبة فيها 5000 كتاب. كل يوم فيه ناس بتضيف كتب جديدة وبتعدّل في الفهرس وبتنقل كتب من رف لرف. أمين المكتبة كل ليلة بيصوّر المكتبة كلها: الكتب نفسها، الفهرس، حتى ترتيب الرفوف، وبيبعت الصور دي لفرع بعيد. لو حصلت نار وضاع نصف الكتب، الأمين بيرجع آخر صورة ويعيد بناء المكتبة في ساعة بدل أسبوع كامل.

Velero بيشتغل بنفس المنطق بالظبط. هو عبارة عن controller بيتركّب جوا cluster Kubernetes، ووظيفته اتنين: ياخد snapshot للـ Kubernetes API objects (Deployments, Services, ConfigMaps, Secrets, CRDs) ويحوّلها لـ tarball على object storage خارجي زي AWS S3 أو MinIO أو GCS. وبالتوازي، بيطلب من CSI driver أو من Kopia data mover إنه ياخد snapshot للـ Persistent Volumes ويرفعها على نفس الـ bucket مع الـ metadata.

أحدث إصدار وقت كتابة المقال هو Velero 1.18.0 (أبريل 2026)، ومعاه plugin AWS v1.13.2، وبقى فيه default دعم Kopia للـ volumes الكبيرة بدل PodVolumeBackup القديم الـ restic-based.

الإعداد العملي في 4 خطوات

1. جهّز S3 bucket + IAM user: bucket مخصص للـ backup بس، وuser بصلاحيات GetObject/PutObject/DeleteObject/ListBucket فقط على الـ bucket ده. صلاحية أوسع من كدا = سر طويل العمر بخطر.
2. ثبّت Velero CLI + server: CLI محلي على جهازك، والـ server بيشتغل كـ deployment في namespace اسمه velero.
3. فعّل Kopia للـ PV: Kopia بيعمل block-level deduplication + compression، يعني backup كل يوم لـ 500GB ممكن يتخزّن في 50GB فقط بعد deduplication.
4. schedule يومي + اختبار restore أسبوعي: الـ schedule لوحده مش كفاية. backup ما اتجرّبش الاستعادة منه = backup وهمي.

# 1) إنشاء bucket + IAM (مرة واحدة)
aws s3 mb s3://prod-velero-backup-2026 --region us-east-1

# 2) تثبيت Velero 1.18 مع Kopia كـ uploader افتراضي
velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.13.2 \
  --bucket prod-velero-backup-2026 \
  --backup-location-config region=us-east-1 \
  --snapshot-location-config region=us-east-1 \
  --secret-file ./credentials-velero \
  --use-node-agent \
  --uploader-type kopia \
  --default-volumes-to-fs-backup

# 3) schedule يومي 3 صباحاً مع retention 30 يوم
velero schedule create daily-prod \
  --schedule "0 3 * * *" \
  --include-namespaces production \
  --ttl 720h0m0s

# 4) backup فوري للاختبار الأول
velero backup create prod-initial \
  --include-namespaces production --wait

# 5) استعادة namespace اتمسح بالخطأ
velero restore create rescue-$(date +%s) \
  --from-backup prod-initial

trade-offs بصراحة: بتكسب إيه وبتدفع إيه

• تكلفة التخزين: cluster بـ 500GB PV + retention 30 يوم على S3 Standard ≈ 15 دولار/شهر. على S3 Standard-IA بينزل لـ 6 دولار، بس الاستعادة بتاخد 3-5x أطول لأن الـ retrieval time أكبر.
• RTO (زمن الاستعادة): cluster بـ 40 microservice في region واحد برجع في حدود 12 دقيقة. لو عندك 200 microservice، خد بالك: الـ restore بيتم sequentially داخل كل API priority level.
• RPO = مدة الـ schedule: backup يومي معناه ممكن تخسر آخر 24 ساعة تغييرات. لو ده كتير، خلّي الـ schedule كل 6 ساعات، بس كل backup بياخد CPU من الـ node-agent لحوالي 2-4 دقائق.
• consistency للـ databases: snapshot PV للـ PostgreSQL أو MySQL وهي شغّالة ممكن يطلع corrupt. لازم pre-backup hook يعمل pg_dump أو fsfreeze قبل ما الـ snapshot يتاخد.

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

Velero أداة ممتازة لكنها مش حل لكل سيناريو:

• قواعد بيانات إنتاج حرجة لوحدها: PostgreSQL أو MySQL ذات RPO بالثواني محتاجة streaming replication (Patroni, pg_basebackup مستمر، أو managed RDS). Velero بيكمّل مش بيبدل.
• multi-region active-active مع RTO أقل من دقيقة: Velero بيعمل restore مش failover لحظي. هنا بتحتاج Kasten K10 أو Portworx بـ sync replication بين الـ clusters.
• cluster أقل من 5 خدمات: overhead الـ installation + maintenance أكبر من الفائدة. GitOps (ArgoCD/Flux) + etcd snapshot أسبوعي بيكفي.

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

افتح terminal دلوقتي وشغّل velero install على cluster staging، بعدين اعمل kubectl delete ns test-ns على namespace تجريبي، وشوف velero restore بيرجّعه في كام ثانية. لو طلع عندك PartiallyFailed، 90% من الحالات المشكلة في صلاحيات IAM مش في Velero، راجع logs الـ node-agent pods قبل ما تفتح GitHub issue.

المصادر

• الموقع الرسمي: velero.io
• Velero على GitHub (vmware-tanzu): github.com/vmware-tanzu/velero
• دليل OneUptime لـ Velero 2026: oneuptime.com
• مقارنة Velero vs Kasten K10 (2026): devopsboys.com
• توثيق Canonical لاستخدام Velero مع MicroK8s: canonical.com