محتوای آموزشی وبلاگ نتآرام
وجود یک فایل با نام
backup.zip خیال آدم را راحت میکند، اما تا زمانی که آن فایل مستقل، سالم و قابلبازیابی نباشد، بکاپ نیست؛ فقط امیدی فشردهشده است. بسیاری از خرابیها هنگام گرفتن نسخه رخ نمیدهند. روز Restore معلوم میشود آرشیو ناقص بوده، دیتابیس با فایلها همزمان نیست یا رمز رمزنگاری در دسترس نیست.قاعدهٔ ۳-۲-۱ یک نقطهٔ شروع ساده است:
- دستکم سه نسخه از داده؛
- روی دو نوع یا سامانهٔ ذخیرهسازی مستقل؛
- دستکم یک نسخه خارج از محل اصلی.
این اعداد جادو نیستند. هدف حذف «نقطهٔ خرابی مشترک» است.
اول RPO و RTO را مشخص کنید
پیش از انتخاب حجم و زمانبندی، دو پرسش تجاری را پاسخ دهید:
RPO میگوید حداکثر از دستدادن چه مقدار داده قابلتحمل است. اگر فروشگاه روزانه هزار سفارش دارد، بکاپ شبانه ممکن است تا ۲۴ ساعت سفارش را از دست بدهد. شاید RPO پانزدهدقیقهای برای دیتابیس لازم باشد.
RTO میگوید سرویس حداکثر چه مدت میتواند از دسترس خارج بماند. داشتن چند ترابایت بکاپ روی فضای کند، اگر بازیابی آن دو روز طول بکشد، برای RTO چهارساعته کافی نیست.
زمانبندی بدون این دو عدد یا بیشازحد گران میشود یا روز حادثه نیاز واقعی را پوشش نمیدهد.
Snapshot را با بکاپ اشتباه نگیرید
Snapshot برای بازگشت کوتاهمدت پیش از یک تغییر مفید است، اما معمولاً روی همان Storage ماشین قرار دارد. خرابی Storage، حذف اشتباه VM یا دسترسی مهاجم میتواند Snapshot و ماشین اصلی را همزمان از بین ببرد.
Snapshot بخشی از برنامه است، نه کل آن. نسخهٔ مستقل باید از محیط تولید جدا شود و سیاست نگهداری خودش را داشته باشد.
سه نسخه چه هستند؟
برای یک سرور وب نمونه میتوان این ساختار را داشت:
- دادهٔ فعال روی سرور؛
- بکاپ زمانبندیشده روی فضای بکاپ مستقل؛
- نسخهٔ ثانویه در موقعیت یا حساب مدیریتی جدا.
اگر هر سه با یک حساب روت، یک Credential و یک پنل قابل حذف باشند، استقلال واقعی ندارند. دسترسی نوشتن از سرور تولید به مخزن بکاپ را محدود کنید و در صورت امکان سیاست Immutable یا نگهداری نسخهها داشته باشید.
سازگاری فایل و دیتابیس مهم است
کپی فایلهای وردپرس و Dump دیتابیس در دو زمان متفاوت میتواند حالتی بسازد که رسانه یا سفارش در یکی هست و در دیگری نیست. برای سیستم پرتراکنش، فرآیند بکاپ باید سازگاری برنامه را در نظر بگیرد:
- دیتابیس را با ابزار و گزینهٔ سازگار با موتور آن Dump کنید؛
- هنگام بکاپ فایلهای در حال تغییر، Snapshot فایلسیستم یا توقف بسیار کوتاه کنترلشده داشته باشید؛
- نسخهٔ برنامه، پیکربندی و Schema را کنار داده ثبت کنید؛
- صفها و فایلهای موقت را براساس نیاز واقعی وارد یا حذف کنید.
در فروشگاه، بکاپ کامل هفتگی بهتنهایی کافی نیست. دیتابیس سفارشها ممکن است به نسخههای نزدیکتر نیاز داشته باشد، در حالی که تصاویر کمتر تغییر میکنند.
نگهداری چندنسخهای جلوی باجافزار و خطای دیرکشف را میگیرد
اگر هر بکاپ نسخهٔ قبلی را جایگزین کند، خرابی خاموش یا آلودگی میتواند وارد تنها نسخه شود. یک الگوی نمونه:
- نسخههای ساعتی برای ۲۴ ساعت؛
- نسخههای روزانه برای ۱۴ روز؛
- نسخههای هفتگی برای ۸ هفته؛
- نسخههای ماهانه براساس الزام کسبوکار.
این اعداد باید با RPO، حجم و هزینه تنظیم شوند. نکته داشتن نقاط زمانی متفاوت است. تاریخچه باید بهاندازهای طولانی باشد که خطای دیرکشف را پوشش دهد.
رمزنگاری بدون مدیریت کلید خطرناک است
بکاپ خارج از محل باید در انتقال و در حالت ذخیره رمزنگاری شود، بهخصوص اگر شامل اطلاعات مشتری یا Credential است. اما اگر کلید فقط روی همان سرور خرابشده باشد، فایل امن و غیرقابلبازیابی خواهید داشت.
کلید یا Secret بازیابی را در محل امن و جدا نگه دارید، دسترسی آن را محدود و فرآیند تحویل اضطراری را مستند کنید. کلید را داخل همان آرشیو قرار ندهید.
اعتبارسنجی خودکار و آزمون Restore دو چیز متفاوتاند
Checksum، اندازهٔ فایل و موفقیت Job نشان میدهد انتقال ظاهراً کامل شده است. این کنترلها لازماند اما ثابت نمیکنند برنامه بالا میآید. آزمون Restore باید این مراحل را پوشش دهد:
- استخراج فایل در محیط جدا؛
- بازیابی دیتابیس؛
- اعمال پیکربندی و Secretهای لازم؛
- بالا آمدن سرویس بدون اتصال اشتباه به کاربران واقعی؛
- اجرای Health Check و چند سناریوی کاربردی؛
- ثبت زمان واقعی بازیابی.
برای سایت مهم، دستکم فصلی یک Restore کامل تمرین کنید. پس از تغییر بزرگ معماری یا نسخهٔ دیتابیس نیز آزمون را تکرار کنید.
مانیتورینگ بکاپ باید نبودن نسخه را فریاد بزند
پیام «Job اجرا شد» کافی نیست. مانیتورینگ باید آخرین بکاپ موفق، سن فایل، حجم غیرعادی، نتیجهٔ Checksum و وضعیت فضای مقصد را بررسی کند. اگر فایل امروز ناگهان یکدهم میانگین روزهای قبل است، موفقیت ابزار انتقال نباید آن را سالم تلقی کند.
اعلان شکست را به مسیری بفرستید که مستقل از همان سرور باشد. اگر ایمیل و مانیتورینگ هر دو روی سرور خراب قرار دارند، حادثه صدای هشدار را هم خاموش میکند.
بکاپ قبل از تغییر، راه بازگشت مشخص میخواهد
قبل از ارتقای سیستمعامل، تغییر دیسک، نصب مجدد یا مهاجرت:
- زمان آخرین نسخهٔ سالم را ثبت کنید؛
- Checksum و قابلیت خواندن آن را کنترل کنید؛
- مشخص کنید در چه شرطی Rollback میکنید؛
- مسئول تصمیم بازگشت را تعیین کنید؛
- برآورد زمان Restore را با پنجرهٔ نگهداری مقایسه کنید.
صرف نوشتن «بکاپ گرفته شد» در تیکت، برنامهٔ بازیابی نیست.
یک ماتریس ساده برای سرویسها بسازید
| سرویس | RPO | RTO | نسخه مستقل | آخرین Restore آزمایشی |
| --- | --- | --- | --- | --- |
| وبسایت شرکتی | ۲۴ ساعت | ۸ ساعت | دارد | |
| فروشگاه | ۱۵ دقیقه | ۲ ساعت | دارد | |
| فایلهای کاربران | ۱ ساعت | ۴ ساعت | دارد | |
این جدول سریع نشان میدهد کدام سرویس فقط «فایل بکاپ» دارد و کدام واقعاً برنامهٔ تداوم کسبوکار دارد. برای پیادهسازی و پایش روی سرور، مدیریت سرور باید خروجی آزمون و مستند بازیابی تحویل دهد، نه فقط نام یک Job زمانبندیشده.
جمعبندی
بکاپ ۳-۲-۱ یعنی نسخهها خرابی مشترک نداشته باشند. RPO و RTO، نگهداری چندنسخهای، رمزنگاری با مدیریت کلید، مانیتورینگ و Restore آزمایشی اجزای یک سیستماند. نسخهای که هرگز برنگرداندهاید، هنوز اثبات نشده است؛ روز حادثه جای اولین آزمایش نیست.
برچسبها:
اشتراکگذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاهها (۰)
دیدگاههای تاییدشده و پاسخهای تیم نتآرام