راه‌اندازی Velero برای پشتیبان‌گیری و بازیابی کلاستر Kubernetes خودمیزبان روی سرور اختصاصی و VPS

کلاستری که خودتان روی سرور اختصاصی یا VPS بالا آورده‌اید، بکاپ خودکاری مثل سرویس‌های مدیریت‌شده ندارد. اگر یک namespace اشتباهی حذف شود یا دیسک یکی از نودها از بین برود، چیزی جز حافظهٔ شما برای بازگرداندن منابع وجود ندارد. Velero همین خالی را پر می‌کند: منابع کلاستر و در صورت نیاز داده‌های Volume را می‌گیرد و در یک Object Storage جدا از کلاستر نگه می‌دارد.

چرا kubectl get -o yaml کافی نیست

خیلی‌ها فکر می‌کنند با یک اسکریپت که kubectl get all -o yaml می‌زند و خروجی را ذخیره می‌کند، بکاپ کلاستر حل شده. این کار فقط بخشی از منابع را می‌گیرد، ترتیب وابستگی بین آن‌ها را نادیده می‌گیرد و هیچ کاری با داده‌های داخل Volume نمی‌کند. وقتی یک پایگاه‌داده روی یک PersistentVolumeClaim اجرا می‌شود، همان داده‌ها معمولا چیزی است که نباید از دست برود؛ نه خود manifest دیپلویمنت.

Velero هر دو بخش را پوشش می‌دهد: منابع کلاستر (Deployment، Service، ConfigMap، Secret و بقیه) و در صورت فعال بودن، داده‌های Volume. بکاپ کامل در یک بسته، با یک دستور گرفته می‌شود و با یک دستور دیگر برمی‌گردد.

Velero از چه قطعاتی تشکیل شده؟

سه بخش اصلی دارد که باید جداگانه بشناسید:

• Velero CLI — همان باینری که روی لپ‌تاپ یا سرور خودتان اجرا می‌کنید تا بکاپ بسازید، وضعیت را چک کنید یا بازیابی کنید.
• Velero Server — یک Deployment داخل namespace به‌نام velero که کار گرفتن و بازگرداندن بکاپ را انجام می‌دهد. CLI فقط با آن از طریق CRD‌های کلاستر صحبت می‌کند.
• BackupStorageLocation — تعریف می‌کند بکاپ‌ها کجا ذخیره شوند؛ همان باکت Object Storage شماست.

یک قطعهٔ چهارم هم برای خودمیزبان‌ها حیاتی است: Node Agent. کلاستری که روی OVH یا هر سرور اختصاصی/VPS دیگری اجرا می‌شود، API اسنپ‌شات ابری ندارد که Velero بتواند مستقیم از دیسک کلود اسنپ‌شات بگیرد. Node Agent یک DaemonSet است که روی هر نود اجرا می‌شود و داده‌های داخل PV را در سطح فایل‌سیستم (با Kopia) می‌خوانَد و در همان بکاپ ذخیره می‌کند. بدون این DaemonSet، Velero فقط manifestها را بکاپ می‌گیرد؛ داده‌های واقعی داخل Volume نادیده گرفته می‌شوند. به همین دلیل PV روی Longhorn یا هر storage خودمیزبان دیگری هم قابل بکاپ است، نه فقط storage ابری.

پیش‌نیازها

قبل از نصب این موارد را آماده کنید:

• دسترسی kubectl با حقوق مدیر به کلاستر (kubeadm یا K3s، فرقی نمی‌کند — اگر هنوز کلاستر ندارید، راه‌اندازی کلاستر Kubernetes روی سرور اختصاصی و VPS با kubeadm را ببینید).
• یک باکت Object Storage سازگار با S3، جدا از سرورهایی که نودهای کلاستر روی آن اجرا می‌شوند.
• Access Key و Secret Key همان باکت.
• آدرس endpoint باکت (برای Object Storageهای غیر AWS همیشه لازم است).

نکتهٔ مهم: باکت باید منطقه‌ای نزدیک به نودهای کلاستر باشد. اگر نودها در آلمان هستند و باکت در منطقهٔ دیگری ساخته شود، هر بار آپلود بکاپ چند ثانیه بیشتر طول می‌کشد و برای کلاسترهایی با PV حجیم این تفاوت محسوس می‌شود.

نصب Velero روی کلاستر

اول فایل اعتبارنامه را بسازید:

aws_access_key_id=<ACCESS_KEY>
aws_secret_access_key=<SECRET_KEY>

و با همین فایل، Velero را نصب کنید:

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.9.0 \
  --bucket my-velero-backups \
  --secret-file ./credentials-velero \
  --use-volume-snapshots=false \
  --use-node-agent \
  --backup-location-config region=default,s3ForcePathStyle=true,s3Url=https://<endpoint-object-storage>

سه نکته در این دستور جای اشتباه دارد:

• --provider aws درست است حتی وقتی Object Storage شما AWS نیست؛ پلاگین velero-plugin-for-aws فقط پروتکل S3 را پیاده‌سازی می‌کند و با هر سرویس سازگار با آن کار می‌کند.
• s3ForcePathStyle=true برای Object Storageهای غیر AWS تقریبا همیشه لازم است؛ بدون آن، Velero آدرس باکت را به شکل subdomain می‌سازد که روی خیلی از سرویس‌های S3-compatible جواب نمی‌دهد.
• --use-volume-snapshots=false یعنی از اسنپ‌شات ابری استفاده نمی‌کنید (چون روی سرور اختصاصی یا VPS وجود ندارد)؛ --use-node-agent همان DaemonSet بخش قبل را فعال می‌کند تا داده‌های Volume از راه فایل‌سیستم خوانده شوند.

بعد از چند ثانیه با این دستور وضعیت را چک کنید:

kubectl get backupstoragelocations -n velero

ستون PHASE باید Available باشد. اگر Unavailable بود، قبل از ادامه باید اول همان را حل کنید؛ بخش رفع مشکلات پایین همین مقاله رایج‌ترین دلیل‌هایش را توضیح می‌دهد.

بکاپ فقط منابع یا همراه داده‌های Volume

این دو حالت رایج‌ترین نقطهٔ اشتباه کسانی است که تازه با Velero کار می‌کنند. بدون تنظیم درست، بکاپ شما ممکن است فقط manifestها را داشته باشد و خودتان متوجه نشوید که داده‌ای در آن نیست.

	فقط منابع (Resource-only)	منابع + داده Volume
چه چیزی بکاپ می‌شود	Deployment، Service، ConfigMap، Secret و بقیهٔ manifestها	همان منابع، به‌علاوهٔ محتوای واقعی PersistentVolumeClaim
نیاز به Node Agent	خیر	بله، باید روشن باشد
حجم بکاپ	کم، چند مگابایت	بسته به حجم دیتابیس یا فایل‌های اپلیکیشن
کاربرد	بازسازی سریع ساختار کلاستر روی یک محیط تازه	بازیابی کامل، از جمله خود داده‌ها
ریسک اگر فکر کنید PV هم بکاپ شده ولی نشده باشد	از دست رفتن کامل داده در بازیابی واقعی	—

برای فعال کردن بکاپ داده روی یک namespace خاص، به هر Pod که PV دارد یک annotation اضافه کنید:

kubectl -n my-app annotate pod/my-db-0 \
  backup.velero.io/backup-volumes=data

data همان نام Volume داخل تعریف Pod است، نه نام PVC.

گرفتن اولین بکاپ

velero backup create first-backup --include-namespaces=my-app

وضعیت را با این دستور دنبال کنید:

velero backup describe first-backup --details

اگر Phase به Completed رسید، بکاپ تمام شده. اگر PartiallyFailed بود، لاگ کامل را بگیرید:

velero backup logs first-backup

بیشتر وقت‌ها دلیل، یک Secret یا CRD است که Velero نتوانسته سریالایز کند؛ معمولا در همان لاگ به اسم دقیق منبع مشکل‌دار اشاره می‌شود.

زمان‌بندی بکاپ خودکار

بکاپ دستی دیر یا زود فراموش می‌شود. با Schedule، Velero خودش هر شب بکاپ می‌گیرد:

velero schedule create daily-backup \
  --schedule="0 2 * * *" \
  --include-namespaces=my-app \
  --ttl 168h0m0s

--ttl 168h0m0s یعنی هر بکاپ بعد از ۷ روز از باکت حذف می‌شود. برای namespaceهای حساس‌تر می‌توانید یک Schedule دوم با TTL طولانی‌تر و فاصلهٔ کمتر هم بسازید.

تمرین بازیابی: فقط گرفتن بکاپ کافی نیست

بکاپی که هیچ‌وقت بازگردانی نشده، فقط یک فایل داخل یک باکت است. برای اینکه بدانید کار می‌کند یا نه، یک namespace تست را عمدا حذف کنید و برگردانید:

kubectl delete namespace my-app
velero restore create --from-backup first-backup

وضعیت بازیابی را چک کنید:

velero restore describe <نام-restore> --details

وقتی همهٔ Pod‌ها دوباره Running شدند و دیتابیس همان رکوردهای قبل از حذف را دارد، مطمئن هستید که هم بکاپ و هم مسیر بازیابی درست کار می‌کند. این تمرین را هر چند ماه یک‌بار تکرار کنید، نه فقط یک بار بعد از نصب.

چرا داده‌ها پشتیبان‌گیری نمی‌شود

این شکایت رایج‌ترین مشکلی است که بعد از نصب Velero می‌شنوید: بکاپ Completed می‌شود، اما وقتی بازیابی می‌کنید، دیتابیس خالی است. چند دلیل محتمل دارد:

• Node Agent نصب نیست یا روی همهٔ نودها اجرا نمی‌شود. با kubectl get daemonset node-agent -n velero بررسی کنید که تعداد Pod آمادهٔ آن برابر تعداد نودهاست.
• annotation روی Pod تنظیم نشده. بدون backup.velero.io/backup-volumes، Velero فقط manifest را می‌گیرد و حتی خطایی هم نمی‌دهد؛ سکوت کامل، همان چیزی که این مشکل را گیج‌کننده می‌کند.
• BackupStorageLocation در وضعیت Unavailable است. معمولا به دلیل Secret اشتباه، endpoint غلط یا نبود s3ForcePathStyle=true برای Object Storage غیر AWS.
• دسترسی نوشتن باکت کافی نیست. کلید استفاده‌شده باید هم خواندن و هم نوشتن روی همان باکت را داشته باشد.

راه قطعی برای فهمیدن اینکه کدام مورد است، همان تمرین بازیابی بالاست؛ به جای حدس زدن، یک namespace تست را بازیابی کنید و ببینید داده برمی‌گردد یا نه.

سرور اختصاصی یا VPS برای این کلاستر؟

جایی که نودهای کلاستر اجرا می‌شوند، مستقیم روی سرعت و قابلیت اطمینان بکاپ اثر دارد. control plane و نودهایی که etcd یا دیتابیس‌های اصلی روی آن‌ها اجرا می‌شوند، از دیسک و شبکهٔ پایدار یک سرور اختصاصی بیشتر سود می‌برند؛ Node Agent موقع خواندن داده‌های حجیم از PV، به I/O دیسک وابسته است و روی یک سرور اختصاصی این کار سریع‌تر و قابل‌پیش‌بینی‌تر پیش می‌رود. نودهای worker که فقط اپلیکیشن‌های stateless اجرا می‌کنند، معمولا روی VPS هم کافی هستند و هزینه را پایین نگه می‌دارند.

اگر هنوز بین این دو مطمئن نیستید، تفاوت سرور Bare Metal و VPS را هم بخوانید. و وقتی نوبت به باکت بکاپ رسید، بکاپ‌گیری خودکار از MySQL به Object Storage نشان می‌دهد همان باکت را می‌توانید برای دیتابیس‌های خارج از کلاستر هم استفاده کنید.

سرور اختصاصی مناسب برای کلاستر Kubernetes خودتان را از آریانت انتخاب کنید

جمع‌بندی

Velero سه کار اصلی برای یک کلاستر خودمیزبان انجام می‌دهد: بکاپ منابع، بکاپ داده‌های Volume با Node Agent، و بازیابی سریع از یک باکت Object Storage جدا از کلاستر. نصب اولیه چند دقیقه طول می‌کشد؛ کاری که وقت می‌برد، تنظیم annotation درست روی Podهای استیت‌فول و یک تمرین بازیابی واقعی است. همین دو مورد فرق بین یک بکاپ قابل اعتماد و یک فایل بی‌فایده داخل باکت را مشخص می‌کند.

سؤالات متداول

آیا Velero برای K3s هم کار می‌کند، نه فقط kubeadm؟ بله، Velero به توزیع Kubernetes وابسته نیست و روی هر کلاستر استاندارد از جمله K3s نصب و اجرا می‌شود.

چند روز بکاپ کلاستر را نگه دارم؟ بستگی به نیاز دارد؛ یک الگوی رایج، نگه‌داشتن بکاپ‌های روزانهٔ هفت روز اخیر با Schedule و TTL است، به‌علاوهٔ یک یا دو بکاپ ماهانه با TTL طولانی‌تر.

فرق Velero با اسنپ‌شات دیسک ابری چیست؟ اسنپ‌شات ابری فقط دیسک یک نود را کپی می‌کند و به API ارائه‌دهنده ابری وابسته است. Velero روی سطح منابع Kubernetes کار می‌کند و با Node Agent، داده Volume را هم بدون نیاز به چنین API مستقل می‌گیرد؛ برای کلاستر خودمیزبان گزینهٔ عملی‌تری است.

اگر Object Storage باکت پر شود چه اتفاقی می‌افتد؟ بکاپ بعدی با خطا شکست می‌خورد. تنظیم TTL روی Scheduleها همین مشکل را از قبل حل می‌کند، چون بکاپ‌های قدیمی خودکار حذف می‌شوند.