بهترین بکاپ یک ابزار یا فایل ZIP نیست؛ سیستمی است که با میزان داده قابل‌از‌دست‌رفتن و زمان قابل‌قبول بازیابی کسب‌وکار هماهنگ باشد و restore آن قبلاً آزموده شده باشد. کپی روی همان دیسک، snapshot تنها و jobی که فقط «موفق» ثبت می‌شود، در خرابی واقعی تضمین بازیابی نیستند.
پاسخ سریع: ابتدا RPO و RTO هر سرویس را تعیین کنید، سپس دیتابیس، فایل کاربر، config و secret لازم را به‌صورت سازگار backup بگیرید. نسخه‌ای رمزنگاری‌شده خارج از همان سرور و ترجیحاً مرز حساب نگه دارید، retention و immutability تعریف کنید و restore دوره‌ای را در محیط جدا با اندازه‌گیری زمان انجام دهید.
RPO و RTO را قبل از ابزار مشخص کنید
RPO بیشترین بازه داده‌ای است که از دست رفتنش قابل‌قبول است. RTO زمان هدف برای بازگشت سرویس است. فروشگاهی با سفارش پیوسته ممکن است RPO بسیار کوتاه بخواهد؛ سایت معرفی شاید روزانه کافی باشد. این تصمیم کسب‌وکاری است و هزینه storage، replication و عملیات را تعیین می‌کند.
چه چیزهایی باید Backup شوند؟
- دیتابیس و نقش‌ها/extensionهای لازم برای بازیابی
- فایل‌های آپلود و داده کاربر
- config برنامه، proxy، firewall و scheduler
- فهرست نسخه image/package و manifest deployment
- certificate و secretهای لازم با حفاظت بیشتر
- مستندات restore، DNS و dependencyها
- کلید رمزگشایی در محل جدا و قابل‌دسترسی
cache، artifact قابل‌ساخت و dependency قابل‌دانلود شاید نیاز به backup نداشته باشند، اما این تصمیم باید مستند باشد. اگر build قدیمی دیگر در registry موجود نیست، rollback صرفاً با source code ممکن است کند یا غیرقابل‌تکرار باشد.
Backup سازگار با برنامه
کپی فایل‌های دیتابیس در حال اجرا بدون روش پشتیبانی‌شده ممکن است ناسازگار باشد. از ابزار رسمی database engine یا snapshot هماهنگ با flush/quiesce استفاده کنید. فایل upload و رکورد دیتابیس باید تا حد ممکن از یک نقطه زمانی منطقی باشند؛ وگرنه restore می‌تواند به فایل مفقود یا رکورد بدون فایل برسد.
Logical Backup و Physical Backup
logical dump قابل‌انتقال و برای بازیابی انتخابی مفید است، اما روی دیتابیس بزرگ زمان و منابع می‌خواهد. physical backup سریع‌تر یا مناسب PITR است، ولی به نسخه، layout و روش engine حساس‌تر است. بسیاری از معماری‌ها برای اهداف متفاوت هر دو را نگه می‌دارند؛ یکی جای دیگری را مطلقاً نمی‌گیرد.
Snapshot چه کاری می‌کند؟
snapshot volume بازیابی سریع block-level می‌دهد، اما اگر بدون هماهنگی از دیتابیس گرفته شود ممکن است فقط crash-consistent باشد. snapshot در همان account/provider نیز در حذف حساب یا رخداد منطقه‌ای آسیب‌پذیر است. آن را یک لایه recovery بدانید، نه تنها backup.
اصل چند نسخه و چند Failure Domain
چند نسخه با retention متفاوت نگه دارید و حداقل یک کپی را خارج از host و failure domain اصلی قرار دهید. جداسازی account، region یا media به threat model وابسته است. هدف این است که خرابی disk، حذف اشتباه، compromise credential یا مشکل provider همه نسخه‌ها را هم‌زمان از بین نبرد.
Offline و Immutable
backupی که production credential امکان حذف یا رمزگذاری آن را دارد در ransomware یا compromise مقاوم نیست. object lock، نسخه غیرقابل‌تغییر یا جداسازی credential می‌تواند مقاومت را بالا ببرد. immutability بدون expiration هزینه storage را بی‌نهایت می‌کند؛ retention و legal hold باید طراحی شوند.
رمزنگاری و مدیریت کلید
داده باید هنگام انتقال و نگهداری محافظت شود. کلید رمزگشایی را کنار backup با همان credential نگذارید. rotation، دسترسی اضطراری و تست decrypt لازم است. رمزنگاری بدون بازیابی کلید، backup را غیرقابل‌استفاده می‌کند؛ نگهداری چندنسخه‌ای کلید و audit دسترسی اهمیت دارد.
Retention چندلایه
نسخه‌های نزدیک برای خطای اخیر و نسخه‌های دورتر برای کشف دیرهنگام corruption یا حذف لازم‌اند. retention باید با RPO، قانون، هزینه و نرخ تغییر هماهنگ شود. حذف خودکار را روی prefix یا bucket اشتباه آزمایش نکنید؛ policy را در محیط جدا و با گزارش inventory بررسی کنید.
Incremental و Full
incremental فضای کمتر و RPO کوتاه‌تر می‌دهد، اما restore به زنجیره و catalog وابسته است. full مستقل ساده‌تر اما پرهزینه‌تر است. طراحی باید طول زنجیره، زمان restore، integrity و availability metadata را بسنجد. deduplication نیز به ابزار و threat model وابسته است.
بکاپ Docker و Volume
backup image جای volume داده نیست و export container نیز لزوماً داده mountشده را شامل نمی‌شود. هر volume را به owner و نوع داده نسبت دهید. برای دیتابیس داخل container همچنان consistency ابزار دیتابیس لازم است. Compose file، env template و secret reference را جدا نگه دارید؛ secret واقعی حفاظت بیشتری می‌خواهد.
بکاپ Config بدون افشای Secret
config غیرحساس را می‌توان نسخه‌دار کرد، اما password و private key نباید وارد repository عمومی شود. secret store باید export/recovery کنترل‌شده داشته باشد. صرف داشتن فایل برنامه بدون credential و DNS موردنیاز، recovery کامل ایجاد نمی‌کند.
تأثیر Backup روی Production
dump، compression و upload CPU، RAM، I/O و network مصرف می‌کنند. job را در ساعات مناسب زمان‌بندی و منابع را محدود کنید، اما پنجره backup نباید RPO را نقض کند. metric latency و queue هنگام backup را بررسی کنید. اگر backup باعث 504 می‌شود، معماری یا منابع نیاز به اصلاح دارد.
چرا بکاپ Disk را پر می‌کند؟
نوشتن backup محلی پیش از upload، failure انتقال و retention ناقص می‌تواند فایل‌ها را انباشته کند. فضای موقت و بدترین حجم را ظرفیت‌سنجی کنید. پس از upload موفق و verifyشده cleanup طبق policy انجام شود. راهنمای پر شدن Disk سرور روش تشخیص امن را توضیح می‌دهد.
Verification با Restore فرق دارد
checksum سالم نشان می‌دهد فایل از زمان محاسبه تغییر نکرده، اما ثابت نمی‌کند dump منطقی قابل restore یا برنامه قابل اجراست. verification format، decrypt، decompression و catalog لازم است؛ سپس restore واقعی در محیط ایزوله باید schema، فایل و journey برنامه را آزمون کند.
Restore Test حرفه‌ای
- یک recovery point واقعی انتخاب کنید.
- محیط جدا با شبکه و credential غیرproduction بسازید.
- کلید و artifact را از مسیر مستند بازیابی کنید.
- دیتابیس، فایل و config را با ترتیب runbook restore کنید.
- integrity و چند journey اصلی را smoke test کنید.
- زمان هر مرحله و مانع‌ها را ثبت کنید.
- محیط آزمایش و داده حساس را امن پاک‌سازی کنید.
restore روی production برای «تست» خطرناک است. محیط بازیابی نباید ایمیل، پیامک یا callback واقعی ارسال کند و دسترسی آن باید محدود باشد.
Point-in-Time Recovery
PITR امکان بازگشت به نقطه‌ای میان backupهای کامل را با log تراکنش می‌دهد، اما setup، retention و آزمون پیچیده‌تری دارد. corruption منطقی و زمان دقیق رخداد باید مشخص شود. replication به‌تنهایی backup نیست؛ حذف یا خرابی منطقی می‌تواند سریع replicate شود.
مانیتورینگ Pipeline
- زمان آخرین backup موفق هر dataset
- حجم و تغییر غیرعادی نسبت به baseline
- مدت job و نزدیک‌شدن به پنجره بعدی
- نتیجه upload، checksum و retention
- تازگی recovery point و پوشش RPO
- تاریخ آخرین restore test و زمان واقعی آن
- انقضای credential یا کلید backup
exit code صفر یک مرحله کافی نیست. اگر dump موفق اما upload شکست خورده، نسخه خارج سرور به‌روز نیست. alert باید dataset و آخرین recovery point سالم را گزارش کند.
Runbook و مسئولیت
در بحران، دانستن نام ابزار کافی نیست. محل backup، روش دسترسی، ترتیب restore، DNS، dependency، owner و escalation را مستند کنید. حداقل دو فرد مجاز باید مسیر را بفهمند، بدون اینکه credential مشترک بسازید. runbook پس از هر تغییر معماری به‌روز شود.
اشتباه‌های رایج
- تنها نسخه روی همان سرور
- snapshot به‌عنوان تنها backup
- کپی خام دیتابیس در حال اجرا
- رمزنگاری بدون recovery کلید
- retention نامحدود یا بسیار کوتاه
- مانیتور job بدون restore test
- نادیده گرفتن فایل upload یا config
- restore آزمایشی با اتصال‌های production
چه زمانی کمک تخصصی لازم است؟
اگر دیتابیس، volumeهای Docker، فایل کاربر و object storage هم‌زمان باید سازگار بازیابی شوند، یک cron ساده کافی نیست. مدیریت ماهانه سرور می‌تواند RPO/RTO، pipeline رمزنگاری‌شده، retention، alert و restore test مستند را پیاده کند.
پرسش‌های متداول
هر چند وقت بکاپ بگیریم؟
بر اساس RPO و نرخ تغییر؛ اگر از دست رفتن یک ساعت سفارش قابل‌قبول نیست، backup روزانه کافی نیست.
آیا Snapshot کافی است؟
خیر؛ برای recovery سریع مفید است اما consistency و failure domain و حذف حساب را به‌تنهایی پوشش نمی‌دهد.
چطور بفهمیم بکاپ سالم است؟
checksum و verify اولیه لازم‌اند، اما فقط restore دوره‌ای در محیط جدا قابلیت بازیابی واقعی را ثابت می‌کند.
Replication جای Backup است؟
نه؛ حذف، corruption یا تغییر ناخواسته می‌تواند replicate شود. replication availability را بهتر می‌کند، نه history مستقل را.