بکاپ‌گیری سرور وقتی به کار می‌آید که در روز حادثه بشود سرویس را از آن برگرداند. کانفیگ سرور برنامه پشتیبان‌گیری و بازیابی بحران را متناسب با اهمیت هر سرویس طراحی و اجرا می‌کند و بازیابی را به‌صورت دوره‌ای تست می‌کند.
فایل بکاپ ممکن است ناقص، خراب یا بدون دیتابیس باشد و این معمولاً در بدترین زمان معلوم می‌شود. بازیابی آزمایشی را در محیط جدا انجام می‌دهیم تا سلامت بکاپ روشن شود. روش گرفتن بکاپ سازگار از MySQL و MariaDB را در بکاپ گرفتن از دیتابیس MySQL نوشته‌ایم.
باج‌افزار، خرابی دیسک یا حذف اشتباه می‌تواند نسخه اصلی و بکاپ را هم‌زمان از بین ببرد. دست‌کم یک نسخه باید بیرون از دسترس سرور اصلی نگهداری شود.
وقتی RPO و RTO تعریف نشده، بودجه بکاپ را نمی‌شود توجیه کرد و مدیران هم نمی‌دانند چه انتظاری داشته باشند. این دو هدف را با شما و بر اساس اثر توقف هر سرویس تعیین می‌کنیم.
پیش از انتخاب ابزار باید روشن باشد از چه چیزی، چند نسخه، کجا و با چه سرعتی باید بازگردانده شود.
از داده‌های مهم سه نسخه داشته باشید، روی دو نوع ذخیره‌سازی متفاوت، که دست‌کم یکی از آن‌ها بیرون از محل سرور اصلی باشد.
RPO فاصله زمانی بین آخرین نسخه سالم و لحظه حادثه است. اگر بکاپ فقط هر شب گرفته شود، در بدترین حالت کار یک روز کامل از دست می‌رود و این مقدار برای دیتابیس فروش یا حسابداری معمولاً زیاد است.
RTO مدت قابل قبول از لحظه حادثه تا کار کردن دوباره سرویس است و آماده کردن سرور، بازگردانی داده و تست را شامل می‌شود. RTO کوتاه‌تر معمولاً به نسخه آماده (Replication) و هزینه بیشتر نیاز دارد.
در بازه‌های منظم، بکاپ را در محیط جدا بازمی‌گردانیم، سلامت فایل‌ها و دیتابیس را بررسی می‌کنیم و زمان واقعی بازیابی را با RTO هدف مقایسه می‌کنیم.
از یک سرور لینوکسی تا محیط مجازی‌سازی چندمیزبانی، طرح بکاپ را با ابزار مناسب همان محیط اجرا می‌کنیم.
مشخص می‌کنیم از چه چیزی، هر چند وقت و تا چه مدت نسخه نگهداری شود.
برای هر بستر ابزاری را انتخاب می‌کنیم که بازگردانی سریع و قابل اتکا بدهد.
روی سرورهای لینوکسی و هاست‌ها، ابزارهای سبک و رمزنگاری‌شده معمولاً کافی‌اند.
نسخه دوم را پیش از ارسال رمزنگاری می‌کنیم و روی ذخیره‌سازی S3-compatible داخل یا خارج کشور نگه می‌داریم.
برای سرویس‌هایی که RTO کوتاه دارند، بکاپ به‌تنهایی کافی نیست و میزبان یا سایت دوم لازم است.
Job بکاپی که بی‌صدا شکست بخورد، تا روز حادثه دیده نمی‌شود.
بکاپ‌گیری سرور یعنی از داده و پیکربندی سرویس‌ها نسخه‌ای نگهداری شود که بعد از خرابی دیسک، حذف اشتباه یا حمله باج‌افزار قابل بازگرداندن باشد. بازیابی بحران (Disaster Recovery) یک قدم جلوتر است و مشخص می‌کند سرویس‌ها با چه ترتیبی، در چه مدتی و روی کدام سرور دوباره راه می‌افتند. بسیاری از سازمان‌ها بکاپ دارند، اما هیچ‌وقت از آن بازگردانی نکرده‌اند و نمی‌دانند برگرداندن یک سرور چند ساعت طول می‌کشد. نکته‌های زیر ترتیب طراحی را از فهرست داده‌ها تا تست بازیابی توضیح می‌دهد.
کار با فهرست سرویس‌ها و داده‌ها شروع می‌شود: دیتابیس‌ها، فایل‌های کاربران، ماشین‌های مجازی، ایمیل و پیکربندی سرورها. برای هر سرویس بپرسید اگر یک روز از دسترس خارج شود یا داده یک روز از دست برود، چه اتفاقی می‌افتد. RPO از پاسخ همین سؤال به دست می‌آید و تعیین می‌کند هر چند وقت نسخه بگیرید؛ با بکاپ شبانه، در بدترین حالت کار یک روز از دست می‌رود. RTO روش بازیابی را تعیین می‌کند، چون برگرداندن داده از بکاپ ساعت‌ها طول می‌کشد و RTO کوتاه‌تر به Replication روی میزبان یا سایت دوم نیاز دارد.
این اهداف را با مدیران سازمان تعیین کنید و هزینه هر گزینه را کنارش بگذارید. RPO و RTO کوتاه‌تر فضای ذخیره‌سازی بیشتر، لینک سریع‌تر یا سخت‌افزار دوم می‌خواهد و همه سرویس‌ها به آن نیاز ندارند. سایتی که کم تغییر می‌کند ممکن است با بکاپ روزانه کافی باشد، در حالی که دیتابیس سفارش‌ها یا حسابداری فاصله‌های کوتاه‌تری لازم دارد.
قاعده 3-2-1 می‌گوید از داده مهم سه نسخه داشته باشید، روی دو نوع ذخیره‌سازی متفاوت، و دست‌کم یکی از آن‌ها بیرون از محل سرور اصلی باشد. باج‌افزارها معمولاً پیش از رمزگذاری سراغ بکاپ‌ها می‌روند، پس نسخه‌ای که با همان حساب کاربری سرور اصلی قابل حذف باشد محافظت کافی ندارد. برای مخزن بکاپ حساب و رمز جدا تعریف کنید، اگر ذخیره‌سازی قفل تغییرناپذیری دارد آن را فعال کنید و یک نسخه را آفلاین یا بیرون از دسترس شبکه اصلی نگه دارید. داده را هم پیش از ارسال به ذخیره‌سازی S3-compatible رمزنگاری کنید.
Snapshot و RAID جای بکاپ را نمی‌گیرند. Snapshot روی همان استوریج ماشین نگهداری می‌شود و RAID حذف اشتباه یا رمزگذاری را فوراً روی همه دیسک‌ها تکرار می‌کند. اگر حمله رخ داده و فایل‌ها رمزگذاری شده‌اند، کار از بازیابی از باج‌افزار شروع می‌شود و طرح بکاپ جدید بعد از پاک‌سازی نوشته می‌شود.
ابزار باید با بستر هماهنگ باشد. Veeam Backup & Replication برای VMware، Hyper-V و سرور فیزیکی بکاپ سازگار با برنامه می‌گیرد و Proxmox Backup Server برای ماشین‌های Proxmox VE بکاپ افزایشی با حذف داده تکراری دارد؛ طراحی خود بستر مجازی در خدمات مجازی‌سازی سرور انجام می‌شود. روی سرورهای لینوکسی، restic و borg نسخه‌های رمزنگاری‌شده با تاریخچه می‌سازند. rsync به‌تنهایی فقط فایل‌ها را همگام می‌کند، پس اگر فایلی در مبدأ حذف یا خراب شود، در همگام‌سازی بعدی همان تغییر به مقصد هم می‌رسد، مگر آنکه نسخه‌های قدیمی جداگانه نگهداری شوند.
از فایل‌های در حال استفاده دیتابیس کپی مستقیم نگیرید، چون نسخه‌ای که وسط نوشتن گرفته شود ممکن است باز نشود. برای MySQL و PostgreSQL خروجی منظم با ابزارهای خود دیتابیس یا بکاپ سازگار با برنامه بگیرید. روی هاست‌ها، بکاپ حساب‌های cPanel و DirectAdmin ایمیل، دیتابیس و تنظیمات هر حساب را یک‌جا نگه می‌دارد.
بکاپی که هیچ‌وقت بازگردانده نشده، ممکن است روز حادثه ناقص، خراب یا بدون دیتابیس از آب درآید. تست را در شبکه‌ای جدا از محیط اصلی انجام دهید تا سرویس بازیابی‌شده با سرور اصلی تداخل نکند. در هر تست این موارد را بررسی می‌کنیم:
Runbook بازیابی مکتوب می‌کند چه کسی، چه کاری و به چه ترتیبی انجام دهد. ترتیب راه‌اندازی اهمیت دارد، چون سرویس‌هایی مثل DNS و Active Directory باید پیش از دیتابیس و دیتابیس پیش از اپلیکیشن بالا بیایند. نسخه‌ای از Runbook و اطلاعات دسترسی به مخزن بکاپ را بیرون از سرورهایی نگه دارید که قرار است بازیابی شوند. هشدار Jobهای ناموفق را هم فعال کنید و طرح را با هر تغییر سرورها به‌روز کنید.
تعداد سرورها و سرویس‌ها، حجم داده و سرعت تغییر آن، اهداف RPO و RTO و نیاز به Replication یا سایت دوم پایه برآورد هستند. هزینه فضای ذخیره‌سازی و لایسنس نرم‌افزار جداست و فاصله تست‌های بازیابی در قرارداد مشخص می‌شود. اگر نمی‌دانید بکاپ فعلی قابل بازگرداندن است یا نه، از بررسی رایگان وضعیت بکاپ شروع کنید. برای برآورد، فهرست سرورها، حجم تقریبی داده، ابزار بکاپ فعلی و محل نگهداری نسخه‌ها را بفرستید.
کلید یا رمز رمزنگاری بکاپ را فقط روی همان سروری که از آن بکاپ می‌گیرید نگه ندارید. اگر آن سرور از دست برود یا رمزگذاری شود، بکاپ رمزنگاری‌شده بدون کلید قابل بازگرداندن نیست.
سه خدمت کانفیگ سرور به بکاپ و بازیابی مربوط‌اند و هر کدام برای موقعیت متفاوتی است.
| موقعیت شما | خدمت مناسب | نوع همکاری |
|---|---|---|
| می‌خواهید بدانید بکاپ فعلی واقعاً قابل بازیابی است یا نه | بررسی رایگان وضعیت بکاپ یا مشاوره از طریق تلگرام | یک‌باره و رایگان |
| داده همین حالا از دست رفته یا سرور بالا نمی‌آید | بازیابی اطلاعات سرور | فوری و یک‌باره |
| فایل‌ها رمزگذاری شده و پیام باج دریافت کرده‌اید | بازیابی از باج‌افزار | فوری و یک‌باره |
| می‌خواهید بکاپ و DR به‌طور مستمر اجرا، پایش و تست شود | بکاپ و بازیابی بحران (همین خدمت) | قرارداد مدیریت‌شده و مستمر |
سرورها، داده‌های مهم، بکاپ‌های موجود و محل نگهداری آن‌ها را بررسی می‌کنیم و در صورت امکان یک بازیابی آزمایشی انجام می‌دهیم.
RPO و RTO هدف هر سرویس را با شما تعیین می‌کنیم و ساختار 3-2-1، ابزارها، زمان‌بندی و فضای ذخیره‌سازی لازم را پیشنهاد می‌دهیم.
Jobهای بکاپ، رمزنگاری، نسخه بیرون از محل و Runbook بازیابی را راه‌اندازی و مستند می‌کنیم.
بازیابی را در بازه‌های توافق‌شده تست می‌کنیم، نتیجه را گزارش می‌دهیم و طرح را با تغییر زیرساخت به‌روز می‌کنیم.
معیار موفقیت این است که در تست بازیابی، سرویس در زمان مورد انتظار شما دوباره کار کند. مشاوره اولیه از طریق تلگرام رایگان است.
با Veeam، Proxmox Backup Server، restic، borg و rsync کار می‌کنیم و هر جا ممکن باشد، گزینه متن‌باز را برای کاهش هزینه لایسنس پیشنهاد می‌دهیم.
طرح بکاپ همراه بازیابی آزمایشی و مقایسه زمان واقعی با RTO هدف تحویل می‌شود و گزارش موفق بودن Jobها به‌تنهایی ملاک نیست.
راهنمای Veeam Backup & Replication و Proxmox Backup Server را منتشر کرده‌ایم تا پیش از تصمیم با ابزارها آشنا شوید. بکاپ از سرور فیزیکی با Veeam Agent را هم در بکاپ از سرور فیزیکی با Veeam مرحله‌به‌مرحله توضیح داده‌ایم.
معماری و اجزای Veeam پیش از طراحی بکاپ ماشین‌های مجازی.
راهنماگزینه متن‌باز بکاپ برای محیط‌های Proxmox VE.
راهنماپایش و گزارش‌گیری از وضعیت Jobهای بکاپ.
خیر. Snapshot معمولاً روی همان استوریج ماشین نگهداری می‌شود و با خرابی استوریج یا حذف ماشین از بین می‌رود. Snapshot برای بازگشت کوتاه‌مدت پیش از تغییرات مفید است، اما بکاپ باید مستقل و بیرون از همان سیستم باشد.
خیر. RAID در برابر خرابی یک دیسک از دسترس‌پذیری محافظت می‌کند، اما حذف اشتباه، خراب شدن فایل یا رمزگذاری باج‌افزار فوراً روی همه دیسک‌ها اعمال می‌شود.
فاصله بکاپ به RPO هر سرویس بستگی دارد. سایت‌های کم‌تغییر ممکن است با بکاپ روزانه کافی باشند، اما دیتابیس سفارش‌ها یا حسابداری معمولاً به فاصله‌های کوتاه‌تر یا Replication نیاز دارد.
در صورتی امن است که داده پیش از ارسال رمزنگاری شود و کلید آن جدا از سرور اصلی نگهداری شود. محل ذخیره‌سازی داخل یا خارج کشور را هم بر اساس الزامات قانونی و سرعت بازیابی انتخاب می‌کنیم.
پیش از ارزیابی عددی قول نمی‌دهیم. اهداف RPO و RTO را با توجه به زیرساخت و بودجه شما تعیین می‌کنیم و دست‌یافتنی بودن آن‌ها را با تست بازیابی اندازه می‌گیریم.
بکاپ و بازیابی بحران یک قرارداد مستمر برای پیشگیری و آمادگی است؛ بازیابی اطلاعات فوری برای زمانی است که حادثه رخ داده و باید داده را همان لحظه نجات داد.
وضعیت فعلی بکاپ و سرورهای خود را در تلگرام بنویسید تا کارشناس ما نقاط ضعف را مشخص کند و مسیر مناسب را پیشنهاد دهد.
