Categories
Database Backup

** Discover the hidden dangers of DIY database backup scripts. Learn why custom Bash scripts fail in production, the risks of logical dumps, and how to secure your data with enterprise solutions.

هر مدیر پایگاه داده (DBA) و مهندس سیستم، در مقطعی از دوران حرفه‌ای خود، یک اسکریپت شل (Shell Script) سفارشی برای پشتیبان‌گیری از پایگاه داده نوشته است. این عملاً یک آیین گذر است. در مراحل اولیه یک پروژه، یک cron job ساده که mysqldump یا pg_dump را اجرا کرده و خروجی آن را به gzip می‌فرستد، راهکاری ظریف، سبک و مقرون‌به‌صرفه به نظر می‌رسد.

با این حال، با مقیاس‌پذیر شدن زیرساخت، افزایش حجم داده‌ها و سخت‌گیرانه‌تر شدن توافق‌نامه‌های سطح خدمات (SLA) برای زمان در دسترس بودن، آن اسکریپت ۱۰ خطی Bash به آرامی به یک بمب ساعتی تبدیل می‌شود. محیط‌های عملیاتی (Production) نیازمند در دسترس بودن بالا، اهداف نقطه بازیابی (RPO) دقیق و اهداف زمان بازیابی (RTO) سریع هستند. تکیه بر اسکریپت‌های پشتیبان‌گیری دست‌ساز (DIY) در این محیط‌ها، خطرات جدی مربوط به یکپارچگی داده‌ها، شکست‌های خاموش، آسیب‌پذیری‌های امنیتی و فرآیندهای بازیابی غیرقابل مدیریت را به همراه دارد.

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

توهم سادگی: کالبدشکافی اسکریپت کلاسیک دست‌ساز

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

#!/bin/bash
# اسکریپت ساده پشتیبان‌گیری MySQL دست‌ساز
BACKUP_DIR="/mnt/backups"
DATE=$(date +%F)
DB_USER="admin"
DB_PASS="SuperSecret123!"

mysqldump -u $DB_USER -p$DB_PASS my_database | gzip > $BACKUP_DIR/mydb_$DATE.sql.gz

# حذف پشتیبان‌های قدیمی‌تر از ۳۰ روز
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;

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

خطر ۱: شکست‌های خاموش و تله پایپ (Pipe Trap)

یکی از موذیانه‌ترین خطرات اسکریپت‌های دست‌ساز، شکست خاموش است. در اسکریپت بالا، دستور mysqldump مستقیماً از طریق پایپ (|) به gzip ارسال می‌شود.

در Bash، وضعیت خروج یک خط لوله (pipeline)، وضعیت خروج آخرین دستور در آن خط لوله است. اگر سرور پایگاه داده در میانه عملیات دامپ، با کمبود حافظه مواجه شود، اتصال قطع شود یا به یک جدول قفل‌شده برخورد کند، mysqldump شکست می‌خورد و خطا می‌دهد. با این حال، gzip خروجی ناقصی که دریافت کرده را با موفقیت فشرده می‌کند و با کد وضعیت 0 (موفقیت) خارج می‌شود.

سیستم مانیتورینگ شما که کد خروج cron job را بررسی می‌کند، یک پشتیبان‌گیری موفق را گزارش خواهد کرد. شما یک فایل .gz معتبر روی دیسک خواهید داشت، اما داخل آن یک فایل SQL ناقص و بی‌فایده است. شما تا زمانی که سعی نکنید یک بازیابی حیاتی انجام دهید، متوجه این موضوع نخواهید شد.

کاهش اثرات (و محدودیت‌های آن)

مهندسان اغلب سعی می‌کنند با فعال کردن مدیریت خطای سخت‌گیرانه در Bash، این مشکل را وصله کنند:

set -e
set -o pipefail

اگرچه set -o pipefail تضمین می‌کند که اگر هر دستوری در خط لوله شکست بخورد، اسکریپت متوقف شود، اما همچنان نیازمند آن است که مکانیزم‌های قوی هشداردهی، ثبت وقایع (Logging) و تلاش مجدد (Retry) را پیرامون اسکریپت بسازید. وقتی یک خطای شبکه گذرا باعث شکست در ساعت ۲ بامداد می‌شود، یک اسکریپت دست‌ساز به سادگی متوقف می‌شود. پلتفرم‌های سازمانی این خطاهای گذرا را با تلاش‌های مجدد هوشمند و نمایی (Exponential Backoff) مدیریت می‌کنند.

خطر ۲: یکپارچگی داده‌ها و کابوس‌های قفل‌گذاری

اسکریپت‌های دست‌ساز به شدت به پشتیبان‌گیری‌های منطقی (mysqldump، pg_dump) متکی هستند. پشتیبان‌گیری‌های منطقی داده‌ها را با اجرای دستورات SELECT در تمام جداول استخراج می‌کنند. در یک پایگاه داده عملیاتی با تراکنش‌های بالا، داده‌ها دائماً در حال تغییر هستند. اگر یک اسکریپت ۴۵ دقیقه زمان ببرد تا از یک پایگاه داده ۱۰۰ گیگابایتی دامپ بگیرد، داده‌های ابتدای دامپ ۴۵ دقیقه قدیمی‌تر از داده‌های انتهای آن خواهند بود که این امر نقض انطباق با ACID است.

یکپارچگی تراکنشی MySQL

برای دستیابی به یک اسنپ‌شات منسجم در MySQL با استفاده از InnoDB، باید پرچم‌های خاصی را ارسال کنید:

mysqldump --single-transaction --quick --routines --events -u user -p db > dump.sql

پرچم --single-transaction سطح ایزولاسیون را روی REPEATABLE READ تنظیم کرده و قبل از دامپ گرفتن، یک تراکنش را شروع می‌کند. با این حال، اگر پایگاه داده شما همچنان شامل جداول قدیمی MyISAM باشد، این پرچم از قفل شدن آن‌ها جلوگیری نمی‌کند و ممکن است ترافیک خواندن/نوشتن عملیاتی را در حین اجرای پشتیبان‌گیری متوقف کند. علاوه بر این، هر دستور ALTER TABLE، DROP TABLE یا RENAME TABLE که توسط توسعه‌دهندگان در حین پشتیبان‌گیری اجرا شود، اسنپ‌شات REPEATABLE READ را می‌شکند و باعث شکست دامپ می‌شود.

PostgreSQL و آرشیو کردن WAL

برای PostgreSQL، ابزار pg_dump پشتیبان‌گیری‌های منطقی منسجم ارائه می‌دهد، اما پشتیبان‌گیری‌های منطقی به تنهایی نمی‌توانند بازیابی در لحظه (PITR) را فراهم کنند. اگر پایگاه داده شما در ساعت ۴ بعدازظهر کرش کند و آخرین اسکریپت کرون شما در نیمه‌شب اجرا شده باشد، شما ۱۶ ساعت داده را از دست می‌دهید.

دستیابی به PITR نیازمند آرشیو کردن مداوم لاگ‌های پیش‌نویس (Write-Ahead Logs یا WAL) است. نوشتن یک اسکریپت دست‌ساز برای مدیریت ایمن archive_command به طرز بدنامی دشوار است.

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /mnt/wal_archive/%f && cp %p /mnt/wal_archive/%f'

اگر فضای ذخیره‌سازی مقصد (/mnt/wal_archive/) پر شود یا در دسترس نباشد، archive_command شکست می‌خورد. سپس PostgreSQL فایل‌های WAL را به صورت محلی ذخیره می‌کند تا زمانی که دیسک اصلی پر شود و باعث از کار افتادن کامل پایگاه داده گردد. اسکریپت‌های دست‌ساز به ندرت دارای تله‌متری لازم برای نظارت بر تجمع WAL و هشدار به مدیران قبل از وقوع قطعی هستند.

خطر ۳: رولت نگهداری (Retention Roulette)

به دستور نگهداری در اسکریپت اولیه ما نگاه کنید:

find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;

این یک رویداد فاجعه‌بار از دست دادن داده است که در انتظار وقوع است. سناریویی را تصور کنید که در آن یک تغییر پیکربندی، احراز هویت mysqldump را مختل می‌کند. اسکریپت در ایجاد پشتیبان‌های جدید شکست می‌خورد، اما دستور find هر شب به اجرای خود ادامه می‌دهد و با وظیفه‌شناسی فایل‌های قدیمی‌تر از ۳۰ روز را حذف می‌کند.

پس از ۳۰ روز شکست خاموش در پشتیبان‌گیری، دستور find آخرین پشتیبان سالم باقی‌مانده شما را حذف خواهد کرد. اکنون شما هیچ پشتیبانی ندارید.

نرم‌افزارهای پشتیبان‌گیری سازمانی مانند CloudSave از سیاست‌های نگهداری وضعیت‌مند (Stateful) استفاده می‌کنند. این نرم‌افزار تفاوت بین «حذف پشتیبان‌های قدیمی‌تر از ۳۰ روز» و «اطمینان از وجود حداقل ۳۰ نقطه بازیابی موفق قبل از پاکسازی داده‌های قدیمی» را درک می‌کند.

خطر ۴: نقاط کور امنیتی، رمزنگاری و انطباق

در عصر باج‌افزارها و چارچوب‌های انطباق سخت‌گیرانه (GDPR، HIPAA، SOC 2)، پشتیبان‌ها هدف اصلی هستند. اسکریپت‌های دست‌ساز اغلب بهترین شیوه‌های امنیتی را نقض می‌کنند:

  1. اعتبارنامه‌های سخت‌کد شده: ذخیره رمزهای عبور پایگاه داده در اسکریپت‌های متنی ساده یا تعاریف کرون، یک ریسک امنیتی بزرگ است. اگرچه ابزارهایی مانند mysql_config_editor در MySQL یا فایل .pgpass در PostgreSQL این مشکل را کاهش می‌دهند، اما همچنان نیازمند مدیریت فایل‌های کلید محلی روی سرور هستند.
  2. عدم رمزنگاری در حالت سکون (At Rest): دامپ کردن SQL خام روی دیسک، اطلاعات حساس PII/PHI را در معرض خطر قرار می‌دهد.
  3. خط لوله‌های رمزنگاری پیچیده: تلاش برای رمزنگاری پشتیبان‌ها در لحظه با استفاده از GPG، سربار پردازشی شدید و پیچیدگی‌های مدیریت کلید ایجاد می‌کند.
# یک خط لوله پشتیبان‌گیری رمزنگاری‌شده دست‌ساز
pg_dump mydb | gzip | gpg --symmetric --cipher-algo AES256 --passphrase-file /etc/keys/backup.key > backup.sql.gz.gpg

اگر سرور به خطر بیفتد، مهاجم به هر دو فایل پشتیبان رمزنگاری‌شده و فایل /etc/keys/backup.key دسترسی پیدا می‌کند و رمزنگاری را بی‌اثر می‌سازد. علاوه بر این، اگر مدیر پایگاه داده‌ای که کلید GPG را تولید کرده شرکت را ترک کند و کلید گم شود، پشتیبان‌ها غیرقابل بازیابی خواهند بود.

خطر ۵: واقعیت RTO (بازیابی سخت‌تر از پشتیبان‌گیری است)

آزمون نهایی یک پشتیبان، بازیابی آن است. پشتیبان‌های منطقی تولید شده توسط اسکریپت‌های دست‌ساز به کندی بازیابی می‌شوند. ایجاد یک دامپ SQL پانصد گیگابایتی ممکن است ۱۵ دقیقه طول بکشد، اما بازیابی آن نیازمند این است که موتور پایگاه داده، SQL را تجزیه کند، ایندکس‌ها را بازسازی کند و محدودیت‌ها را دوباره محاسبه نماید. این فرآیند می‌تواند ساعت‌ها یا حتی روزها طول بکشد و RTO شما را نابود کند.

برای پایگاه‌های داده بزرگ عملیاتی، پشتیبان‌گیری‌های فیزیکی (کپی کردن فایل‌های داده واقعی) الزامی است. اگرچه ابزارهایی مانند Percona XtraBackup یا pg_basebackup وجود دارند، اما قرار دادن آن‌ها در اسکریپت‌های Bash دست‌ساز بسیار پیچیده است. شما باید اسنپ‌شات‌های LVM را مدیریت کنید، سیستم فایل را ساکن (Quiesce) کنید و اطمینان حاصل کنید که پشتیبان بدون اشباع کردن رابط شبکه به خارج از سایت منتقل می‌شود.

تله اسنپ‌شات LVM

بسیاری از مهندسان تلاش می‌کنند با استفاده از اسنپ‌شات‌های LVM، پشتیبان‌گیری فیزیکی «بدون توقف» انجام دهند:

# ایجاد یک اسنپ‌شات
lvcreate --size 20G --snapshot --name db_snap /dev/vg0/db_vol

# مونت کردن و کپی
mount /dev/vg0/db_snap /mnt/snap
tar -czf /backups/db_physical.tar.gz /mnt/snap/mysql

اگر پایگاه داده با جهش ناگهانی در I/O نوشتن مواجه شود، اسنپ‌شات ۲۰ گیگابایتی LVM می‌تواند فوراً پر شود. وقتی یک اسنپ‌شات LVM پر می‌شود، نامعتبر شده و پشتیبان‌گیری شکست می‌خورد. بدتر اینکه، اسنپ‌شات‌های LVM که به شدت استفاده می‌شوند، می‌توانند عملکرد I/O حجم اصلی پایگاه داده را به شدت کاهش دهند و باعث جهش در تأخیر برنامه شوند.

گذار به محافظت در سطح سازمانی

گذار از اسکریپت‌های دست‌ساز به یک پلتفرم سازمانی، یک نقطه عطف بلوغ حیاتی برای هر تیم زیرساختی است. هدف این است که از «امیدواری به اجرای اسکریپت» به داشتن اثبات رمزنگاری‌شده از قابلیت بازیابی برسیم.

پلتفرم‌هایی مانند CloudSave به‌طور خاص برای حذف نقاط کور اسکریپت‌نویسی دست‌ساز مهندسی شده‌اند. با استقرار عامل‌های (Agents) آگاه از برنامه، CloudSave مستقیماً با APIهای پایگاه داده (MySQL، PostgreSQL، MS SQL، Oracle) تعامل برقرار می‌کند تا پشتیبان‌گیری‌های فیزیکی و منطقی منسجم را بدون قفل کردن جداول یا کاهش عملکرد، هماهنگ کند.

مزایای کلیدی کنار گذاشتن اسکریپت‌ها:

  1. تأیید خودکار: پلتفرم‌های مدرن فقط پشتیبان نمی‌گیرند؛ آن‌ها پشتیبان‌ها را تست می‌کنند. CloudSave می‌تواند به‌طور خودکار یک نمونه پایگاه داده موقت را بالا بیاورد، پشتیبان را بازیابی کند، بررسی‌های یکپارچگی (مانند DBCC CHECKDB) را اجرا کند و سپس آن را حذف نماید، که گزارشی تأییدشده مبنی بر قابل استفاده بودن پشتیبان ارائه می‌دهد.
  2. ذخیره‌سازی تغییرناپذیر (Immutable): برای مبارزه با باج‌افزارها، پشتیبان‌ها باید تغییرناپذیر باشند. اسکریپت‌های دست‌ساز نمی‌توانند به راحتی روی ذخیره‌سازی WORM (یک بار نوشتن، بارها خواندن) بنویسند. راهکارهای سازمانی به‌طور بومی با S3 Object Lock و ذخیره‌سازی ابری تغییرناپذیر ادغام می‌شوند و تضمین می‌کنند که حتی اگر سرور کاملاً به خطر بیفتد، پشتیبان‌ها توسط مهاجم قابل حذف یا رمزنگاری نباشند.
  3. ساده‌سازی PITR: به جای چسباندن دستی یک پشتیبان پایه و صدها فایل WAL با استفاده از پارامترهای پیچیده recovery.conf یا postgresql.auto.conf، پلتفرم‌ها یک جدول زمانی بصری ارائه می‌دهند. شما به سادگی دقیقه‌ای که می‌خواهید به آن بازیابی کنید را انتخاب می‌کنید و نرم‌افزار به‌طور خودکار پخش مجدد لاگ‌ها را مدیریت می‌کند.
  4. حذف داده‌های تکراری (Deduplication) و فشرده‌سازی: اسکریپت‌های دست‌ساز به gzip متکی هستند که هر فایل را به‌طور جداگانه فشرده می‌کند. نرم‌افزارهای پشتیبان‌گیری سازمانی از حذف داده‌های تکراری در سطح بلوک جهانی استفاده می‌کنند که هزینه‌های ذخیره‌سازی و پهنای باند شبکه را هنگام انتقال پشتیبان‌ها به خارج از سایت به شدت کاهش می‌دهد.

نتیجه‌گیری

نوشتن یک اسکریپت Bash سفارشی برای پشتیبان‌گیری از یک پایگاه داده آسان است. نوشتن اسکریپتی که شکست‌های خاموش خط لوله را مدیریت کند، یکپارچگی ACID را تضمین نماید، کلیدهای رمزنگاری را به‌طور ایمن مدیریت کند، از دست رفتن داده‌ها بر اساس سیاست نگهداری را جلوگیری کند و SLAهای سخت‌گیرانه RTO/RPO را تضمین نماید، تقریباً غیرممکن است.

در محیط‌های عملیاتی، پایگاه داده حیاتی‌ترین دارایی کسب‌وکار است. برخورد با محافظت از آن به عنوان یک پروژه جانبی که توسط چند صد خط اسکریپت شل نگهداری می‌شود، ریسکی است که هیچ سازمانی نمی‌تواند بپذیرد. با حسابرسی استراتژی‌های فعلی پشتیبان‌گیری، درک محدودیت‌های دامپ‌های منطقی و مهاجرت به پلتفرم‌های قوی و خودکار مانند CloudSave، تیم‌های DevOps و DBA می‌توانند «فاکتور اتوبوس» (وابستگی به یک فرد) اسکریپت‌های سفارشی را حذف کرده و اطمینان حاصل کنند که داده‌هایشان واقعاً تاب‌آور است.

دسته‌ها