در سیستم‌های حیاتی (Mission-Critical Systems) مانند سامانه‌های بانکی، زیرساخت‌های پرداختی، پلتفرم‌های E-commerce بزرگ و سیستم‌های سلامت، قطعی پایگاه داده یا از دست رفتن داده‌ها (Data Loss) تنها یک مشکل فنی نیست؛ بلکه می‌تواند به خسارت‌های سنگین مالی، پیگردهای قانونی و نابودی برند منجر شود.

شاخص‌های کلیدی تصمیم‌گیری: RPO و RTO

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

                  زمان وقوع حادثه (Disaster)
                             │
  ◄──────────────────────────┼──────────────────────────►
            RPO              │            RTO
  (چقدر داده از دست می‌رود؟)  │ (چقدر زمان برای بازگشت نیاز است؟)

• RPO (Recovery Point Objective - نقطه مطلوب بازیابی): حداکثر میزان داده‌ای که کسب‌وکار می‌تواند از دست دادن آن را تحمل کند (بر حسب زمان). برای مثال، RPO برابر با ۵ دقیقه یعنی در صورت بروز حادثه، نباید بیش از ۵ دقیقه از آخرین داده‌های ذخیره‌شده از دست برود.

• RTO (Recovery Time Objective - زمان مطلوب بازیابی): حداکثر زمان مجاز برای بازگرداندن سیستم به حالت عملیاتی پس از وقوع حادثه.

سطح‌بندی سیستم‌ها بر اساس RPO و RTO

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

برای طراحی یک استراتژی جامع، شناخت نحوه کارکرد فیزیکی و منطقی انواع Backup ضروری است.

┌─────────────────────────────────────────────────────────┐
│                    Full Backup                          │ (یکشنبه)
└─────────────────────────────────────────────────────────┘
        │                            │
        ▼                            ▼
┌───────────────┐            ┌───────────────┐
│ Diff Backup   │ (دوشنبه)   │ Log Backup    │ (هر ۱۵ دقیقه)
└───────────────┘            └───────────────┘

۱. پشتیبان‌گیری کامل (Full Backup)

کپی کامل از تمام ساختارها، جداول، ایندکس‌ها و داده‌های پایگاه داده.

• مزایا: بازیابی ساده و یکپارچه.

• معایب: حجم بسیار بالا، فشار شدید روی I/O و پهنای باند، زمان‌بر بودن.

۲. پشتیبان‌گیری تفاضلی (Differential Backup)

ذخیره تمامی تغییراتی که از زمان آخرین Full Backup رخ داده است.

• مزایا: حجم کمتر نسبت به Full Backup، بازیابی سریع‌تر نسبت به Incremental.

• معایب: رشد حجم فایل پشتیبان به مرور زمان تا گرفتن Full Backup بعدی.

۳. پشتیبان‌گیری از Log / WAL (Transaction Log / Write-Ahead Log)

در پایگاه‌های داده رابطه‌ای (RDBMS)، هر تغییری ابتدا در Log نوشته می‌شود و سپس روی دیسک اعمال می‌گردد. پشتیبان‌گیری متوالی از این فایل‌های Log (مثلاً هر ۵ دقیقه)، امکان بازسازی ریزترین تغییرات را فراهم می‌کند.

• مزایا: دستیابی به RPO نزدیک به صفر و امکان بازیابی نقطه به زمان (Point-In-Time Recovery).

• معایب: وابستگی شدید به زنجیره کامل فایل‌های Log (اگر یک فایل خراب شود، زنجیره می‌شکند).

۴. اسنپ‌شات در سطح استوریج (Storage/Block-Level Snapshots)

استفاده از قابلیت‌های SAN Storage یا Cloud (مانند AWS EBS Snapshots یا LVM) برای گرفتن عکس لحظه‌ای از دیسک.

• نکته حیاتی: برای جلوگیری از Data Corruption، اسنپ‌شات باید Database-Consistent باشد (با فراخوانی دستوراتی مانند FLUSH TABLES WITH READ LOCK یا استفاده از VSS در ویندوز).

قابلیت بازیابی نقطه به زمان (Point-In-Time Recovery - PITR)

یکی از خطرناک‌ترین سناریوها در سیستم‌های حیاتی، خطای انسانی یا باگ نرم‌افزاری است (مانند اجرای اشتباه دستور DELETE یا UPDATE بدون شرط WHERE).

در این سناریوها، Replication کمکی نمی‌کند، زیرا دستور مخرب بلافاصله به Nodeهای دیگر نیز منتقل می‌شود!

[Full Backup 00:00] ---> [Log 01:00] ---> [Log 02:00] ---> [باگ نرم‌افزاری 02:14] ---> [Log 03:00]
                                                                │
                                              هدف بازگردانی: 02:13:59

نحوه عملکرد PITR

1. بازگردانی آخرین Full Backup پیش از زمان حادثه.

2. اعمال آخرین Differential Backup (در صورت وجود).

3. اعمال زنجیره‌وار فایل‌های Transaction Log / WAL تا دقیقا یک ثانیه (یا یک Transaction ID مشخص) پیش از وقوع خطا.

معماری مدرن پشتیبان‌گیری: قانون 0-1-1-2-3

قانون کلاسیک 3-2-1 در سیستم‌های حیاتی امروزی ارتقا یافته و به قانون 3-2-1-1-0 تبدیل شده است:

  ┌─────────────────────────────────────────────────────────────┐
  │                    3 کپی از داده‌ها                          │
  └──────────────────────────────┬──────────────────────────────┘
                                 │
         ┌───────────────────────┴───────────────────────┐
         ▼                                               ▼
┌─────────────────┐                             ┌─────────────────┐
│  2 رسانه متفاوت  │                             │ 1 نسخه Offsite  │
│ (Disk / Object) │                             │ (کلاود/دیتاسنتر2)│
└────────┬────────┘                             └────────┬────────┘
         │                                               │
         ▼                                               ▼
┌─────────────────┐                             ┌─────────────────┐
│  1 نسخه غیرقابل  │                             │ 0 خطا در تست    │
│  تغییر (WORM)   │                             │  بازیابی خودکار │
└─────────────────┘                             └─────────────────┘

1. ۳ کپی از داده‌ها: یک نسخه اصلی + دو نسخه پشتیبان.

2. ۲ رسانه متفاوت: ذخیره روی ابزارهای ذخیره‌سازی مختلف (مثلاً NVMe Local + Object Storage / S3).

3. ۱ نسخه خارج از سایت (Offsite): نگهداری حداقل یک نسخه در دیتاسنتر یا منطقه جغرافیایی متفاوت برای مقابله با حوادث فیزیکی (زgroup، آتش‌سوزی).

4. ۱ نسخه غیرقابل تغییر و ایزوله (Immutable / Air-Gapped): ذخیره به صورت WORM (Write Once, Read Many) جهت جلوگیری از حذف یا رمزنگاری توسط باج‌افزارها (Ransomware).

5. ۰ خطا در تست بازیابی (Zero Errors): تایید ۱۰۰٪ سلامت فایل‌ها با تست خودکار بازگردانی.

تفکیک معماری High Availability (HA) از Disaster Recovery (DR)

اشتباه رایجی که بسیاری از تیم‌ها مرتکب می‌شوند، یکسان فرض کردن Replication با Backup است.

اصل طلایی: Replication ابزار پایداری و دسترسی‌پذیری (HA) است، نه ابزار بازیابی از حادثه (Backup/DR). اگر دیتایی به اشتباه پاک شود، این پاک شدن بر روی تمام Replicas کپی خواهد شد!

┌─────────────────────────────────────────────────────────────────────────┐
│                               Primary Node                              │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │
           ┌─────────────────────────┴─────────────────────────┐
           ▼                                                   ▼
┌─────────────────────┐                             ┌─────────────────────┐
│ Synchronous Replica │                             │ Backup & WAL Engine │
│       (HA)          │                             │  (PITR / Disaster)  │
└─────────────────────┘                             └─────────────────────┘

• کلاسترینگ و HA (مانند PostgreSQL Patroni / SQL Server AlwaysOn): سیستم را در صورت خرابی سخت‌افزاری Node اصلی زنده نگه می‌دارد (RTO نزدیک به صفر).

• پشتیبان‌گیری (Backup): سیستم را در برابر فساد داده‌ها (Data Corruption)، خطای انسانی و خرابی کلی دیتاسنتر محافظت می‌کند.

امنیت، رمزنگاری و مقابله با باج‌افزارها

فایل‌های پشتیبان یکی از هدف‌های اصلی هکرها هستند. اگر مهاجم به فایل‌های پشتیبان دسترسی پیدا کند، می‌تواند بدون نیاز به نفوذ به دیتاسنتر اصلی، داده‌ها را بدست آورد یا آن‌ها را نابود کند.

الزامات امنیتی فایل‌های پشتیبان:

1. رمزنگاری در حال حرکت و سکون (Encryption in Transit & at Rest):

   • استفاده از الگوریتم‌های استاندارد نظیر AES-256 برای فایل‌های ذخیره‌شده.

   • انتقال فایل‌ها صرفاً از طریق پروتکل‌های امن (TLS 1.3, SSH/SFTP).

2. مدیریت کلیدها (KMS): کلیدهای رمزنگاری نباید در همان سرور پشتیبان‌گیری یا دیتابیس ذخیره شوند.

3. اصل حداقل دسترسی (Least Privilege): سرویس پشتیبان‌گیری نباید با دسترسی root یا sysadmin اجرا شود.

4. Object Locking & Immutability: در Object Storageها (مانند AWS S3 یا MinIO) با فعال‌سازی S3 Object Lock در حالت Compliance Mode، حتی مدیر ارشد سیستم (Root User) نیز نمی‌تواند فایل پشتیبان را تا زمان تعیین‌شده حذف یا ویرایش کند.

پارادایم «پشتیبان‌گیری شروپینگراف»: تست خودکار بازیابی

پشتیبان‌گیری تا زمانی که بازیابی و تست نشده باشد، در حالت نامشخص (هم سالم و هم خراب) قرار دارد!

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

┌──────────────┐     ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│ Backup File  │ ──► │ Spawn Temp   │ ──► │ Execute      │ ──► │ Run Data     │
│ Created      │     │ Container/VM │     │ Restore      │     │ Integrity    │
└──────────────┘     └──────────────┘     └──────────────┘     │ Checks       │
                                                               └──────┬───────┘
                                                                      │
                                                                      ▼
                                                               ┌──────────────┐
                                                               │ Destroy Temp │
                                                               │ Environment  │
                                                               └──────────────┘

مراحل یک Pipeline خودکار برای تایید پشتیبان‌گیری:

1. دریافت رویداد (Event) ایجاد فایل پشتیبان جدید.

2. ایجاد خودکار یک محیط ایزوله موقت (مثلاً یک Docker Container یا Ephemeral VM).

3. اجرای فرآیند Restore فایل پشتیبان روی محیط موقت.

4. اجرای اسکریپت‌های صحت سنجی داده (Data Integrity Tests):

   • کنترل فیلدهای کلیدی و تعداد رکوردهای جداول اصلی.

   • اجرای DBCC CHECKDB در SQL Server یا amcheck در PostgreSQL.

5. ثبت گزارش موفقیت/خطا در سیستم‌های مانیتورینگ (Prometheus/Grafana) و ارسال هشدار در صورت بروز مشکل.

6. انهدام (Destroy) محیط موقت.

بررسی پیاده‌سازی در موتورهای رایج پایگاه داده

الف) PostgreSQL

در پلتفرم‌های حیاتی مبتنی بر PostgreSQL، ابزارهای سنتـی مانند pg_dump به دلیل سنگین بودن و عدم پشتیبانی مناسب از PITR در حجم‌های بالا ناکارآمد هستند.

• ابزارهای استاندارد صنعتی: استفاده از pgBackRest یا WAL-G.

• مکانیزم:

  • گرفتن Physical Backup به‌صورت موازی (Multi-threaded).

  • ارسال متوالی و فشرده‌شده فایل‌های WAL به Object Storage.

  • پشتیبانی از Block-level incremental backups.

ب) Microsoft SQL Server

در محیط‌های Enterprise مبتنی بر SQL Server:

• تنظیم Recovery Model: باید حتما روی FULL تنظیم شده باشد.

• استراتژی زمان‌بندی استاندارد:

  • Full Backup: هفته‌ای یک بار (در ساعات کم‌ترافیک).

  • Differential Backup: روزانه یک بار.

  • Transaction Log Backup: هر ۵ تا ۱۵ دقیقه.

• قابلیت‌های پیشرفته: استفاده از CHECKSUM در دستورات پشتیبان‌گیری برای تشخیص زودهنگام فساد دیسک.

-- نمونه دستور استاندار پشتیبان‌گیری در SQL Server با کنترل صحت
BACKUP DATABASE [MissionCriticalDB]
TO DISK = N'S:\Backups\MissionCriticalDB_Full.bak'
WITH CHECKSUM, COMPRESSION, STATS = 10;

چک‌لیست نهایی ارزیابی استراتژی پشتیبان‌گیری

اگر مسئولیت مدیریت داده‌های یک سیستم حیاتی را بر عهده دارید، پاسخ به سوالات زیر سلامت استراتژی شما را مشخص می‌کند:

• [ ] آیا شاخص‌های RPO و RTO سیستم به صورت مکتوب و با تایید ذینفعان کسب‌وکار تعریف شده‌اند؟

• [ ] آیا قابلیت Point-In-Time Recovery (PITR) فعال و تست‌شده است؟

• [ ] آیا حداقل یک نسخه از پشتیبان‌ها به صورت Immutable (غیرقابل تغییر/WORM) ذخیره می‌شود؟

• [ ] آیا فرآیند بازگردانی پشتیبان‌ها به صورت خودکار و روزانه/هفتگی تست می‌شود؟

• [ ] آیا کلیدهای رمزنگاری فایل‌های پشتیبان در مکانی خارج از سرور پایگاه داده نگهداری می‌شوند؟

• [ ] آیا قطع کامل یک دیتاسنتر (Site Failure) در سناریوهای Disaster Recovery تمرین شده است؟

طراحی استراتژی پشتیبان‌گیری و بازیابی در سیستم‌های حیاتی، یک فرآیند ایستا و یک‌باره نیست، بلکه یک چرخه مداوم از نگهداری، تست و بهینه‌سازی است. اتکا به روش‌های سنتی و عدم تست مداوم سناریوهای بازیابی، ریسک‌های جبران‌ناپذیری را به همراه دارد. با به‌کارگیری الگوی 3-2-1-1-0، اتوماسیون کامل تست‌های بازیابی و پیاده‌سازی مکانیزم‌های مدرن مانند PITR، می‌توان پایداری و بقای داده‌های سیستم را در سخت‌ترین حوادث تضمین کرد.