بکاپ داریم، اما هیچوقت بازگردانیاش را امتحان نکردهایم
فایل بکاپ ممکن است ناقص، خراب یا بدون دیتابیس باشد و این معمولاً در بدترین زمان معلوم میشود. بازیابی آزمایشی را در محیط جدا انجام میدهیم تا سلامت بکاپ روشن شود.
شبکه، مجازیسازی و ابر
بکاپ گیری سرور و بازیابی بحران (Disaster Recovery)
بکاپگیری سرور وقتی به کار میآید که در روز حادثه بشود سرویس را از آن برگرداند. کانفیگ سرور برنامه پشتیبانگیری و بازیابی بحران را متناسب با اهمیت هر سرویس طراحی و اجرا میکند و بازیابی را بهصورت دورهای تست میکند.
Veeam Backup & Replication
Proxmox Backup Server
restic، borg و rsync
چه زمانی به این خدمت نیاز دارید؟
نشانههایی که برنامه بکاپگیری سرور شما ناقص است
بکاپها روی همان سرور یا همان دیتاسنتر است
باجافزار، خرابی دیسک یا حذف اشتباه میتواند نسخه اصلی و بکاپ را همزمان از بین ببرد. دستکم یک نسخه باید بیرون از دسترس سرور اصلی نگهداری شود.
نمیدانیم اگر سرور از دست برود، چند ساعت کار متوقف میشود
وقتی RPO و RTO تعریف نشده، بودجه بکاپ را نمیشود توجیه کرد و مدیران هم نمیدانند چه انتظاری داشته باشند. این دو هدف را با شما و بر اساس اثر توقف هر سرویس تعیین میکنیم.
مفاهیم پایه
قاعده 3-2-1، RPO و RTO به زبان ساده
پیش از انتخاب ابزار باید روشن باشد از چه چیزی، چند نسخه، کجا و با چه سرعتی باید بازگردانده شود.
قاعده 3-2-1
از دادههای مهم سه نسخه داشته باشید، روی دو نوع ذخیرهسازی متفاوت، که دستکم یکی از آنها بیرون از محل سرور اصلی باشد.
- سه نسخه: نسخه اصلی بهعلاوه دو بکاپ
- دو نوع ذخیرهسازی یا سیستم متفاوت
- یک نسخه بیرون از محل؛ ترجیحاً تغییرناپذیر یا آفلاین در برابر باجافزار
RPO: چه مقدار داده را میتوانید از دست بدهید؟
RPO فاصله زمانی بین آخرین نسخه سالم و لحظه حادثه است. اگر بکاپ فقط هر شب گرفته شود، در بدترین حالت کار یک روز کامل از دست میرود و این مقدار برای دیتابیس فروش یا حسابداری معمولاً زیاد است.
RTO: سرویس چقدر میتواند از دسترس خارج باشد؟
RTO مدت قابل قبول از لحظه حادثه تا کار کردن دوباره سرویس است و آماده کردن سرور، بازگردانی داده و تست را شامل میشود. RTO کوتاهتر معمولاً به نسخه آماده (Replication) و هزینه بیشتر نیاز دارد.
تست بازیابی منظم
در بازههای منظم، بکاپ را در محیط جدا بازمیگردانیم، سلامت فایلها و دیتابیس را بررسی میکنیم و زمان واقعی بازیابی را با RTO هدف مقایسه میکنیم.
آنچه انجام میدهیم
خدمات بکاپگیری سرور و Disaster Recovery
از یک سرور لینوکسی تا محیط مجازیسازی چندمیزبانی، طرح بکاپ را با ابزار مناسب همان محیط اجرا میکنیم.
طراحی سیاست بکاپ
مشخص میکنیم از چه چیزی، هر چند وقت و تا چه مدت نسخه نگهداری شود.
- دستهبندی سرویسها بر اساس اهمیت
- تعیین RPO و RTO هدف با شما
- زمانبندی، مدت نگهداری (Retention) و رمزنگاری
بکاپ ماشین مجازی و سرور فیزیکی
برای هر بستر ابزاری را انتخاب میکنیم که بازگردانی سریع و قابل اتکا بدهد.
- Veeam Backup & Replication برای VMware، Hyper-V و سرور فیزیکی
- Proxmox Backup Server با بکاپ افزایشی و حذف داده تکراری
- بکاپ سازگار با برنامه برای دیتابیسها
بکاپ لینوکس، فایل و دیتابیس
روی سرورهای لینوکسی و هاستها، ابزارهای سبک و رمزنگاریشده معمولاً کافیاند.
- restic، borg یا rsync با زمانبندی مشخص
- خروجی منظم از MySQL و PostgreSQL
- بکاپ حسابهای cPanel و DirectAdmin
نسخه بیرون از محل روی S3
نسخه دوم را پیش از ارسال رمزنگاری میکنیم و روی ذخیرهسازی S3-compatible داخل یا خارج کشور نگه میداریم.
- رمزنگاری پیش از خروج داده از سرور
- قفل تغییرناپذیری در صورت پشتیبانی ذخیرهسازی
- کنترل هزینه با سیاست نگهداری مناسب
طرح بازیابی بحران (DR)
برای سرویسهایی که RTO کوتاه دارند، بکاپ بهتنهایی کافی نیست و میزبان یا سایت دوم لازم است.
- Replication ماشینهای مجازی به میزبان یا سایت دوم
- Runbook مکتوب: چه کسی، چه کاری، به چه ترتیب
- ترتیب راهاندازی سرویسهای وابسته
پایش و گزارش دورهای
Job بکاپی که بیصدا شکست بخورد، تا روز حادثه دیده نمیشود.
- هشدار برای Jobهای ناموفق
- گزارش دورهای وضعیت بکاپ و فضای ذخیرهسازی
- بهروزرسانی طرح با تغییر سرورها
راهنمای کامل
راهنمای بکاپگیری سرور و طراحی Disaster Recovery
بکاپگیری سرور یعنی از داده و پیکربندی سرویسها نسخهای نگهداری شود که بعد از خرابی دیسک، حذف اشتباه یا حمله باجافزار قابل بازگرداندن باشد. بازیابی بحران (Disaster Recovery) یک قدم جلوتر است و مشخص میکند سرویسها با چه ترتیبی، در چه مدتی و روی کدام سرور دوباره راه میافتند. بسیاری از سازمانها بکاپ دارند، اما هیچوقت از آن بازگردانی نکردهاند و نمیدانند برگرداندن یک سرور چند ساعت طول میکشد. نکتههای زیر ترتیب طراحی را از فهرست دادهها تا تست بازیابی توضیح میدهد.
از کجا شروع کنیم: فهرست دادهها، RPO و RTO
کار با فهرست سرویسها و دادهها شروع میشود: دیتابیسها، فایلهای کاربران، ماشینهای مجازی، ایمیل و پیکربندی سرورها. برای هر سرویس بپرسید اگر یک روز از دسترس خارج شود یا داده یک روز از دست برود، چه اتفاقی میافتد. RPO از پاسخ همین سؤال به دست میآید و تعیین میکند هر چند وقت نسخه بگیرید؛ با بکاپ شبانه، در بدترین حالت کار یک روز از دست میرود. RTO روش بازیابی را تعیین میکند، چون برگرداندن داده از بکاپ ساعتها طول میکشد و RTO کوتاهتر به Replication روی میزبان یا سایت دوم نیاز دارد.
این اهداف را با مدیران سازمان تعیین کنید و هزینه هر گزینه را کنارش بگذارید. RPO و RTO کوتاهتر فضای ذخیرهسازی بیشتر، لینک سریعتر یا سختافزار دوم میخواهد و همه سرویسها به آن نیاز ندارند. سایتی که کم تغییر میکند ممکن است با بکاپ روزانه کافی باشد، در حالی که دیتابیس سفارشها یا حسابداری فاصلههای کوتاهتری لازم دارد.
قاعده 3-2-1 و محافظت از بکاپ در برابر باجافزار
قاعده 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
بکاپی که هیچوقت بازگردانده نشده، ممکن است روز حادثه ناقص، خراب یا بدون دیتابیس از آب درآید. تست را در شبکهای جدا از محیط اصلی انجام دهید تا سرویس بازیابیشده با سرور اصلی تداخل نکند. در هر تست این موارد را بررسی میکنیم:
- بازگرداندن یک سرور یا ماشین کامل
- باز کردن دیتابیس بازیابیشده و بررسی آخرین رکوردها
- بازگرداندن چند فایل از نسخههای قدیمیتر
- اندازهگیری زمان کل و مقایسه آن با RTO هدف
Runbook بازیابی مکتوب میکند چه کسی، چه کاری و به چه ترتیبی انجام دهد. ترتیب راهاندازی اهمیت دارد، چون سرویسهایی مثل DNS و Active Directory باید پیش از دیتابیس و دیتابیس پیش از اپلیکیشن بالا بیایند. نسخهای از Runbook و اطلاعات دسترسی به مخزن بکاپ را بیرون از سرورهایی نگه دارید که قرار است بازیابی شوند. هشدار Jobهای ناموفق را هم فعال کنید و طرح را با هر تغییر سرورها بهروز کنید.
زمان و هزینه بکاپ و DR به چه بستگی دارد؟
تعداد سرورها و سرویسها، حجم داده و سرعت تغییر آن، اهداف RPO و RTO و نیاز به Replication یا سایت دوم پایه برآورد هستند. هزینه فضای ذخیرهسازی و لایسنس نرمافزار جداست و فاصله تستهای بازیابی در قرارداد مشخص میشود. اگر نمیدانید بکاپ فعلی قابل بازگرداندن است یا نه، از بررسی رایگان وضعیت بکاپ شروع کنید. برای برآورد، فهرست سرورها، حجم تقریبی داده، ابزار بکاپ فعلی و محل نگهداری نسخهها را بفرستید.
کلید یا رمز رمزنگاری بکاپ را فقط روی همان سروری که از آن بکاپ میگیرید نگه ندارید. اگر آن سرور از دست برود یا رمزگذاری شود، بکاپ رمزنگاریشده بدون کلید قابل بازگرداندن نیست.
مقایسه خدمات
کدام سرویس بکاپ برای شما مناسب است؟
سه خدمت کانفیگ سرور به بکاپ و بازیابی مربوطاند و هر کدام برای موقعیت متفاوتی است.
| موقعیت شما | خدمت مناسب | نوع همکاری |
|---|---|---|
| میخواهید بدانید بکاپ فعلی واقعاً قابل بازیابی است یا نه | بررسی رایگان وضعیت بکاپ یا مشاوره از طریق تلگرام | یکباره و رایگان |
| داده همین حالا از دست رفته یا سرور بالا نمیآید | بازیابی اطلاعات سرور | فوری و یکباره |
| فایلها رمزگذاری شده و پیام باج دریافت کردهاید | بازیابی از باجافزار | فوری و یکباره |
| میخواهید بکاپ و DR بهطور مستمر اجرا، پایش و تست شود | بکاپ و بازیابی بحران (همین خدمت) | قرارداد مدیریتشده و مستمر |
فرآیند اجرای کار
مراحل طراحی بکاپگیری سرور و DR، از ارزیابی تا تست مستمر
۱. ارزیابی وضعیت فعلی
سرورها، دادههای مهم، بکاپهای موجود و محل نگهداری آنها را بررسی میکنیم و در صورت امکان یک بازیابی آزمایشی انجام میدهیم.
۲. طراحی طرح بکاپ و DR
RPO و RTO هدف هر سرویس را با شما تعیین میکنیم و ساختار 3-2-1، ابزارها، زمانبندی و فضای ذخیرهسازی لازم را پیشنهاد میدهیم.
۳. اجرا و مستندسازی
Jobهای بکاپ، رمزنگاری، نسخه بیرون از محل و Runbook بازیابی را راهاندازی و مستند میکنیم.
۴. تست و پایش مستمر
بازیابی را در بازههای توافقشده تست میکنیم، نتیجه را گزارش میدهیم و طرح را با تغییر زیرساخت بهروز میکنیم.
محدوده خدمت بکاپ و بازیابی بحران
شامل این خدمت
- طراحی سیاست بکاپ و تعیین RPO و RTO هدف
- راهاندازی Veeam، Proxmox Backup Server یا restic و borg
- نسخه بیرون از محل روی ذخیرهسازی S3-compatible
- Runbook بازیابی بحران و مستندات
- تست بازیابی و گزارش دورهای طبق قرارداد
خارج از این خدمت
- نجات اضطراری داده از دیسک خراب یا سرور بدون بکاپ؛ بازیابی اطلاعات سرور
- پاکسازی و بازگردانی پس از حمله؛ بازیابی از باجافزار
- هزینه فضای ذخیرهسازی و لایسنس نرمافزار؛ پرسشهای لایسنس Veeam در لایسنسهای سازمانی
- امنسازی کامل سیستمعامل؛ امنسازی سرور
چرا کانفیگ سرور؟
بکاپ را برای روز بازیابی طراحی میکنیم
معیار موفقیت این است که در تست بازیابی، سرویس در زمان مورد انتظار شما دوباره کار کند. مشاوره اولیه از طریق تلگرام رایگان است.
01
ابزار متناسب با محیط
با Veeam، Proxmox Backup Server، restic، borg و rsync کار میکنیم و هر جا ممکن باشد، گزینه متنباز را برای کاهش هزینه لایسنس پیشنهاد میدهیم.
02
تست بازیابی جزو کار است
طرح بکاپ همراه بازیابی آزمایشی و مقایسه زمان واقعی با RTO هدف تحویل میشود و گزارش موفق بودن Jobها بهتنهایی ملاک نیست.
03
راهنماهای فنی منتشرشده
راهنمای Veeam Backup & Replication و Proxmox Backup Server را منتشر کردهایم تا پیش از تصمیم با ابزارها آشنا شوید.
راهنماهای مرتبط
راهنما
دانلود Veeam Backup & Replication 12.3 + راهنمای جامع معماری و نصب
معماری و اجزای Veeam پیش از طراحی بکاپ ماشینهای مجازی.
راهنمادانلود Proxmox Backup Server: راهنمای جامع و کاربردی
گزینه متنباز بکاپ برای محیطهای Proxmox VE.
راهنمادانلود Veeam ONE 12.3 + راهنمای مانیتورینگ و گزارشگیری زیرساخت
پایش و گزارشگیری از وضعیت Jobهای بکاپ.
سوالات متداول
پرسشهای رایج درباره بکاپگیری سرور
آیا Snapshot ماشین مجازی جای بکاپ را میگیرد؟
خیر. Snapshot معمولاً روی همان استوریج ماشین نگهداری میشود و با خرابی استوریج یا حذف ماشین از بین میرود. Snapshot برای بازگشت کوتاهمدت پیش از تغییرات مفید است، اما بکاپ باید مستقل و بیرون از همان سیستم باشد.
RAID جایگزین بکاپ است؟
خیر. RAID در برابر خرابی یک دیسک از دسترسپذیری محافظت میکند، اما حذف اشتباه، خراب شدن فایل یا رمزگذاری باجافزار فوراً روی همه دیسکها اعمال میشود.
هر چند وقت یکبار باید از سرور بکاپ گرفت؟
فاصله بکاپ به RPO هر سرویس بستگی دارد. سایتهای کمتغییر ممکن است با بکاپ روزانه کافی باشند، اما دیتابیس سفارشها یا حسابداری معمولاً به فاصلههای کوتاهتر یا Replication نیاز دارد.
نگهداری بکاپ روی فضای ابری امن است؟
در صورتی امن است که داده پیش از ارسال رمزنگاری شود و کلید آن جدا از سرور اصلی نگهداری شود. محل ذخیرهسازی داخل یا خارج کشور را هم بر اساس الزامات قانونی و سرعت بازیابی انتخاب میکنیم.
میتوانید از پیش عدد مشخصی برای RPO و RTO قول بدهید؟
پیش از ارزیابی عددی قول نمیدهیم. اهداف RPO و RTO را با توجه به زیرساخت و بودجه شما تعیین میکنیم و دستیافتنی بودن آنها را با تست بازیابی اندازه میگیریم.
تفاوت این خدمت با بازیابی اطلاعات فوری چیست؟
بکاپ و بازیابی بحران یک قرارداد مستمر برای پیشگیری و آمادگی است؛ بازیابی اطلاعات فوری برای زمانی است که حادثه رخ داده و باید داده را همان لحظه نجات داد.
از بکاپهای خود مطمئن نیستید؟
وضعیت فعلی بکاپ و سرورهای خود را در تلگرام بنویسید تا کارشناس ما نقاط ضعف را مشخص کند و مسیر مناسب را پیشنهاد دهد.
