در این مقاله از بلاگ رهام کلود، میخوایم بررسی کنیم که بکاپگیری از سرور چه اهمیتی داره، Disaster Recovery چیست و چه تفاوتی با بکاپ معمولی داره.
همچنین میخوایم ببینیم چطور میشه یک برنامه درست برای تهیه نسخه پشتیبان و بازیابی اطلاعات داشت تا در زمان بروز مشکل، سایت، اپلیکیشن یا سرویس
شما برای مدت طولانی از دسترس خارج نشه.
تقریبا همه مدیران سرور امیدوارن هیچوقت با اتفاقاتی مثل خرابی هارد، حذف اشتباهی فایلها، حمله سایبری، باج افزار یا خرابی کامل سرور روبهرو نشن.
اما واقعیت اینه که این اتفاقها ممکنه برای هر سروری پیش بیاد. مهم این نیست که چقدر به سرور خودتون اطمینان دارید؛
مهم اینه که اگر مشکل پیش اومد، چقدر سریع و بدون از دست دادن اطلاعات میتونید همه چیز رو به حالت عادی برگردونید.
اینجاست که بکاپ و Disaster Recovery اهمیت خودشون رو نشون میدن.
فهرست موضوعات:
- Disaster Recovery چیست؟
- تفاوت Backup و Disaster Recovery چیست؟
- اهمیت بکاپگیری از سرور
- قانون 3-2-1
- بکاپ اطلاعات از سرور
- انواع بکاپ
- دوره بکاپگیری
- RPO و RTO در Disaster Recovery چیست؟
- محل نگهداری بکاپ
- تست بکاپها
- Disaster Recovery Plan شامل چه چیزهاییه؟
- طراحی برنامه بکاپ و Disaster Recovery مناسب
- اشتباه رایج…
- آیا Snapshot جای بکاپ رو میگیره؟
- امنیت بکاپها
- نتیجهگیری
- سوالات متداول
Disaster Recovery چیست؟
اگر بخوایم خیلی ساده جواب بدیم که Disaster Recovery چیست، باید بگیم Disaster Recovery یا بازیابی پس از بحران مجموعهای از برنامهها، ابزارها و
اقداماته که کمک میکنه بعد از یک اتفاق جدی، سرویسها و اطلاعات شما دوباره در کوتاهترین زمان ممکن در دسترس قرار بگیرن.
بحران همیشه به معنی آتشسوزی یا اتفاقات عجیب نیست.
برای یک سرور، حذف اشتباهی دیتابیس، خراب شدن سیستم عامل، آلوده شدن به باج افزار، خرابی سخت افزار، حمله سایبری یا حتی یک اشتباه ساده
هنگام اجرای دستور هم میتونه یک بحران جدی باشه.
مثلا فرض کنید یک فروشگاه اینترنتی روی یک سرور مجازی اجرا میشه. یک شب به دلیل خرابی دیسک، سیستم عامل بالا نمیاد و سایت کاملا از دسترس خارج میشه.
اگر فقط یک بکاپ قدیمی داشته باشید، شاید بتونید اطلاعات رو برگردونید، اما ممکنه سفارشهای چند ساعت یا چند روز اخیر رو از دست بدید.
اما اگر یک برنامه Disaster Recovery درست داشته باشید، از قبل مشخص شده که بکاپها کجا نگهداری میشن، چطور باید سرور جدید راهاندازی
بشه، اطلاعات با چه ترتیبی بازیابی بشن و چه مقدار زمان برای بازگرداندن سرویس قابل قبوله. در واقع، بکاپ فقط بخشی از Disaster Recovery محسوب میشه.
تفاوت Backup و Disaster Recovery چیست؟
خیلی وقتها این دو مفهوم با هم اشتباه گرفته میشن.
بکاپ یعنی یک نسخه کپی از اطلاعات داشته باشید تا در صورت حذف یا خرابی، بتونید دادهها رو بازیابی کنید.
اما Disaster Recovery یک برنامه کاملتره.
فرض کنید شما هر شب از فایلها و دیتابیس سایت بکاپ میگیرید. این کار خیلی خوبه، اما حالا تصور کنید سرور اصلی به طور کامل از بین رفته.
در این شرایط فقط داشتن فایل بکاپ کافی نیست. شما باید بدونید:
– بکاپها کجا قرار دارن
– چطور به اونها دسترسی پیدا کنید
– سرور جدید رو چطور آماده کنید
– چه نرم افزارهایی باید دوباره نصب بشن
– دیتابیس و فایلها با چه ترتیبی بازیابی بشن
– DNS و تنظیمات شبکه چطور به سرور جدید منتقل بشن
این مجموعه اقدامات، بخش مهمی از Disaster Recovery رو تشکیل میده.
پس میشه گفت بکاپ به شما کمک میکنه اطلاعات رو برگردونید، اما Disaster Recovery کمک میکنه کل سرویس رو دوباره راهاندازی کنید.
اهمیت بکاپگیری از سرور
بعضی از مدیران سرور تا زمانی که با یک مشکل واقعی روبهرو نشن، اهمیت بکاپ رو جدی نمیگیرن.
معمولا تصور میشه چون سرور جدید و سخت افزار خوبه، پس احتمال از دست رفتن اطلاعات خیلی کمه. اما مشکل فقط خرابی سخت افزار نیست.
ممکنه یک نفر به اشتباه یک پوشه مهم رو حذف کنه، یا یک آپدیت باعث خراب شدن سرویس بشه.
و یا ممکنه دیتابیس دچار مشکل بشه یا یک مهاجم به سرور دسترسی پیدا کنه و فایلها رو حذف یا رمزگذاری کنه.
در چنین شرایطی، داشتن یک بکاپ سالم میتونه تفاوت بین چند دقیقه اختلال و چند روز دردسر باشه.
نکته مهم اینه که بکاپ گرفتن به تنهایی کافی نیست. بکاپی که خراب باشه یا هیچوقت تست نشده باشه، ممکنه درست زمانی که بهش نیاز دارید، قابل استفاده نباشه.
قانون 3-2-1
یکی از روشهای شناختهشده برای داشتن یک ساختار مناسب بکاپ، قانون 3-2-1 هست.
ایده این قانون سادهست: بهتره حداقل 3 نسخه از اطلاعات داشته باشید، این نسخهها روی حداقل 2 نوع فضای ذخیرهسازی متفاوت قرار بگیرن و حداقل
1 نسخه خارج از سرور یا محل اصلی نگهداری بشه.
مثلا فرض کنید اطلاعات اصلی شما روی یک VPS قرار داره.
یک نسخه بکاپ روی فضای ذخیرهسازی جداگانه نگهداری میشه و یک نسخه دیگه روی یک سرور یا فضای ابری در موقعیت متفاوت قرار میگیره.
دلیل این کار واضحه. اگر بکاپ شما روی همان سروری باشه که اطلاعات اصلی قرار دارن، در صورت خرابی کامل سرور، ممکنه هم اطلاعات اصلی
و هم بکاپ رو با هم از دست بدید.
مثلا نگهداری فایلهای سایت در مسیر اصلی و ذخیره بکاپ در یک پوشه دیگه روی همان هارد، امنیت واقعی ایجاد نمیکنه. این کار فقط در بعضی
شرایط مثل حذف اشتباهی فایلها میتونه مفید باشه.
بکاپ اطلاعات از سرور
جواب این سوال به نوع سرویس شما بستگی داره، اما معمولا فقط بکاپ گرفتن از فایلهای سایت کافی نیست.
اگر یک وبسایت وردپرسی دارید، باید هم فایلها و هم دیتابیس رو در نظر بگیرید. اگر فقط از فایلهای وردپرس بکاپ داشته باشید ولی دیتابیس
از بین بره، اطلاعاتی مثل نوشتهها، کاربران، سفارشها و تنظیمات سایت ممکنه قابل بازیابی نباشن.
در یک سرور کامل، مواردی مثل فایلهای سایت و اپلیکیشن، دیتابیسها، تنظیمات وب سرور، فایلهای کانفیگ سرویسها، تنظیمات DNS در صورت
مدیریت روی همان سرور، اطلاعات کاربران، کلیدهای SSH، تنظیمات فایروال و اسکریپتها یا سرویسهای سفارشی اهمیت زیادی دارن.
البته لازم نیست از همه چیز به یک شکل بکاپ بگیرید.
بعضی اطلاعات روزانه تغییر میکنن و باید مرتب از آنها نسخه پشتیبان تهیه بشه، اما بعضی تنظیمات شاید فقط بعد از هر تغییر مهم نیاز به بکاپ داشته باشن.
انواع بکاپ
بکاپگیری همیشه به معنی کپی کردن تمام اطلاعات در هر مرحله نیست. بسته به حجم دادهها و تعداد تغییرات، میشه از روشهای مختلف استفاده کرد.
بکاپ کامل
در Full Backup، تمام اطلاعات انتخابشده دوباره کپی میشن.
بازیابی این نوع بکاپ معمولا سادهتره، اما به فضای بیشتری نیاز داره و ممکنه زمان بیشتری هم برای تهیه اون لازم باشه.
بکاپ افزایشی
در Incremental Backup، فقط تغییراتی که از آخرین بکاپ ثبت شده ایجاد شدن ذخیره میشن.
این روش میتونه فضای کمتری مصرف کنه و فرآیند بکاپگیری هم سریعتر باشه.
البته برای بازیابی، ممکنه نیاز باشه علاوه بر بکاپ کامل اولیه، نسخههای افزایشی مختلف هم در دسترس باشن.
بکاپ تفاضلی
در Differential Backup، تغییرات نسبت به آخرین بکاپ کامل ذخیره میشن.
این روش از نظر نحوه بازیابی و حجم ذخیرهسازی، معمولا بین بکاپ کامل و افزایشی قرار میگیره.
انتخاب بهترین روش به حجم اطلاعات، میزان تغییرات و اهمیت سرویس شما بستگی داره.
دوره بکاپگیری
در جواب به این سوال که هر چند وقت یکبار بکاپ بگیریم، باید گفت که هیچ عدد ثابت و یکسانی برای همه سرورها وجود نداره.
مثلا یک سایت شرکتی که ماهی چند بار محتوای اون تغییر میکنه، احتمالا به بکاپ ساعتی نیاز نداره.
اما یک فروشگاه اینترنتی که در طول روز سفارشهای زیادی دریافت میکنه، شرایط کاملا متفاوتی داره.
فرض کنید فروشگاه شما هر ساعت دهها سفارش جدید ثبت میکنه.
اگر فقط روزی یک بار بکاپ بگیرید و سرور عصر دچار مشکل بشه، ممکنه تمام سفارشهای ثبتشده بعد از آخرین بکاپ از بین برن.
در چنین شرایطی، بکاپ دیتابیس میتونه با فاصله زمانی کوتاهتری انجام بشه، در حالی که فایلهای سایت شاید نیازی به بکاپ ساعتی نداشته باشن.
پس زمانبندی بکاپ باید براساس میزان تغییر اطلاعات و اهمیت آنها مشخص بشه.
RPO و RTO در Disaster Recovery چیست؟
وقتی صحبت از Disaster Recovery میشه، معمولا با دو مفهوم مهم روبهرو میشیم: RPO و RTO.
RPO مشخص میکنه شما حداکثر چقدر از اطلاعات جدید رو حاضر هستید در یک بحران از دست بدید.
مثلا اگر RPO شما یک ساعت باشه، یعنی سیستم بکاپ باید طوری طراحی شده باشه که در بدترین حالت، بیشتر از یک ساعت اطلاعات از دست نره.
RTO هم مشخص میکنه چقدر زمان برای بازگرداندن سرویس قابل قبوله.
برای مثال، اگر RTO چهار ساعت باشه، برنامه Disaster Recovery شما باید به شکلی طراحی شده باشه که سرویس حداکثر تا چهار ساعت بعد از وقوع بحران دوباره فعال بشه.
این دو مورد کمک میکنن برنامه بکاپ و بازیابی شما براساس نیاز واقعی کسبوکار طراحی بشه.
محل نگهداری بکاپ
یکی از اشتباهات رایج اینه که بکاپها فقط روی همان سرور اصلی نگهداری میشن.
بهتره بکاپ در یک محل جداگانه قرار بگیره. این محل میتونه یک سرور بکاپ مستقل، فضای ذخیرهسازی ابری یا یک موقعیت فیزیکی متفاوت باشه.
اگر سرور اصلی دچار خرابی کامل، حذف اطلاعات یا حمله باج افزاری بشه، داشتن نسخهای جدا از محیط اصلی اهمیت زیادی پیدا میکنه.
برای سرویسهای مهم، بهتره به این فکر کنید که اگر کل سرور اصلی دیگر در دسترس نبود، آیا همچنان میتونید به بکاپ خودتون دسترسی داشته باشید یا نه.
اگر جواب این سوال منفی باشه، ساختار بکاپ شما نیاز به بازبینی داره.
تست بکاپها
بکاپی که تست نشده، نباید صد درصد قابل اعتماد در نظر گرفته بشه.
ممکنه فرآیند بکاپ ظاهرا بدون خطا انجام بشه، اما فایل خروجی ناقص باشه.
ممکنه هنگام بازیابی با مشکل مواجه بشید یا نسخه بکاپ با تنظیمات فعلی سرویس سازگار نباشه.
به همین دلیل بهتره هر چند وقت یکبار فرآیند Restore رو در یک محیط آزمایشی امتحان کنید.
مثلا یک سرور تست راهاندازی کنید، بکاپ رو روی اون بازیابی کنید و بررسی کنید که سایت، دیتابیس و سرویسهای مهم واقعا درست کار میکنن.
این کار شاید در نگاه اول وقتگیر به نظر برسه، اما بهتر از اینه که روز حادثه برای اولین بار متوجه بشید بکاپ شما قابل استفاده نیست.
Disaster Recovery Plan شامل چه چیزهاییه؟
یک Disaster Recovery Plan یا برنامه بازیابی پس از بحران، لازم نیست حتما یک سند پیچیده و چندصدصفحهای باشه.
حتی برای یک کسبوکار کوچک هم میشه یک برنامه ساده و کاربردی داشت.
مهم اینه که مشخص باشه در زمان بروز مشکل چه کسی مسئول انجام کارهاست، بکاپها کجا هستن، مراحل بازیابی چیه و کدام سرویسها باید در اولویت قرار بگیرن.
مثلا اگر یک شرکت چند سرویس مختلف داشته باشه، شاید ابتدا لازم باشه دیتابیس اصلی و وبسایت بازیابی بشن و سرویسهای کماهمیتتر در مرحله بعد قرار بگیرن.
بهتره در برنامه Disaster Recovery اطلاعات مهم مثل روش دسترسی به بکاپ، مراحل نصب سرویسها، تنظیمات ضروری، ترتیب بازیابی و اطلاعات تماس مسئولان ثبت شده باشه.
هدف اینه که در زمان بحران، همه چیز به حافظه افراد وابسته نباشه.
فرض کنید یک فروشگاه اینترنتی روی سرور خودش دچار حمله باج افزاری شده و بخش زیادی از فایلها غیرقابل استفاده شدن.
اگر برنامه مشخصی وجود نداشته باشه، ممکنه تیم ساعتها صرف بررسی مشکل کنه و تازه بعد از اون به فکر پیدا کردن آخرین بکاپ بیفته.
اما در یک سناریوی درست Disaster Recovery، روند میتونه به این شکل باشه که ابتدا سرور آسیبدیده از شبکه جدا میشه تا مشکل بیشتر نشه.
سپس یک سرور جدید یا محیط جایگزین آماده میشه.
سیستم عامل و سرویسهای ضروری نصب میشن، آخرین بکاپ سالم بازیابی میشه و پس از بررسی صحت اطلاعات، سرویس دوباره در دسترس کاربران قرار میگیره.
اگر از قبل مشخص شده باشه که این مراحل توسط چه افرادی و با چه ترتیبی انجام میشه، زمان قطعی سرویس به شکل قابل توجهی کاهش پیدا میکنه.
طراحی برنامه بکاپ و Disaster Recovery مناسب
اول از همه باید مشخص کنید چه اطلاعات و سرویسهایی برای شما حیاتی هستن. همه فایلها لزوما ارزش یکسانی ندارن.
بعد باید بررسی کنید اگر این اطلاعات از بین برن، حداکثر چقدر داده قابل از دست رفتنه و سرویس چقدر میتونه قطع بمونه. اینجا همون RPO و RTO به شما کمک میکنن.
در مرحله بعد باید مشخص کنید بکاپها با چه فاصله زمانی گرفته میشن و کجا ذخیره میشن. بهتره حداقل یک نسخه از بکاپ خارج از سرور اصلی نگهداری بشه.
بعد از اون، فرآیند بازیابی رو مستند کنید. یعنی اگر فردا مجبور شدید کل سرور رو از ابتدا راهاندازی کنید، دقیقا بدونید از کجا باید شروع کنید.
و مهمتر از همه، این برنامه رو تست کنید. Disaster Recovery Plan فقط وقتی ارزش واقعی داره که در شرایط واقعی یا شبیهسازیشده قابل اجرا باشه.
اشتباه رایج…
یکی از رایجترین اشتباهها اینه که فکر کنیم بکاپ گرفتن انجام شده، پس همه چیز امنه! در حالی که باید بررسی کنید بکاپ کامل، سالم و قابل بازیابی هست یا نه.
اشتباه دیگه، نگهداری تمام نسخههای بکاپ روی همان سرور اصلیه. اگر سرور به طور کامل از دسترس خارج بشه، ممکنه بکاپ هم همراه اون از بین بره.
بعضی افراد هم فقط از فایلها بکاپ میگیرن و دیتابیس یا تنظیمات مهم رو فراموش میکنن.
مشکل دیگه، وابسته بودن کامل فرآیند بازیابی به یک نفره.
اگر فقط یک مدیر سرور بدونه چطور سرویس رو برگردونه، نبودن اون فرد در زمان بحران میتونه خودش تبدیل به یک مشکل جدید بشه.
بهتره مراحل ضروری مستند باشن و افراد مسئول به اطلاعات لازم دسترسی داشته باشن.
آیا Snapshot جای بکاپ رو میگیره؟
Snapshot میتونه ابزار بسیار مفیدی باشه، اما همیشه نباید اون رو جایگزین کامل بکاپ در نظر گرفت.
اسنپشات معمولا برای برگرداندن سریع یک ماشین یا سرور به وضعیت قبلی کاربرد داره.
مثلا قبل از انجام یک آپدیت مهم، میتونید Snapshot تهیه کنید تا اگر مشکلی پیش اومد، سریعتر به وضعیت قبل برگردید.
اما اگر Snapshot روی همان زیرساخت اصلی نگهداری بشه و آن زیرساخت دچار مشکل جدی بشه، ممکنه Snapshot هم در دسترس نباشه.
به همین دلیل، Snapshot میتونه بخشی از استراتژی محافظت از اطلاعات شما باشه، اما داشتن بکاپ مستقل همچنان اهمیت خودش رو داره.
امنیت بکاپها
بکاپها معمولا شامل مهمترین اطلاعات شما هستن. دیتابیس، فایلهای کاربران، تنظیمات و گاهی اطلاعات حساس داخل نسخههای پشتیبان قرار میگیرن.
به همین دلیل، بکاپ باید از نظر امنیتی هم محافظت بشه.
دسترسی به محل نگهداری بکاپها باید محدود باشه و بهتره از رمزنگاری برای اطلاعات حساس استفاده بشه. همچنین دسترسیهای غیرضروری باید حذف بشن.
اگر مهاجم بتونه هم به سرور اصلی و هم به تمام بکاپها دسترسی پیدا کنه، ممکنه کل استراتژی بازیابی شما بیفایده بشه.
برای همین بهتره حسابها و دسترسیهای مربوط به بکاپ تا حد امکان از محیط اصلی جدا باشن.
نتیجهگیری
اگر بخوایم تمام این مقاله رو در یک جمله خلاصه کنیم، پاسخ به سوال Disaster Recovery چیست اینه که Disaster Recovery یعنی از قبل
آماده باشید تا اگر اتفاق بدی برای سرور و اطلاعات شما افتاد، بتونید با کمترین میزان از دست رفتن داده و در کوتاهترین زمان ممکن سرویس رو دوباره راهاندازی کنید.
بکاپگیری بخش مهمی از این فرآینده، اما همه چیز نیست.
شما باید بدونید چه اطلاعاتی رو بکاپ میگیرید، چند نسخه از اونها دارید، بکاپها کجا نگهداری میشن و در زمان بروز مشکل دقیقا چطور باید اطلاعات و سرویسها رو بازیابی کنید.
یک برنامه ساده اما تستشده، معمولا خیلی ارزشمندتر از یک سیستم پیچیدهایه که هیچکس مطمئن نیست در زمان بحران واقعا کار میکنه یا نه.
پس بهتره قبل از اینکه با حذف اطلاعات، خرابی سرور یا حمله سایبری روبهرو بشید، برنامه بکاپ و Disaster Recovery خودتون رو آماده و تست کنید.
اگر این مطلب برایتان مفید بود، پیشنهاد میکنیم به مقاله چگونه مصرف CPU و RAM سرور را کاهش دهیم؟ نیز در بلاگ ما سر بزنید.
سوالات متداول
Disaster Recovery چیست؟
بازیابی پس از بحران یا Disaster Recovery، مجموعهای از برنامهها و اقدامات برای بازگرداندن اطلاعات و سرویسها بعد از اتفاقاتی مثل
خرابی سرور، حمله سایبری، حذف اطلاعات یا مشکلات زیرساختیه.
آیا بکاپ گرفتن به تنهایی برای Disaster Recovery کافی است؟
نه همیشه. بکاپ فقط نسخهای از اطلاعات شماست.
برای Disaster Recovery باید روش بازیابی سرور، سرویسها، تنظیمات و مراحل بازگرداندن کل سیستم هم مشخص باشه.
هر چند وقت یکبار باید از سرور بکاپ بگیریم؟
این موضوع به میزان تغییر اطلاعات بستگی داره. یک سایت کمتغییر ممکنه به بکاپ روزانه یا هفتگی نیاز داشته باشه،
اما فروشگاهها و سرویسهای پرترافیک ممکنه به بکاپهای ساعتی یا حتی زمانبندی کوتاهتر نیاز داشته باشن.
بهترین محل برای نگهداری بکاپ کجاست؟
بهتره حداقل یک نسخه از بکاپ خارج از سرور اصلی نگهداری بشه.
میتونید از سرور بکاپ جداگانه یا فضای ذخیرهسازی مستقل استفاده کنید تا در صورت خرابی کامل سرور اصلی، نسخه پشتیبان همچنان در دسترس باشه.
آیا باید بکاپها را تست کنیم؟
بله. بهتره به صورت دورهای یک نسخه بکاپ رو در محیط آزمایشی بازیابی کنید تا مطمئن بشید فایلها و اطلاعات واقعا قابل استفاده هستن.
تفاوت Snapshot و Backup چیست؟
Snapshot معمولا برای بازگرداندن سریع یک سرور یا ماشین به وضعیت قبلی کاربرد داره، اما بکاپ مستقل میتونه برای نگهداری و بازیابی اطلاعات در
سناریوهای مختلف قابل اعتمادتر باشه. بهتره Snapshot رو مکمل بکاپ در نظر بگیرید، نه جایگزین کامل اون.
RPO و RTO چه ارتباطی با Disaster Recovery دارند؟
RPO مشخص میکنه حداکثر چه مقدار اطلاعات قابل از دست رفتنه و RTO مشخص میکنه سرویس حداکثر چه مدت میتونه از دسترس خارج باشه. این دو
معیار به شما کمک میکنن استراتژی بکاپ و Disaster Recovery مناسبی طراحی کنید.