مقال مرتبط · هذا الدليل جزء من سلسلة Kubernetes منزلي على Proxmox VE. الدليل السابق: kube-prometheus-stack. الخطوة الأخيرة من المسار.
بمجرّد أن يصير العنقود إنتاجيًّا، السؤال الأخير المُلِحّ هو النسخ الاحتياطي. دون خطّة استرجاع مُختبَرة، حذف عرضي، ترقية فاشلة، أو حادث تخزين Ceph قد يُدمّر أسابيع من الإعداد والبيانات. Velero هو الأداة المرجعية لنسخ عنقود Kubernetes احتياطيًّا: يلتقط كائنات API server (Deployments، Services، ConfigMaps، Secrets، CRDs) والـ volumes المستمرّة المُرافقة، إلى تخزين كائنات متوافق مع S3. النسخة 1.18 الصادرة في ربيع 2026 تُضيف دعم cache volumes لـ data movers وتصفية glob على namespaces. يُثَبِّت هذا الدليل Velero 1.18، يُهَيِّئ bucket S3 من Rook-Ceph، يُشَغِّل أوّل نسخ مُجَدوَلة، ويختبر استعادة كاملة لـ namespace.
الخطوة 1 — تحضير bucket S3 والاعتماديّات
Velero يحتاج bucket لتخزين الكائنات المُسَلسَلة وsnapshots الـ volumes. bucket ObjectStore لـ Rook-Ceph (المُنشَأ في دليل Rook) يفي بالغرض. ننشئ user مخصَّصًا لـ Velero لعزل الصلاحيات.
kubectl -n rook-ceph exec deploy/rook-ceph-tools -- \
radosgw-admin user create --uid=velero --display-name="Velero Backup User"
# دوِّن access_key وsecret_key من الخرج
# أنشئ الـ bucket عبر CLI s3cmd أو عبر CRD ObjectBucketClaim
cat > velero-bucket-claim.yaml <الـ bucket يُنشَأ في Ceph وتُديره Rook. مقاربة ObjectBucketClaim أنظف من الإنشاء اليدوي لأنّها تُنسِّق الإعلان وتربطه بدورة حياة namespace velero.
الخطوة 2 — تثبيت Velero عبر CLI الرسمي
Velero يُثَبَّت عبر CLI مخصَّص بدل Helm الصرف لأنّ الـ CLI يُهَيِّئ BackupStorageLocation وVolumeSnapshotLocation بشكل أصحّ.
# تثبيت velero CLI 1.18
VELERO_VERSION=v1.18.0
curl -L https://github.com/vmware-tanzu/velero/releases/download/${VELERO_VERSION}/velero-${VELERO_VERSION}-linux-amd64.tar.gz -o velero.tar.gz
tar -xvzf velero.tar.gz
sudo install velero-${VELERO_VERSION}-linux-amd64/velero /usr/local/bin/
# جَهِّز ملفّ اعتماديّات S3
cat > credentials-velero <التثبيت يُنشئ namespace velero، ينشر pod Velero الرئيسي وDaemonSet node-agent. وجود علم --default-volumes-to-fs-backup وKopia كـ uploader يُهَيِّئ file system backup، الذي ينسخ الملفّات من داخل كلّ pod إلى الـ bucket. هذه الطريقة الشاملة التي تعمل مع أيّ StorageClass، بما فيه Rook-Ceph RBD وCephFS.
الخطوة 3 — التحقّق من أنّ Velero يعمل
velero version
# يجب عرض Client v1.18.0 وServer v1.18.0
velero backup-location get
# default يجب أن يكون في حالة Available
velero get plugin
# يجب إدراج velero-plugin-for-aws وdata moverحالة Available على BackupStorageLocation تُؤكِّد أنّ Velero يستطيع القراءة والكتابة في الـ bucket. إن كانت Unavailable، افحص أولًا حلّ DNS الداخلي، وصولية Service Ceph RGW من namespace velero، وصحّة اعتماديّات S3.
الخطوة 4 — تشغيل أوّل نسخ احتياطي يدوي
velero backup create test-demo-1 \
--include-namespaces demo \
--wait
velero backup describe test-demo-1 --details
# Status يجب أن يتقدّم: InProgress ← Completed
# Items backed up يُبيّن عدد الكائنات الملتقطةرؤية النسخة تمرّ إلى Completed مع عدد items متّسق (Pods، PersistentVolumes، Services، Secrets…) وحجم بيانات يعكس الحجم الفعلي للـ PVC يُؤكِّد أنّ Velero يلتقط كلّ شيء. للتحقّق من نسخ بيانات الـ volume فعليًّا، افحص الـ bucket بعميل S3.
الخطوة 5 — جدولة النسخ الليلية
velero schedule create nightly-full \
--schedule="0 2 * * *" \
--ttl 720h \
--include-namespaces "*" \
--exclude-namespaces "kube-system,velero,monitoring"
velero schedule create nightly-monitoring \
--schedule="0 3 * * *" \
--ttl 168h \
--include-namespaces "monitoring"
velero schedule get
# يجب إدراج الجدوَلَتَين مع next backup timeفصل namespace monitoring (الذي قد يبلغ عدّة جيغا بسبب Prometheus) مع احتفاظ أقصر يتفادى أن تُشبِع snapshots stack الرصد الـ bucket. TTL بـ 720 ساعة (30 يومًا) على النسخ العامّة تسوية معقولة لـ homelab.
الخطوة 6 — اختبار استعادة كاملة
نسخة غير مُختبَرة ليست نسخة. الاختبار حذف namespace قائم واستعادته من Velero، ثم التحقّق من أنّ الـ pods تُقلِع والبيانات موجودة.
# احذف namespace demo
kubectl delete namespace demo
sleep 30
kubectl get namespace demo
# يجب إرجاع NotFound
# استعد من النسخة
velero restore create demo-restore-1 \
--from-backup test-demo-1 \
--wait
velero restore describe demo-restore-1
# Status يجب أن يكون Completed
# تحقّق من عودة الـ pods
kubectl get pods -n demo
# تحقّق من بيانات الـ volume
kubectl exec test-pod -n demo -- cat /data/hello.txt
# يجب عرض: persistent-dataملفّ hello.txt الذي يُعاود الظهور بمحتواه يُثبت أنّ file system backup نسخ البيانات فعلًا وأنّ الاستعادة أعادتها إلى volume Rook-Ceph جديد. هو المعيار الوحيد الذي يُصادِق على السلسلة من البداية إلى النهاية.
الخطوة 7 — نسخ احتياطي إلى تخزين خارج العنقود
النسخ داخل نفس العنقود الذي نَنسخه له قيمة جزئية فقط: إن احترق كلّ العنقود (حريق، سرقة، عطل قرص كارثي)، النسخ تحترق معه. الممارسة الجدّية تكرار الـ bucket إلى تخزين خارجي: VPS Hetzner مع MinIO، حساب Backblaze B2، Wasabi، أو قرص خارجي عبر rclone مُزامَن كلّ ليلة.
# مثال نسخ عبر rclone (يُنفَّذ من VPS خارجي)
rclone sync \
s3-homelab:velero-xxxxxxxx \
s3-backblaze:backup-homelab/velero \
--transfers 4 \
--checkers 8 \
--log-file /var/log/rclone-velero.logهذا الأمر ينسخ كامل bucket النسخ إلى حساب B2 بعيد. القاعدة الشاملة 3-2-1 (3 نسخ، 2 وسائط، 1 خارج الموقع) تصير تطبيقية: البيانات تعيش على أقراص Ceph، في bucket Velero، وخارج الموقع على B2. اختبر دوريًّا الاستعادة من الـ bucket البعيد بتركيب BackupStorageLocation الثاني مؤقّتًا.
الخطوة 8 — مراقبة الصحّة عبر Prometheus وGrafana
Velero يكشف مقاييس Prometheus حين يُمرَّر العلم --features=EnableCSI عند التثبيت. ServiceMonitor المرافق يجب إنشاؤه ليحصده kube-prometheus-stack.
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: velero
namespace: velero
labels:
release: kube-prometheus-stack
spec:
selector:
matchLabels:
app.kubernetes.io/name: velero
endpoints:
- port: monitoring
interval: 30sبعد تطبيق ServiceMonitor، مقاييس velero_backup_success_total، velero_backup_failure_total، velero_backup_duration_seconds تصير قابلة للاستعلام. لوحة Grafana Velero (تُستورَد من grafana.com بـ ID 11055) تعرض كلّ ما يجب معرفته: timeline النسخ، نسبة النجاح، المدّة لكلّ namespace، الحجم التراكمي للـ bucket.
الخطوة 9 — تحضير إجراء Disaster Recovery
للنسخ معنى فقط إن عرفنا استعادة عنقود كامل، لا مجرّد namespace. إجراء DR يتمثّل، على عنقود Kubernetes جديد عاري: تثبيت Velero مُشيرًا إلى نفس الـ bucket، إدراج النسخ المتاحة، وتشغيل استعادة شاملة. توثيق هذا الإجراء بأهمّية النسخ الاحتياطي ذاتها.
# على العنقود الهدف (عاري)، بعد تثبيت Velero مُشيرًا إلى نفس الـ bucket
velero backup get
# يُدرج كلّ النسخ المتاحة في الـ bucket
velero restore create dr-2026-05-06 \
--from-backup nightly-full-20260505020000 \
--include-namespaces "demo,gitea,vaultwarden,nextcloud" \
--wait
# تحقّق من الصحّة بعد الاستعادة
kubectl get pods -A
kubectl get pvc -Aدقائق بعد بدء الاستعادة، الـ pods تعود في Running والـ volumes تُعاد التركيب. هذا تمامًا السيناريو الذي نأمل ألّا نضطرّ لتنفيذه، لكن يجب اختباره مرّة واحدة على الأقلّ للاعتماد عليه.
أخطاء شائعة وحلولها
| العَرَض | السبب | الحلّ |
|---|---|---|
| BackupStorageLocation يمرّ إلى Unavailable | endpoint S3 غير قابل للوصول أو credentials سيّئة | افحص kubectl logs -n velero deploy/velero واختبر اتّصال s3 من pod |
| نسخة Completed لكنّ الـ volume فارغ عند الاستعادة | تعليق backup.velero.io/backup-volumes مفقود |
تحقّق من تفعيل --default-volumes-to-fs-backup |
| الاستعادة تفشل بـ "namespace already exists" | namespace الهدف قائم بتعارضات | احذف namespace الهدف قبل أو استعمل --namespace-mappings |
| Schedule لا يُشَغَّل | صيغة cron سيّئة أو عنقود بلا تزامن NTP | افحص velero schedule describe وساعة العقدة |
| الـ bucket ينمو بلا حدود | TTL غير مُطَبَّق على النسخ القديمة | افحص velero backup get --selector velero.io/schedule-name=... واتّساق TTL |
لاستكمال المسار
البيئة الآن كاملة: hypervisor، VMs، Kubernetes HA، CNI eBPF، تخزين مُكَرَّر، GitOps، رصد، نسخ احتياطي. أيّ حِمل يُنشَر من الآن يستفيد من السلسلة الكاملة. هي نقطة وصول المسار الأوّلي ونقطة انطلاق لكلّ ما نريد استضافته بعده: Gitea، Vaultwarden، Nextcloud، خدمات داخلية، APIs شخصية. للنظرة العامّة ومسارات التطوّر (أمن مُشَدَّد، عنقود متعدّد العقد، تخزين بحجم أكبر)، عُد إلى الدليل الرئيسي.
مصادر وتوثيق رسمي
- توثيق Velero:
velero.io/docs - ملاحظات إصدار Velero 1.18:
github.com/vmware-tanzu/velero/releases - file system backup مع Kopia:
velero.io/file-system-backup - Plugin AWS Velero:
github.com/vmware-tanzu/velero-plugin-for-aws - أنماط Disaster Recovery:
velero.io/disaster-case - توثيق rclone (نسخ خارجي):
rclone.org/docs
الخطوة 10 — فهم الفرق بين file system backup وCSI snapshots
Velero يعرض آليّتين لنسخ الـ volumes: file system backup مع Kopia (المُستعمَل هنا) الذي ينسخ الملفّات من داخل الـ pod، وCSI snapshots التي تستند إلى وظيفة snapshot لمُشَغِّل CSI الأساسي. الاثنان لهما تسويات يجب فهمها لاستعمالهما بحكمة.
file system backup يعمل مع أيّ volume، باستقلال عن المُشَغِّل. محمول: يمكن استعادة نسخة Rook-Ceph على عنقود يستعمل local-path-provisioner. ينسخ الملفّات فعلًا، فيستهلك عرض النطاق والوقت. لـ volume بـ 10 جيغا، احسب دقيقة إلى عشر دقائق حسب زمن الـ bucket.
CSI snapshots شبه فورية (snapshot Ceph يتمّ في O(1) على مستوى الكتلة) لكنّها مرتبطة بمُشَغِّل المصدر. استعادة snapshot Rook-Ceph على عنقود آخر تتطلّب أن يكون الـ bucket متاحًا وأن يكون Rook حاضرًا. القابلية للنقل أضيق لكنّ نافذة النسخ صفرية، وهو ثمين لقواعد بيانات ضخمة جدًّا.
لـ homelab، file system backup مع Kopia هو الافتراضي الجيّد لأنّه بسيط، محمول، موثوق. لـ volumes Ceph كبيرة جدًّا (100 جيغا+)، تحويل هذا الحِمل المحدّد إلى CSI snapshots يُسرِّع النسخ دون تغيير باقي الإعداد. Velero يدعم الوضعَين معًا، التعليق backup.velero.io/backup-volumes-excludes يُتيح استثناء volumes مُعالَجة بـ CSI من file system backup.
الخطوة 11 — تنسيق Velero في Argo CD
كما كلّ المكوّنات المنشورة في هذا المسار، Velero ذاته يجب أن يعيش في Git لإتاحة إعادة بناء قابلة للتكرار. الممارسة التزام المنفست المُولَّد بـ velero install --dry-run -o yaml في مستودع GitOps، ثم دفعه عبر Application Argo CD.
velero install \
--dry-run -o yaml \
--provider aws \
--plugins velero/velero-plugin-for-aws:v1.14.0 \
--bucket velero-xxxxxxxx \
--secret-file ./credentials-velero \
--use-volume-snapshots=false \
--backup-location-config region=default,s3ForcePathStyle=true,s3Url=http://rgw.rook-ceph.svc \
--uploader-type kopia \
--features=EnableCSI \
--default-volumes-to-fs-backup \
> clusters/homelab/infra/velero/install.yaml
git add clusters/homelab/infra/velero
git commit -m "Manage Velero via Argo CD"
git pushبمجرّد مزامنة هذه Application، ترقية Velero تصير إعادة توليد المنفست بنسخة CLI الجديدة والتزام. Argo CD يُطبّق الترقية. الـ Secret cloud-credentials يبقى خارج Git ويُنشَأ منفصلًا (أو عبر sealed-secrets).
الخطوة 12 — إرساء روتين تحقّق شهري
الطقس الذي يُؤتي ثماره تكريس ساعة شهريًّا للتحقّق من أنّ سلسلة النسخ تعمل فعلًا. الروتين النموذجي بخمس خطوات: عرض قائمة النسخ الأخيرة (velero backup get)، التأكّد ألّا واحدة في Failed، قياس الحجم التراكمي للـ bucket، تشغيل استعادة اختبار على namespace قابل للرمي، وتأكيد إقلاع الـ pods المُستَعادة. خمس عشرة دقيقة فعلية شهريًّا لاطمئنان نسخ تعمل.
هذا الانضباط البسيط يُميِّز البيئات التي تنجو فعلًا من الحوادث عمّا تظنّ فقط أنّها تنجو. الثلاثاء الأوّل من كلّ شهر تاريخ طبيعي لهذا الروتين، متكرّر بما يكفي لكشف الانحرافات، ومُتباعد بما يكفي ألّا يصير عبئًا.