خودکارسازی پشتیبان‌گیری از MongoDB برای محیط‌های عملیاتی: یک راهنمای جامع

برای مهندسان DevOps و مدیران پایگاه داده (DBA)، مدیریت MongoDB در محیط عملیاتی (Production) چالش‌های منحصربه‌فردی را در زمینه حفاظت از داده‌ها ایجاد می‌کند. برخلاف پایگاه‌های داده رابطه‌ای سنتی، ماهیت توزیع‌شده MongoDB—که اغلب به صورت مجموعه‌های تکراری (Replica Sets) یا خوشه‌های شاردینگ (Sharded Clusters) بسیار پیچیده پیاده‌سازی می‌شود—نیازمند رویکردی تخصصی برای پشتیبان‌گیری است. یک کپی ساده از فایل‌ها به ندرت کافی است و فرآیندهای پشتیبان‌گیری دستی، راهی مطمئن برای از دست دادن داده‌ها، نقض قوانین انطباق و فرسودگی شغلی هستند.

در این راهنمای جامع، معماری پشتیبان‌گیری MongoDB را بررسی می‌کنیم، استراتژی‌های پشتیبان‌گیری منطقی و فیزیکی را مقایسه کرده و نحوه خودکارسازی قوی این فرآیندها را نشان خواهیم داد. همچنین بررسی خواهیم کرد که چگونه پلتفرم‌های سازمانی مانند CloudSave می‌توانند خودکارسازی پشتیبان‌گیری MongoDB را در مقیاس بزرگ هماهنگ و ساده کنند.

درک استراتژی‌های پشتیبان‌گیری MongoDB

پیش از پیاده‌سازی خودکارسازی، درک مکانیزم‌های زیربنایی که MongoDB برای استخراج داده‌ها فراهم می‌کند، حیاتی است. انتخاب استراتژی اشتباه می‌تواند منجر به بازیابی‌های ناسازگار یا افت شدید عملکرد در گره‌های اصلی (Primary Nodes) شما شود.

پشتیبان‌گیری منطقی (mongodump)

پشتیبان‌گیری منطقی مستقیماً با دیمون MongoDB (mongod) تعامل دارد، از پایگاه داده پرس‌وجو می‌کند و داده‌ها را با فرمت BSON صادر می‌کند.

مزایا:
* مستقل از سخت‌افزار و سیستم‌عامل.
* امکان پشتیبان‌گیری دانه‌ای (پایگاه داده‌ها یا مجموعه‌های خاص).
* فیلتر کردن آسان داده‌ها در طول فرآیند پشتیبان‌گیری.

معایب:
* مصرف بالای منابع (مصرف CPU و RAM در گره پایگاه داده).
* زمان بازیابی (RTO) طولانی برای مجموعه‌داده‌های بزرگ، زیرا ایندکس‌ها باید در طول فرآیند mongorestore دوباره ساخته شوند.

پشتیبان‌گیری فیزیکی (اسنپ‌شات‌های سیستم فایل)

پشتیبان‌گیری فیزیکی شامل گرفتن اسنپ‌شات از حجم ذخیره‌سازی زیربنایی است که موتور ذخیره‌سازی WiredTiger در MongoDB فایل‌های داده خود را در آن می‌نویسد. این کار معمولاً با استفاده از اسنپ‌شات‌های Logical Volume Manager (LVM) یا اسنپ‌شات‌های ذخیره‌سازی بلوکی ابری (مانند AWS EBS، Azure Managed Disks) انجام می‌شود.

مزایا:
* زمان پشتیبان‌گیری و بازیابی بسیار سریع (RTO پایین).
* حداقل تأثیر بر عملکرد موتور پایگاه داده.
* ثبت وضعیت دقیق فایل‌های داده و ایندکس‌های WiredTiger.

معایب:
* نیازمند دسترسی و هماهنگی در سطح سیستم‌عامل یا ابر است.
* بازیابی‌ها به صورت “همه یا هیچ” هستند؛ شما نمی‌توانید به راحتی یک مجموعه (Collection) خاص را از یک اسنپ‌شات فیزیکی بدون راه‌اندازی یک نمونه موقت بازیابی کنید.

چالش سازگاری: Oplog و fsyncLock

پشتیبان‌گیری اگر سازگار نباشد، بی‌فایده است. از آنجایی که MongoDB دائماً در حال پردازش عملیات نوشتن است، یک عملیات پشتیبان‌گیری که ۳۰ دقیقه طول می‌کشد، داده‌ها را در نقاط زمانی متفاوتی ثبت می‌کند.

برای پشتیبان‌گیری منطقی، سازگاری با استفاده از پرچم --oplog به دست می‌آید. این کار mongodump را مجبور می‌کند که لاگ عملیات (oplog) را در کنار داده‌ها ثبت کند. در طول بازیابی، این عملیات‌ها دوباره اجرا می‌شوند تا مجموعه‌داده به یک نقطه زمانی واحد و سازگار برسد.

برای پشتیبان‌گیری فیزیکی، باید اطمینان حاصل کنید که اسنپ‌شات سیستم فایل، وضعیت سازگاری از فایل‌های WiredTiger را ثبت می‌کند. اگرچه WiredTiger می‌تواند از اسنپ‌شات‌های “سقوط‌-سازگار” (crash-consistent) بازیابی شود، بهترین روش این است که تمام عملیات‌های نوشتن معلق را روی دیسک تخلیه کرده و پایگاه داده را به طور لحظه‌ای با استفاده از db.fsyncLock() قفل کنید.

// قفل کردن پایگاه داده و تخلیه عملیات نوشتن روی دیسک
db.adminCommand({ fsync: 1, lock: true });

// ... اسنپ‌شات LVM یا EBS را اینجا اجرا کنید ...

// باز کردن قفل پایگاه داده برای از سرگیری عملیات نوشتن
db.adminCommand({ fsyncUnlock: 1 });

معماری یک خط لوله پشتیبان‌گیری تاب‌آور

معماری پشتیبان‌گیری MongoDB در سطح عملیاتی باید از قانون ۳-۲-۱ پیروی کند: سه کپی از داده‌های شما، روی دو رسانه مختلف، با یک نسخه خارج از سایت.

گام ۱: ایمن‌سازی کاربر پشتیبان‌گیری (RBAC)

هرگز از کاربر root برای پشتیبان‌گیری خودکار استفاده نکنید. MongoDB یک نقش داخلی backup ارائه می‌دهد که حداقل امتیازات لازم برای خواندن داده‌ها و oplog را اعطا می‌کند.

به گره اصلی (Primary) MongoDB خود متصل شوید و یک کاربر پشتیبان‌گیری اختصاصی ایجاد کنید:

use admin
db.createUser({
  user: "cloudsave_backup_agent",
  pwd: passwordPrompt(), // یا یک رمز عبور قوی و محافظت‌شده وارد کنید
  roles: [
    { role: "backup", db: "admin" },
    { role: "read", db: "local" } // برای دسترسی به oplog الزامی است
  ]
})

گام ۲: خودکارسازی بومی از طریق Bash و Cron (روش پایه)

برای پیاده‌سازی‌های کوچک‌تر، مهندسان اغلب با اسکریپت‌های bash سفارشی که از طریق cron زمان‌بندی شده‌اند، شروع می‌کنند. در زیر نمونه‌ای از یک اسکریپت پشتیبان‌گیری منطقی قوی آورده شده است که یک آرشیو فشرده را مستقیماً به یک سطل S3 خارج از سایت ارسال می‌کند و از اتمام فضای دیسک محلی جلوگیری می‌کند.

#!/bin/bash
# mongodb_backup.sh

MONGO_URI="mongodb://cloudsave_backup_agent:STRONG_PASSWORD@mongo-node-01:27017,mongo-node-02:27017/?replicaSet=rs0&authSource=admin"
S3_BUCKET="s3://my-company-offsite-backups/mongodb/"
DATE=$(date +%Y-%m-%dT%H:%M:%SZ)

echo "Starting MongoDB backup at $DATE"

# اجرای mongodump، خروجی به صورت آرشیو gzip به stdout، و ارسال به AWS CLI
mongodump --uri="$MONGO_URI" 
          --readPreference=secondary 
          --oplog 
          --gzip 
          --archive | aws s3 cp - "${S3_BUCKET}mongo_backup_${DATE}.archive.gz"

if [ $? -eq 0 ]; then
  echo "Backup completed successfully."
else
  echo "Backup failed!" >&2
  exit 1
fi

اگرچه این اسکریپت‌ها کارآمد هستند، اما نگهداری آن‌ها در ده‌ها خوشه، رسیدگی به هشدارها، مدیریت سیاست‌های نگهداری و هماهنگ‌سازی پشتیبان‌گیری خوشه‌های شاردینگ، به سرعت به یک کابوس عملیاتی تبدیل می‌شود.

خودکارسازی سازمانی با CloudSave

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

پیکربندی عامل (Agent) CloudSave برای MongoDB

CloudSave با استفاده از یک عامل سبک و ایمن که روی گره‌های پایگاه داده شما نصب می‌شود یا از طریق یک صفحه کنترل مبتنی بر API برای سرویس‌های مدیریت‌شده مانند MongoDB Atlas عمل می‌کند.

برای خودکارسازی پشتیبان‌گیری از طریق CloudSave، ابتدا خوشه MongoDB را با استفاده از CLI CloudSave ثبت می‌کنید. این کار پیچیدگی رشته‌های اتصال و اولویت‌های خواندن را انتزاعی می‌کند.

# ثبت مجموعه تکراری MongoDB با CloudSave
cloudsave resource add mongodb 
  --name "prod-billing-cluster" 
  --uri "mongodb://cloudsave_backup_agent:********@node1,node2,node3/?replicaSet=rs0" 
  --read-preference "secondaryPreferred"

تعریف سیاست‌های پشتیبان‌گیری به عنوان کد

تیم‌های DevOps می‌توانند سیاست‌های پشتیبان‌گیری CloudSave را با استفاده از YAML مدیریت کنند، که به پیکربندی‌های پشتیبان‌گیری اجازه می‌دهد در کنار کد زیرساخت (GitOps) در Git کنترل نسخه شوند.

# cloudsave-mongo-policy.yml
apiVersion: cloudsave.io/v1
kind: BackupPolicy
metadata:
  name: mongodb-tier1-policy
spec:
  resource: prod-billing-cluster
  type: logical
  schedule: "0 */4 * * *" # اجرا هر ۴ ساعت
  retention:
    hourly: 24
    daily: 7
    weekly: 4
  options:
    enableOplog: true
    compression: zstd
    encryptionKey: "arn:aws:kms:us-east-1:123456789012:key/abcd-1234"
  storageTarget:
    name: "cloudsave-immutable-vault-us-east"

اعمال این سیاست به طور خودکار زمان‌بندی را پیکربندی می‌کند، سازگاری --oplog را مدیریت می‌کند، داده‌ها را با استفاده از zstd با کارایی بالا فشرده می‌کند، آن‌ها را در حالت استراحت با استفاده از کلید KMS شما رمزگذاری می‌کند و برای محافظت در برابر باج‌افزار، آن‌ها را به یک مخزن ذخیره‌سازی غیرقابل تغییر (Immutable) هدایت می‌کند.

cloudsave policy apply -f cloudsave-mongo-policy.yml

بازیابی در نقطه زمانی (PITR) از طریق آرشیو Oplog

برای پایگاه‌های داده حیاتی، هدف نقطه بازیابی (RPO) ۴ ساعته اغلب غیرقابل قبول است. CloudSave با دنبال کردن oplog در MongoDB، از بازیابی مداوم در نقطه زمانی (PITR) پشتیبانی می‌کند.

هنگامی که PITR فعال است، CloudSave اسنپ‌شات‌های پایه دوره‌ای (مثلاً روزانه) می‌گیرد و به طور مداوم oplog را به مخزن پشتیبان‌گیری ارسال می‌کند. اگر یک توسعه‌دهنده به طور تصادفی یک مجموعه را در ساعت ۱۴:۳۲:۱۵ حذف کند، DBA می‌تواند از CloudSave برای بازیابی پایگاه داده دقیقاً به ساعت ۱۴:۳۲:۱۴ استفاده کند.

# نمونه دستور بازیابی CloudSave برای PITR
cloudsave restore initiate 
  --resource "prod-billing-cluster" 
  --target-instance "staging-billing-cluster" 
  --point-in-time "2023-10-27T14:32:14Z"

خودکارسازی پشتیبان‌گیری خوشه‌های شاردینگ

خوشه‌های شاردینگ پیچیدگی شدیدی ایجاد می‌کنند. از آنجایی که داده‌ها در چندین مجموعه تکراری (شاردها) توزیع شده‌اند، گرفتن پشتیبان‌گیری مستقل از هر شارد منجر به اسناد یتیم و روابط شکسته می‌شود.

برای پشتیبان‌گیری ایمن از یک خوشه شاردینگ، ابزار خودکارسازی باید:

۱. متعادل‌کننده (Balancer) خوشه را متوقف کند تا از مهاجرت تکه‌های داده در طول پشتیبان‌گیری جلوگیری شود.
۲. سرورهای پیکربندی (که متادیتای خوشه را ذخیره می‌کنند) را قفل کند.
۳. اسنپ‌شات‌های همزمان از تمام شاردها بگیرد.
۴. سرورهای پیکربندی را باز کرده و متعادل‌کننده را دوباره فعال کند.

CloudSave این هماهنگی را به صورت بومی مدیریت می‌کند. هنگامی که یک منبع به عنوان sharded_cluster تعریف می‌شود، عامل CloudSave به طور خودکار با مسیریاب mongos ارتباط برقرار می‌کند تا متعادل‌کننده را غیرفعال کند، اسنپ‌شات توزیع‌شده را در تمام عوامل شارد از طریق صفحه کنترل خود هماهنگ می‌کند و عملیات خوشه را به صورت یکپارچه از سر می‌گیرد—که این امر سازگاری جهانی را بدون مداخله دستی DBA تضمین می‌کند.

بهترین روش‌ها برای پشتیبان‌گیری عملیاتی MongoDB

چه در حال ساخت خودکارسازی خود باشید و چه از CloudSave استفاده می‌کنید، از بهترین روش‌های زیر پیروی کنید:

۱. همیشه از گره‌های ثانویه (Secondary) پشتیبان بگیرید

هرگز پشتیبان‌گیری منطقی را روی گره اصلی (Primary) خود اجرا نکنید. سربار CPU و I/O ناشی از خواندن کل مجموعه‌داده باعث ایجاد تأخیر برای برنامه شما می‌شود. ابزارهای پشتیبان‌گیری خود را طوری پیکربندی کنید که از readPreference به صورت secondary یا secondaryPreferred استفاده کنند. اگر یک گره تحلیل اختصاصی (یک ثانویه مخفی) دارید، آن گره را به طور خاص برای پشتیبان‌گیری هدف قرار دهید.

۲. ذخیره‌سازی غیرقابل تغییر (Immutable) را پیاده‌سازی کنید

باج‌افزارها اغلب قبل از رمزگذاری داده‌های اصلی، پشتیبان‌های پایگاه داده را هدف قرار می‌دهند. اطمینان حاصل کنید که مقصد پشتیبان‌گیری شما از Object Lock یا غیرقابل تغییر بودن پشتیبانی می‌کند. مخازن غیرقابل تغییر CloudSave تضمین می‌کنند که وقتی یک پشتیبان MongoDB نوشته می‌شود، تا زمانی که دوره نگهداری منقضی نشود، قابل تغییر یا حذف نیست—حتی توسط یک حساب کاربری مدیر که به خطر افتاده باشد.

۳. تست بازیابی را خودکار کنید

یک پشتیبان‌گیری تنها زمانی یک شبکه ایمنی نظری است که با موفقیت بازیابی شده باشد. خودکارسازی نباید فقط به استخراج داده ختم شود. خط لوله‌ای را پیاده‌سازی کنید که به طور دوره‌ای (مثلاً هفتگی) آخرین پشتیبان را در یک محیط استیجینگ ایزوله بازیابی کند، اسکریپتی را برای تأیید تعداد اسناد و یکپارچگی ایندکس اجرا کند و نتیجه را به تیم اطلاع دهد.

۴. نظارت و هشدار

شکست‌های خام در پشتیبان‌گیری، بدترین کابوس یک DBA است. اطمینان حاصل کنید که خودکارسازی پشتیبان‌گیری شما معیارها (Metrics) را منتشر می‌کند. اگر از اسکریپت‌های سفارشی استفاده می‌کنید، معیارهای موفقیت/شکست را به Prometheus یا Datadog ارسال کنید. اگر از CloudSave استفاده می‌کنید، وب‌هوک‌های بومی آن را پیکربندی کنید تا در صورت نقض SLA مربوط به RPO، فوراً به کانال‌های PagerDuty یا Slack شما هشدار دهند.

نتیجه‌گیری

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

با بهره‌گیری از یک پلتفرم سازمانی مانند CloudSave، تیم‌های DevOps و DBA می‌توانند پیچیدگی مدیریت oplog، هماهنگی خوشه‌های شاردینگ و چرخه‌های حیات نگهداری را انتزاعی کنند. این به تیم‌های مهندسی اجازه می‌دهد تا تمرکز خود را از نگهداری اسکریپت‌های پشتیبان‌گیری شکننده به ساخت برنامه‌های تاب‌آور و با کارایی بالا تغییر دهند، با این اطمینان که داده‌هایشان به طور مداوم محافظت شده و به سرعت قابل بازیابی است.