چرا بکاپ‌گیری حرفه‌ای حیاتی‌است؟ معرفی روش‌ها و سناریوها

داده یکی از مهم‌ترین دارایی‌های هر سازمان است؛ اما تا زمانی که امکان بازیابی آن در زمان مناسب و در شرایط واقعی بحران اثبات نشده باشد، صرفاً داشتن چند فایل Backup به معنی محافظت از داده نیست.

خرابی دیسک، خطای انسانی، حذف تصادفی اطلاعات، خرابی دیتابیس، حملات باج‌افزاری، آسیب زیرساخت، خطای نرم‌افزاری، از دست رفتن یک سرور یا حتی یک تغییر اشتباه در سیستم می‌تواند باعث شود بخشی از داده‌ها یا کل سرویس از دسترس خارج شود. در چنین شرایطی، تفاوت میان یک سازمان دارای Backup واقعی و قابل بازیابی و سازمانی که فقط تصور می‌کرد Backup دارد، بسیار جدی است.

بکاپ‌گیری حرفه‌ای بخشی از یک استراتژی بزرگ‌تر برای Data Protection، Business Continuity و Disaster Recovery است. این استراتژی باید مشخص کند چه داده‌ای، با چه فاصله زمانی، در چه مکانی، با چه سطحی از امنیت و برای چه مدت نگهداری شود و مهم‌تر از همه، در صورت بروز بحران چگونه و در چه مدت بازیابی خواهد شد.

در این مقاله، روش‌های مختلف Backup، مفهوم‌های RPO و RTO، قانون 3-2-1، Snapshot، Full و Incremental Backup، Point-in-Time Recovery، Immutable Backup، سناریوهای رایج خرابی و اصول طراحی یک معماری حرفه‌ای Backup را بررسی می‌کنیم.

چرا بکاپ‌گیری حرفه‌ای حیاتی است؟

ممکن است یک سازمان تصور کند چون اطلاعات روی RAID، Storage، Cloud یا چند سرور مختلف قرار دارد، در برابر از دست رفتن داده‌ها ایمن است. اما بسیاری از این فناوری‌ها اساساً Backup نیستند.

برای مثال، RAID می‌تواند در برابر خرابی بعضی از دیسک‌ها مقاومت ایجاد کند، اما اگر یک فایل به اشتباه حذف شود، دیتابیس خراب شود یا یک حساب کاربری با دسترسی بالا اطلاعات را حذف کند، RAID لزوماً راهی برای بازگرداندن نسخه قبلی داده ارائه نمی‌کند.

به همین ترتیب، Replication نیز الزاماً Backup نیست. اگر یک داده خراب یا رمزگذاری شود و همان تغییر به Replica منتقل شود، ممکن است تمام نسخه‌های آنلاین نیز تحت تأثیر قرار بگیرند.

Backup حرفه‌ای باید بتواند در برابر خطای منطقی، خطای انسانی، خرابی فیزیکی و حتی برخی سناریوهای امنیتی یک نقطه بازیابی مستقل در اختیار سازمان قرار دهد.

مهم‌ترین دلایل نیاز به Backup

• خرابی دیسک یا Storage
• حذف تصادفی فایل‌ها یا رکوردهای دیتابیس
• خطای انسانی و تغییرات اشتباه
• خرابی یا Corruption دیتابیس
• حملات Ransomware و Data Destruction
• خرابی نرم‌افزار یا Deployment اشتباه
• از دست رفتن یا خرابی یک سرور
• خرابی یک Data Center یا Site
• خطا در Migration یا Upgrade
• نیاز به بازگردانی اطلاعات به یک نقطه زمانی مشخص

راهنماهای معماری قابل اتکا نیز Backup را صرفاً به «کپی گرفتن از داده» محدود نمی‌کنند و بر تعریف اهداف Recovery، محافظت از Backup و انجام Restore Test تأکید دارند.

Backup چیست و چه تفاوتی با Replication و High Availability دارد؟

سه مفهوم Backup، Replication و High Availability گاهی به جای یکدیگر استفاده می‌شوند، در حالی که اهداف متفاوتی دارند.

یک معماری مقاوم معمولاً به ترکیبی از این تکنیک‌ها نیاز دارد. برای مثال، ممکن است یک دیتابیس دارای Replica برای High Availability باشد، اما همزمان Backup روزانه و Point-in-Time Recovery نیز برای مقابله با خطای منطقی یا حذف تصادفی داده داشته باشد.

مفهوم RPO؛ چه مقدار Data Loss قابل قبول است؟

RPO یا Recovery Point Objective مشخص می‌کند در صورت وقوع بحران، حداکثر چه مقدار از داده‌ها می‌تواند از بین برود.

فرض کنید RPO یک سیستم ۱ ساعت باشد. این یعنی معماری Backup باید طوری طراحی شود که در یک سناریوی Recovery، از دست رفتن بیش از یک ساعت داده قابل انتظار نباشد.

برای مثال:

• RPO = ۲۴ ساعت → Backup روزانه ممکن است کافی باشد.
• RPO = ۴ ساعت → Backup باید حداقل با فاصله‌های چندساعته انجام شود.
• RPO = ۱۵ دقیقه → Backup یا Replication با Granularity بالاتر مورد نیاز است.
• RPO نزدیک به صفر → معمولاً باید سراغ Replication، Continuous Backup یا معماری‌های خاص رفت.

نکته مهم این است که RPO یک عدد تکنیکی نیست که DevOps یا تیم زیرساخت به‌تنهایی تعیین کند؛ این مقدار باید از نیاز کسب‌وکار، هزینه از دست رفتن داده و وابستگی‌های سیستم مشخص شود.

مفهوم RTO؛ چقدر زمان برای Recovery داریم؟

RTO یا Recovery Time Objective حداکثر زمان قابل قبول برای بازگرداندن سرویس پس از یک اختلال است.

برای مثال، اگر RTO یک سرویس ۲ ساعت باشد، طراحی Recovery باید به گونه‌ای باشد که سرویس بتواند در محدوده تعیین‌شده دوباره در دسترس قرار گیرد.

RTO فقط به سرعت Backup وابسته نیست. زمان‌های زیر نیز باید در نظر گرفته شوند:

• پیدا کردن Recovery Point مناسب
• Provision کردن Server یا VM جدید
• انتقال داده
• Restore دیتابیس
• Deploy کردن Application
• تنظیم DNS و Network
• بازیابی Secretها و Configurationها
• اجرای Migrationهای لازم
• Validation سرویس
• بازگرداندن Traffic

بنابراین ممکن است یک Backup موفق باشد اما فرآیند Recovery آن سه ساعت طول بکشد؛ در این صورت اگر RTO سازمان یک ساعت بوده باشد، Backup به‌تنهایی نیاز Recovery را برآورده نمی‌کند.

RPO و RTO را با هم ببینیم

اعداد بالا صرفاً نمونه معماری هستند و نباید بدون تحلیل Business Impact برای همه سازمان‌ها یکسان در نظر گرفته شوند.

قانون 3-2-1 در Backup چیست؟

یکی از شناخته‌شده‌ترین اصول طراحی Backup، قانون 3-2-1 است.

• ۳ نسخه از داده داشته باشید.
• این نسخه‌ها روی حداقل ۲ نوع Media یا محل نگهداری قرار بگیرند.
• حداقل ۱ نسخه خارج از محل اصلی نگهداری شود.

برای مثال، یک سازمان می‌تواند Production Data را روی Storage اصلی نگهداری کند، یک Backup روی Storage داخلی و یک نسخه دیگر را در یک Site یا Storage مستقل قرار دهد.

راهنمای CISA نیز برای مقابله با سناریوهایی مانند Ransomware بر نگهداری نسخه‌های متعدد، جداشده و Offline و همچنین اجرای منظم فرآیند Backup و Restore تأکید می‌کند.

3-2-1-1-0 چیست؟

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

• ۳ نسخه از داده
• ۲ نوع Storage یا Media
• ۱ نسخه Off-site
• ۱ نسخه Immutable یا Offline
• ۰ خطای تأییدنشده در فرآیند Backup

عدد صفر در اینجا به یک هدف عملی اشاره دارد: Backup نباید صرفاً با وضعیت Successful در نرم‌افزار Backup تمام شود؛ باید امکان بررسی Integrity و Recovery نیز وجود داشته باشد.

انواع روش‌های Backup

Full Backup

در Full Backup، مجموعه داده مورد نظر به صورت کامل Backup می‌شود.

مزیت اصلی Full Backup، سادگی Recovery است؛ زیرا برای Restore معمولاً به یک Backup کامل نیاز داریم. در مقابل، اجرای مکرر Full Backup می‌تواند مصرف Storage و زمان Backup را افزایش دهد.

Incremental Backup

در Incremental Backup، فقط تغییرات ایجادشده نسبت به Backup قبلی ذخیره می‌شوند.

این روش معمولاً برای Backupهای پرتکرار مناسب است، زیرا حجم هر Backup نسبت به Full Backup کمتر خواهد بود.

در برخی سیستم‌های Backup، اولین نسخه Full و نسخه‌های بعدی Incremental هستند و نرم‌افزار Backup اطلاعات لازم برای Restore کامل را مدیریت می‌کند. بنابراین جزئیات زنجیره Backup به محصول و Storage Backend مورد استفاده وابسته است.

Differential Backup

در Differential Backup، تغییرات از آخرین Full Backup مبنا قرار می‌گیرند.

بنابراین با گذشت زمان حجم Differentialها افزایش پیدا می‌کند، اما Recovery می‌تواند نسبت به برخی مدل‌های Incremental ساده‌تر باشد.

Snapshot

Snapshot تصویری از وضعیت یک Volume، VM، Dataset یا Resource در یک زمان مشخص است.

Snapshot می‌تواند برای Recovery سریع بسیار مفید باشد، اما نباید بدون بررسی معماری Storage آن را معادل یک Backup مستقل در نظر گرفت.

اگر Snapshotها روی همان Storage، همان Cluster یا همان حساب مدیریتی Production قرار داشته باشند، ممکن است یک خرابی بزرگ یا حمله امنیتی روی Backupها نیز اثر بگذارد.

Continuous Backup و Point-in-Time Recovery

در برخی سیستم‌ها می‌توان تغییرات داده را به شکل Continuous ثبت کرد و سپس سیستم را به یک نقطه زمانی مشخص بازگرداند. این مدل به‌خصوص برای دیتابیس‌ها اهمیت زیادی دارد.

در Point-in-Time Recovery یا PITR، به جای انتخاب صرفاً یک Snapshot، امکان انتخاب زمان مشخصی برای Recovery وجود دارد؛ البته مدت نگهداری و دقت زمانی آن به تکنولوژی مورد استفاده بستگی دارد.

برای مثال، اگر ساعت ۱۴:۳۰ یک خطای انسانی باعث حذف بخشی از داده شده باشد، می‌توان در صورت پشتیبانی سیستم از PITR، Recovery را به زمان قبل از خطا بازگرداند.

Backup دیتابیس؛ فقط کپی فایل دیتابیس کافی نیست

دیتابیس یکی از مهم‌ترین بخش‌های هر سیستم است و Backup آن باید با توجه به نوع Database و مدل Transaction طراحی شود.

روش‌های متداول شامل:

• Logical Backup مانند Dump
• Physical Backup
• Database Snapshot
• Incremental Backup
• Continuous Transaction Log Backup
• Point-in-Time Recovery
• Replication در کنار Backup

برای دیتابیس‌های مهم، باید مشخص شود آیا Backup از نظر Application Consistency معتبر است یا صرفاً یک Copy از فایل‌های روی Disk تهیه شده است.

همچنین باید وابستگی‌های دیتابیس با Application، فایل‌ها، Object Storage، Queueها و Configurationها در Recovery در نظر گرفته شوند.

Application-Consistent Backup چیست؟

یکی از اشتباهات رایج این است که تصور کنیم اگر Storage از اطلاعات یک VM Snapshot گرفته، کل Application قابل Recovery است.

در یک سیستم واقعی ممکن است همزمان این اجزا وجود داشته باشند:

• Application Server
• Database
• Object Storage
• Redis
• Message Broker
• Configuration
• Secretها
• Certificateها
• Infrastructure as Code
• Persistent Volumes

اگر فقط یکی از این اجزا Backup شود، ممکن است Restore کامل Application امکان‌پذیر نباشد.

Backup حرفه‌ای باید به جای نگاه کردن به «Server»، به Workload نگاه کند؛ یعنی تمام اجزایی که برای اجرای آن سرویس ضروری هستند شناسایی و برای Recovery آن‌ها برنامه‌ریزی شوند.

چه چیزهایی باید Backup شوند؟

نکته مهم این است که همه چیز الزاماً نباید Backup شود. برخی داده‌ها می‌توانند از Source دیگری مجدداً تولید شوند. اما این تصمیم باید آگاهانه باشد و مشخص شود در صورت از دست رفتن آن داده، چه چیزی برای Rebuild کردن سرویس لازم است.

Backup و Kubernetes

در محیط‌های Kubernetes، مفهوم Backup پیچیده‌تر از گرفتن Snapshot از یک Server است.

یک Application ممکن است شامل Deployment، ConfigMap، Secret، Persistent Volume، Database خارج از Cluster، Object Storage و External Service باشد.

بنابراین Backup یک Cluster باید بر اساس نیاز Workload طراحی شود.

در Kubernetes معمولاً چند لایه Backup مورد نیاز است:

• Backup از منابع و Manifestهای Kubernetes
• Backup از Persistent Volumeها
• Backup از دیتابیس‌ها
• Backup از Object Storage
• Backup از Configuration و Secretهای مورد نیاز
• نگهداری Manifestها و IaC در Version Control
• در صورت نیاز Backup از etcd

در معماری‌های GitOps، بخشی از Configuration از Git قابل بازسازی است؛ بنابراین باید بین Data Backup و Configuration Recovery تفاوت قائل شد.

برای آشنایی بیشتر با معماری Kubernetes می‌توانید مقاله مقدمه‌ای بر کوبرنتیس را نیز مطالعه کنید.

Backup در معماری‌های Cloud و Private Cloud

در Cloud یا Private Cloud، Backup می‌تواند روی Storageهای مختلف انجام شود؛ از جمله Object Storage، Backup Repository، Storage جداگانه، Site دوم یا Data Center دیگر.

در معماری‌های بزرگ‌تر، بهتر است Backup Repository از Production Environment تا حد امکان مستقل باشد.

برای مثال:

Production
    │
    ├── Database
    ├── Application
    ├── Object Storage
    │
    ▼
Backup System
    │
    ├── Local Backup Repository
    │
    ├── Off-site Copy
    │
    └── Immutable / Offline Copy

هدف این معماری این است که خرابی Production به تنهایی به معنی از دست رفتن تمام Recovery Pointها نباشد.

Immutable Backup چیست؟

Immutable Backup نسخه‌ای از Backup است که در یک بازه مشخص نمی‌توان آن را تغییر داد یا حذف کرد.

این ویژگی در مقابله با Ransomware اهمیت زیادی دارد؛ زیرا مهاجم ممکن است پس از دسترسی به زیرساخت تلاش کند Backupها را نیز پیدا و حذف یا رمزگذاری کند.

به همین دلیل، CISA بر نگهداری Backupهای Offline و همچنین استفاده از Backupهای رمزنگاری‌شده و Immutable برای کاهش ریسک Ransomware تأکید کرده است.

البته Immutable بودن به تنهایی کافی نیست. اگر Backup اشتباه، ناقص یا غیرقابل Restore باشد، Immutable بودن فقط یک نسخه اشتباه را برای مدت طولانی حفظ می‌کند.

Offline Backup چیست؟

در Offline Backup، نسخه Backup در زمان‌هایی از محیط Production و شبکه عملیاتی جدا است.

این مدل یک لایه دفاعی مهم در برابر حملاتی است که مهاجم پس از نفوذ به شبکه تلاش می‌کند تمام Backupهای قابل دسترسی را حذف کند.

در محیط‌های مدرن، «Offline» الزاماً به معنی Tape نیست. بسته به معماری می‌توان از ترکیبی از Storage جداگانه، Object Storage با کنترل دسترسی، Immutable Repository و Mediaهای جداشده استفاده کرد.

Retention Policy؛ Backup را تا چه زمانی نگه داریم؟

Backup بدون سیاست Retention می‌تواند خیلی سریع یا بیش از حد زیاد شود.

یک سیاست نمونه ممکن است به این شکل باشد:

این اعداد صرفاً نمونه هستند. Retention باید بر اساس RPO، الزامات قانونی، هزینه Storage، نوع داده و نیازهای کسب‌وکار تعیین شود.

Backup و Ransomware

Ransomware یکی از مهم‌ترین دلایلی است که باعث شده Backup دیگر صرفاً یک موضوع عملیاتی نباشد و به بخشی از Security Architecture تبدیل شود.

در یک سناریوی ساده:

1. مهاجم وارد شبکه می‌شود.
2. به یک حساب Privileged دسترسی پیدا می‌کند.
3. داده‌های Production را رمزگذاری می‌کند.
4. Backupهای Online را پیدا می‌کند.
5. در صورت دسترسی، Backupها را نیز حذف یا رمزگذاری می‌کند.
6. سازمان متوجه می‌شود که Backup قابل استفاده‌ای ندارد.

به همین دلیل، معماری Backup باید شامل کنترل‌هایی مانند:

• جدا کردن دسترسی Backup از Production
• Least Privilege
• رمزنگاری Backup
• Immutable Storage
• Offline یا Air-Gapped Copy در صورت نیاز
• تفکیک Account یا Domain مدیریتی
• Monitoring و Alerting
• تست منظم Restore

باشد.

Backup Monitoring؛ اگر Backup شکست بخورد چه می‌شود؟

یکی از خطرناک‌ترین حالت‌ها این است که Backup برای هفته‌ها اجرا نشود اما هیچ‌کس متوجه آن نشود.

به همین دلیل، Backup باید مانند یک سرویس Production مانیتور شود.

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

• موفق یا ناموفق بودن Backup Job
• مدت زمان اجرای Backup
• حجم Backup
• رشد غیرعادی حجم داده
• ظرفیت باقی‌مانده Backup Storage
• قدیمی شدن آخرین Recovery Point
• Integrity Check
• Replication یا Copy Job
• Immutable Retention
• موفقیت Restore Test

برای محیط‌های زیرساختی، Backup نباید یک Job مستقل و بدون Visibility باشد؛ باید بخشی از Observability و Operational Monitoring سازمان باشد.

برای آشنایی بیشتر با این موضوع می‌توانید مقاله Private Observability چیست؟ و همچنین Grafana چیست؟ را مطالعه کنید.

مهم‌ترین بخش Backup: Restore Test

اگر فقط یک نکته از کل استراتژی Backup قرار باشد جدی گرفته شود، آن نکته باید Restore Testing باشد.

Backupی که هیچ‌وقت Restore نشده، صرفاً یک فرض است.

ممکن است Backup Job با موفقیت تمام شده باشد اما هنگام Recovery متوجه شویم:

• Backup ناقص است.
• داده Corrupt شده است.
• Credentialهای مورد نیاز در دسترس نیستند.
• نسخه Application با Backup سازگار نیست.
• Storage مقصد ظرفیت کافی ندارد.
• Restore بسیار بیشتر از RTO زمان می‌برد.
• یک Dependency مهم Backup نشده است.
• Backup متعلق به زمانی است که داده مورد نظر هنوز وجود نداشته است.

راهنمای AWS نیز تأکید می‌کند که Restore Test باید به‌صورت دوره‌ای انجام شود و صرفاً موفق بودن عملیات Restore کافی نیست؛ باید بررسی شود که داده واقعاً قابل استفاده است و Recovery در محدوده RPO و RTO انجام می‌شود.

یک Restore Test حرفه‌ای چه مراحلی دارد؟

1. انتخاب یک Recovery Point.
2. Restore کردن آن در یک محیط جداگانه.
3. بررسی Integrity داده.
4. اجرای Application.
5. بررسی Database و Queryها.
6. بررسی File و Object Storage.
7. بررسی Secretها و Configurationها.
8. اندازه‌گیری زمان Recovery.
9. مقایسه نتیجه با RTO و RPO.
10. ثبت نتیجه و اصلاح Runbook در صورت وجود مشکل.

سناریوهای اصلی Backup و Recovery

سناریوی اول: حذف تصادفی یک فایل

در این سناریو، معمولاً Full Disaster Recovery لازم نیست.

یک Recovery Point مناسب باید بتواند فایل حذف‌شده را به صورت Granular Restore کند.

این یکی از دلایلی است که Backup حرفه‌ای باید در صورت امکان از Recovery در سطوح مختلف پشتیبانی کند:

• File-Level Recovery
• Database-Level Recovery
• Application-Level Recovery
• VM-Level Recovery
• Infrastructure-Level Recovery

سناریوی دوم: خراب شدن دیتابیس

اگر دیتابیس به دلیل خطای نرم‌افزاری یا انسانی Corrupt شده باشد، Snapshot روزانه ممکن است کافی نباشد.

در چنین شرایطی، داشتن Transaction Log و PITR می‌تواند امکان بازگشت به زمانی قبل از وقوع خطا را فراهم کند.

سناریوی سوم: Ransomware

در این حالت باید فرض کنیم Production و حتی برخی Backupهای Online ممکن است تحت تأثیر قرار گرفته باشند.

به همین دلیل وجود یک نسخه جداشده، Immutable یا Offline اهمیت زیادی دارد.

سناریوی چهارم: خرابی کامل یک Server

در این حالت علاوه بر Data Backup، داشتن Infrastructure Automation و Image یا Templateهای قابل استفاده می‌تواند زمان Recovery را به شکل قابل توجهی کاهش دهد.

برای مثال، ترکیب Backup داده با Infrastructure as Code می‌تواند امکان بازسازی زیرساخت و سپس Restore داده را فراهم کند.

سناریوی پنجم: از دست رفتن Data Center

اگر تمام Backupها در همان Data Center نگهداری شوند، ممکن است یک حادثه فیزیکی باعث از بین رفتن Production و Backup همزمان شود.

برای چنین سناریویی باید حداقل یک Recovery Copy در محل یا Site دیگری نگهداری شود.

این موضوع یکی از نقاط اتصال Backup با Disaster Recovery و Business Continuity است.

سناریوی ششم: Deployment اشتباه

فرض کنید یک Release باعث حذف یا تغییر اشتباه داده‌ها شده است.

در این حالت Backup می‌تواند امکان بازگشت داده را فراهم کند، اما بهتر است در کنار آن از Deployment Strategy مناسب، Database Migration کنترل‌شده، Rollback و Monitoring نیز استفاده شود.

Backup نباید جایگزین فرآیند صحیح Release و Change Management شود.

Backup و Disaster Recovery چه تفاوتی دارند؟

Backup بیشتر درباره داشتن Recovery Point است، در حالی که Disaster Recovery درباره بازگرداندن سرویس و کسب‌وکار پس از یک اختلال صحبت می‌کند.

برای مثال:

Backup
   │
   ├── Database Backup
   ├── File Backup
   ├── Object Storage Backup
   └── Configuration Backup
             │
             ▼
      Recovery Points
             │
             ▼
      Restore Procedure
             │
             ▼
      Disaster Recovery
             │
             ▼
      Business Continuity

بنابراین Backup یکی از اجزای مهم DR است، اما به‌تنهایی یک برنامه کامل Disaster Recovery محسوب نمی‌شود.

Backup در معماری High Availability

حتی اگر یک سیستم دارای High Availability باشد، همچنان به Backup نیاز دارد.

فرض کنید دو دیتابیس با Replication فعال هستند. اگر یک رکورد به اشتباه حذف شود و این حذف به Replica نیز منتقل شود، High Availability باعث جلوگیری از این خطای منطقی نشده است.

بنابراین در معماری‌های HA معمولاً باید چند لایه دفاع وجود داشته باشد:

• HA برای کاهش Downtime
• Replication برای Availability
• Backup برای Recovery
• PITR برای خطاهای منطقی
• Off-site Copy برای Site Failure
• Immutable/Offline Copy برای سناریوهای امنیتی

برای مطالعه بیشتر درباره این موضوع می‌توانید مقاله High Availability در MySQL و MariaDB با Galera Cluster را بخوانید.

Backup چه زمانی کافی نیست؟

Backup قرار نیست تمام مشکلات زیرساخت را حل کند.

اگر RTO بسیار پایین باشد، Restore کردن یک Backup چند ترابایتی ممکن است زمان زیادی ببرد. در چنین شرایطی باید از معماری‌هایی مانند Replication، Warm Standby یا Hot Standby نیز استفاده شود.

از طرف دیگر، اگر RPO بسیار پایین باشد، Backup روزانه کافی نخواهد بود و باید به سمت Continuous Backup، Transaction Log Backup یا Replication رفت.

بنابراین طراحی Backup باید بر اساس Business Requirement انجام شود، نه بر اساس اینکه کدام ابزار قابلیت‌های بیشتری دارد.

یک معماری حرفه‌ای Backup چگونه طراحی می‌شود؟

یک معماری نمونه می‌تواند به شکل زیر باشد:

                Production
                    │
          ┌─────────┴─────────┐
          │                   │
      Continuous          Scheduled
       Backup              Backup
          │                   │
          └─────────┬─────────┘
                    │
             Primary Repository
                    │
          ┌─────────┴─────────┐
          │                   │
       Off-site            Immutable
        Copy                 Copy
          │                   │
          └─────────┬─────────┘
                    │
              Restore Testing
                    │
                    ▼
             Recovery Runbook

این معماری را می‌توان بر اساس اندازه سازمان و نیاز RPO/RTO ساده‌تر یا پیچیده‌تر کرد.

چک‌لیست طراحی Backup حرفه‌ای

• ☐ تمام Workloadهای حیاتی شناسایی شده‌اند.
• ☐ RPO برای هر Workload مشخص است.
• ☐ RTO برای هر Workload مشخص است.
• ☐ Backup به صورت Automated اجرا می‌شود.
• ☐ Backup Repository از Production مستقل است.
• ☐ حداقل یک نسخه Off-site وجود دارد.
• ☐ برای داده‌های حساس Encryption فعال است.
• ☐ Backupهای مهم در برابر حذف یا تغییر محافظت می‌شوند.
• ☐ Retention Policy مشخص است.
• ☐ Backup Monitoring و Alerting وجود دارد.
• ☐ Restore Test به صورت دوره‌ای انجام می‌شود.
• ☐ Runbook برای Recovery مستند شده است.
• ☐ وابستگی‌های Application در Recovery شناسایی شده‌اند.
• ☐ Secretها و Configurationهای لازم قابل بازیابی هستند.
• ☐ فرآیند Recovery پس از تغییرات بزرگ Infrastructure دوباره تست می‌شود.

اشتباهات رایج در Backup

۱. «Backup داریم، پس مشکلی نداریم»

داشتن Backup بدون Restore Test به معنی داشتن Recovery قابل اطمینان نیست.

۲. نگهداری تمام Backupها روی همان Server

اگر Server از بین برود، Backup نیز ممکن است از بین برود.

۳. Backup روی همان Storage Production

این معماری در برابر برخی خرابی‌های Storage یا حملات مدیریتی آسیب‌پذیر است.

۴. نادیده گرفتن دیتابیس

کپی فایل‌های Application بدون توجه به Database ممکن است Recovery واقعی Application را غیرممکن کند.

۵. Backup گرفتن از همه چیز بدون Policy

این کار می‌تواند هزینه Storage را افزایش دهد و مدیریت Recovery Pointها را دشوار کند.

۶. نداشتن Off-site Backup

Backup داخل همان Data Center در برابر Disasterهای Site-Level محافظت کافی ایجاد نمی‌کند.

۷. دسترسی بیش از حد به Backup Repository

اگر تمام Administratorها بتوانند Backupها را حذف کنند، یک Credential Compromise می‌تواند کل زنجیره Recovery را تهدید کند.

۸. تست نکردن Recovery

یکی از مهم‌ترین Anti-Patternها این است که سازمان فقط موفقیت Backup Job را بررسی کند و هیچ‌وقت Restore واقعی انجام ندهد.

Backup و خدمات دواپس

Backup حرفه‌ای بخشی از خدمات دواپس و خدمات DevOps در یک زیرساخت مدرن است، زیرا فرآیند Backup نباید به یک فعالیت دستی و وابسته به یک Administrator تبدیل شود.

در یک معماری DevOps، می‌توان Backup را تا حد زیادی به شکل Policy as Code، Automation و Infrastructure as Code مدیریت کرد و وضعیت آن را مانند سایر اجزای Production پایش کرد.

در محیط‌های Kubernetes نیز می‌توان Backup را در فرآیندهای استاندارد Platform و Operations قرار داد تا ایجاد Backup، Retention، Monitoring و Restore Test به شکل قابل تکرار انجام شوند.

برای سازمان‌هایی که زیرساخت آن‌ها رشد کرده است، ترکیب Backup با Monitoring، S3 Storage، Disaster Recovery، High Availability و Business Continuity می‌تواند یک معماری کامل‌تر برای محافظت از سرویس‌ها ایجاد کند.

چگونه یک استراتژی Backup را از صفر طراحی کنیم؟

برای طراحی یک سیستم Backup حرفه‌ای، بهتر است مراحل زیر طی شود:

1. Inventory: تمام Applicationها، Databaseها، Storageها و سرویس‌های حیاتی شناسایی شوند.
2. Classification: داده‌ها بر اساس اهمیت و حساسیت دسته‌بندی شوند.
3. RPO/RTO: برای هر Workload اهداف Recovery مشخص شود.
4. Backup Policy: Frequency، Retention و Recovery Pointها تعریف شوند.
5. Architecture: Local، Off-site، Immutable و در صورت نیاز Offline Copy طراحی شود.
6. Security: Encryption، Access Control و Isolation پیاده‌سازی شود.
7. Automation: فرآیند Backup بدون وابستگی به اجرای دستی افراد انجام شود.
8. Monitoring: Failure، Capacity و Staleness پایش شوند.
9. Restore Test: Recovery به صورت دوره‌ای تست شود.
10. Runbook: فرآیند Recovery مستند و قابل اجرا باشد.
11. Review: پس از تغییرات مهم زیرساخت، Strategy دوباره بررسی شود.

جمع‌بندی

Backup حرفه‌ای صرفاً به معنی «هر شب از دیتابیس یک فایل بگیریم» نیست. یک Backup Strategy واقعی باید مشخص کند چه چیزی Backup می‌شود، هر چند وقت یک‌بار، کجا نگهداری می‌شود، چه کسی به آن دسترسی دارد، چقدر نگه داشته می‌شود و مهم‌تر از همه، چگونه و در چه مدت قابل بازیابی است.

مفاهیمی مانند RPO، RTO، 3-2-1، Immutable Backup، Off-site Backup، Snapshot، Incremental Backup، PITR و Restore Testing هر کدام بخشی از این معماری هستند و باید متناسب با نیاز واقعی سازمان انتخاب شوند.

مهم‌تر از همه، نباید Backup را جدا از Disaster Recovery، High Availability، Security و Business Continuity دید. هدف نهایی Backup این نیست که چند فایل در یک Storage داشته باشیم؛ هدف این است که در زمان وقوع یک Failure واقعی، بتوانیم داده و سرویس را با میزان قابل قبول Downtime و Data Loss به وضعیت عملیاتی بازگردانیم.

سؤالات متداول درباره Backup

آیا RAID همان Backup است؟

خیر. RAID عمدتاً برای تحمل خرابی Disk و افزایش Availability استفاده می‌شود و جایگزین Backup برای بازیابی اطلاعات حذف‌شده، خراب‌شده یا رمزگذاری‌شده نیست.

آیا Replication جای Backup را می‌گیرد؟

خیر. Replication تغییرات را به سیستم دیگر منتقل می‌کند و ممکن است خطاهای منطقی مانند حذف یا خراب شدن داده را نیز منتقل کند. Replication و Backup معمولاً باید در کنار یکدیگر استفاده شوند.

قانون 3-2-1 Backup چیست؟

به‌صورت کلی یعنی داشتن سه نسخه از داده، روی دو نوع Media یا محل نگهداری متفاوت، با حداقل یک نسخه خارج از محل اصلی.

هر چند وقت یک‌بار باید Backup بگیریم؟

فرکانس Backup باید از RPO مشخص شود. هرچه Data Loss قابل قبول کمتر باشد، Recovery Pointها باید با فاصله زمانی کوتاه‌تری ایجاد شوند.

آیا Cloud Backup کافی است؟

صرفاً قرار گرفتن Backup روی Cloud تضمین‌کننده Recovery نیست. باید Isolation، Access Control، Encryption، Retention، امکان Restore و در صورت نیاز Immutable و Off-site بودن نسخه‌ها بررسی شود.

آیا Backup باید رمزنگاری شود؟

برای داده‌های حساس، رمزنگاری Backup هم در زمان انتقال و هم در زمان نگهداری یکی از کنترل‌های مهم امنیتی است.

Restore Test هر چند وقت یک‌بار باید انجام شود؟

فرکانس آن به اهمیت Workload و RTO/RPO بستگی دارد، اما Restore Test باید بخشی از فرآیند عملیاتی مستمر باشد و پس از تغییرات مهم زیرساخت نیز دوباره بررسی شود.

آیا Backup به تنهایی برای Disaster Recovery کافی است؟

خیر. Backup یکی از اجزای اصلی DR است. برای Recovery واقعی باید فرآیند بازسازی زیرساخت، Application، Network، Database، Configuration و سایر Dependencyها نیز مشخص و تست شده باشند.

برای طراحی یک زیرساخت Backup و Recovery حرفه‌ای

آلتیمیت کلاد می‌تواند در طراحی و پیاده‌سازی معماری Backup، تعریف RPO/RTO، ایجاد Backup Repository، طراحی Off-site و Immutable Backup، اتوماسیون Backup، Monitoring و همچنین سناریوهای Disaster Recovery به سازمان‌ها کمک کند.

اگر زیرساخت شما به نقطه‌ای رسیده که از دست رفتن داده یا چند ساعت Downtime می‌تواند مستقیماً روی کسب‌وکار تأثیر بگذارد، زمان آن است که Backup را از یک Job ساده به یک Recovery Strategy واقعی تبدیل کنید.

برای بررسی زیرساخت و طراحی استراتژی Backup و Recovery با آلتیمیت کلاد در ارتباط باشید.