تفاوت RAID و بکاپ در مسئله‌ای است که حل می‌کنند: بعضی سطح‌های RAID برای ادامه کار در برابر خرابی تعدادی از دیسک‌ها طراحی شده‌اند، در حالی که بکاپ نسخه‌ای برای بازگرداندن داده در زمان نیاز فراهم می‌کند. اگر فایل اشتباهی حذف شود، آینه سالم RAID نیز می‌تواند همان حذف را دریافت کند؛ داشتن چند دیسک، تاریخچه قابل بازیابی نمی‌سازد.
برای خرید یا مدیریت یک سرور اختصاصی، باید بدانید چه مقدار فضای مفید خواهید داشت، خرابی چه اجزایی قابل تحمل است و در کدام رخداد به نسخه مستقل نیاز دارید. در این راهنما، مقایسه با مثال‌های فرضی انجام می‌شود و ظرفیت‌ها قبل از سربار فایل‌سیستم و تفاوت واحدهای نمایش محاسبه شده‌اند.
RAID چه کاری انجام می‌دهد؟
RAID چند دیسک را با یک آرایش مشخص در اختیار سیستم قرار می‌دهد. بسته به سطح انتخابی، داده می‌تواند میان دیسک‌ها تقسیم، آینه یا با اطلاعات افزونگی نگهداری شود. هدف‌ها متفاوت‌اند: ظرفیت، عملکرد و تحمل خرابی همیشه هم‌زمان و به یک اندازه افزایش پیدا نمی‌کنند. برای مثال، RAID 0 افزونگی ندارد؛ بنابراین نمی‌توان گفت هر چیزی که RAID نام دارد، در برابر خرابی دیسک محافظت می‌کند.
در لینوکس، پیاده‌سازی نرم‌افزاری MD و ابزارهای مرتبط امکان مدیریت آرایه را فراهم می‌کنند. مستندات رسمی RAID در کرنل لینوکس وضعیت‌هایی مانند آرایه فعال، بازسازی و شرایط کاهش افزونگی را توضیح می‌دهد. برای تصمیم خرید، دانستن نام سطح کافی نیست؛ نوع پیاده‌سازی، آرایش واقعی اعضا و روش دریافت هشدار هم باید روشن باشد.
بکاپ چه چیزی به این طراحی اضافه می‌کند؟
بکاپ به شما امکان می‌دهد نسخه‌ای از داده را از یک نقطه زمانی مشخص برگردانید، مشروط بر اینکه نسخه سالم، در دسترس و قابل بازیابی باشد. این نسخه می‌تواند در برابر برخی خطاهای انسانی یا خرابی منطقی کمک کند؛ اما اگر تنها بکاپ روی همان دستگاه و با همان دسترسی آسیب‌پذیر قرار داشته باشد، استقلال کافی ندارید.
برای نمونه، یک فروشگاه با دو دیسک آینه‌شده را تصور کنید. خرابی یکی از اعضا ممکن است با ادامه کار آرایه مدیریت شود، ولی اجرای دستور اشتباه در دیتابیس روی داده فعال اثر می‌گذارد. برای بازگشت به قبل از تغییر، به بکاپ یا راهکار بازیابی نقطه‌ای سازگار با دیتابیس نیاز دارید. راهنمای بکاپ خارج از VPS و نگهداری نسخه‌ها جزئیات طراحی مقصد مستقل را پوشش می‌دهد.
مقایسه سطح‌های RAID و ظرفیت قابل استفاده
جدول زیر برای آرایش‌های متداول با دیسک‌های هم‌اندازه است. در عمل، ظرفیت عضو کوچک‌تر، متادیتا، پارتیشن‌بندی و پیاده‌سازی نیز اثر دارند. منظور از تحمل خرابی، خرابی اعضای آرایه در شرایط معمول است؛ تضمین حفاظت در برابر همه انواع خرابی نیست.
| آرایش | نمونه دیسک‌ها | ظرفیت تقریبی پیش از سربار | نکته تحمل خرابی |
|---|---|---|---|
| RAID 0 | دو دیسک ۲ ترابایتی | ۴ ترابایت | تحمل خرابی عضو ندارد |
| RAID 1 دو عضوی | دو دیسک ۲ ترابایتی | ۲ ترابایت | از دست رفتن یک عضو را تحمل می‌کند |
| RAID 5 | چهار دیسک ۲ ترابایتی | ۶ ترابایت | تحمل خرابی یک عضو |
| RAID 6 | چهار دیسک ۲ ترابایتی | ۴ ترابایت | تحمل خرابی دو عضو |
| RAID 10 متداول | چهار دیسک ۲ ترابایتی در دو جفت آینه | ۴ ترابایت | تحمل بیش از یک خرابی به محل اعضای خراب وابسته است |
در مثال RAID 10، اگر هر دو عضو یک جفت آینه از بین بروند، سالم بودن جفت دیگر داده آن جفت را نجات نمی‌دهد. پس عبارت «چهار دیسک داریم و همیشه دو خرابی را تحمل می‌کنیم» دقیق نیست. همچنین آرایش‌های نرم‌افزاری می‌توانند جزئیات متفاوتی داشته باشند؛ پیش از تغییر یا خرید، طرح واقعی را از مدیر سیستم بگیرید.
تفاوت RAID و بکاپ در پنج سناریوی عملی
خرابی یک دیسک فیزیکی
در آرایش دارای افزونگی کافی، احتمال ادامه سرویس وجود دارد. باید عضو خراب شناسایی، دیسک مناسب جایگزین و بازسازی کنترل شود. دسترس‌پذیری برنامه در این مدت به کل سامانه وابسته است؛ کنترلر، سیستم‌عامل یا روش بوت هم می‌توانند بر نتیجه اثر بگذارند. بکاپ در این وضعیت لایه بازیابی تکمیلی است.
حذف یا بازنویسی اشتباهی فایل
RAID معمولاً تاریخچه فایل حذف‌شده را ارائه نمی‌کند. اگر عمل حذف روی فضای فعال اجرا شود، افزونگی نیز وضعیت تازه را منعکس می‌کند. بکاپ دارای نسخه‌های زمانی می‌تواند کمک کند، به شرط اینکه نسخه پیش از رخداد هنوز حفظ شده باشد و فایل موردنظر در دامنه بکاپ قرار گرفته باشد.
آلودگی یا دسترسی غیرمجاز
اگر مهاجم توان تغییر داده و بکاپ با یک حساب را داشته باشد، داشتن کپی بیشتر به‌تنهایی کافی نیست. جداسازی دسترسی، نسخه‌های با نگهداری محافظت‌شده و کنترل مستقل مقصد باید متناسب با نیاز طراحی شوند. RAID مرز امنیتی میان نسخه سالم و داده دستکاری‌شده ایجاد نمی‌کند.
خرابی کامل دستگاه یا خروج از دسترس محل استقرار
آرایه‌ای که تمام اعضای آن داخل همان سرور است، به خرابی دستگاه یا از دست رفتن دسترسی به آن وابسته می‌ماند. نسخه مستقل می‌تواند مسیر بازیابی روی مقصد تازه فراهم کند. برای سامانه‌ای که قطعی بسیار کمی تحمل می‌کند، علاوه بر بکاپ به طراحی افزونگی سرویس و روش جابه‌جایی ترافیک هم نیاز دارید.
خرابی منطقی پایگاه داده
سالم بودن دیسک به معنی درست بودن محتوای دیتابیس نیست. نسخه پشتیبان باید با موتور پایگاه داده و روش ثبت تغییرات سازگار باشد. کپی ساده فایل دیتابیس فعال، بدون توجه به سازگاری داده، ممکن است قابل بازیابی نباشد. آزمون راه‌اندازی دیتابیس و اجرای چند عملیات واقعی، از مشاهده وجود یک فایل آرشیو معتبرتر است.
بازسازی RAID چرا به پایش نیاز دارد؟
بعد از جایگزینی عضو، آرایه ممکن است برای بازسازی اطلاعات به خواندن و نوشتن گسترده نیاز داشته باشد. زمان و اثر این عملیات به ظرفیت، بار جاری، وضعیت اعضا و پیاده‌سازی وابسته است؛ عدد ثابتی برای همه سرورها وجود ندارد. در زمان کاهش افزونگی، خرابی بعدی می‌تواند پیامد جدی‌تری داشته باشد.
هشدار باید به فرد پاسخ‌گو برسد و فقط داخل یک پنل باقی نماند. وضعیت آرایه، خطاهای دیسک و پایان بازسازی را کنترل کنید. در بعضی معماری‌ها دیسک یدکی می‌تواند شروع بازسازی را سریع‌تر کند، اما جایگزین پایش و تعویض عضو معیوب نیست. برای سرور هتزنر، راهنمای رسمی Software RAID را متناسب با سیستم‌عامل و پیکربندی مطالعه کنید.
RAID سخت‌افزاری بهتر است یا نرم‌افزاری؟
پاسخ به نیاز برنامه، ابزار مدیریت، امکانات کنترلر و مهارت تیم بستگی دارد. کنترلر سخت‌افزاری می‌تواند امکانات خاصی ارائه دهد، ولی وضعیت کش، حفاظت توان و سناریوی خرابی خود کنترلر باید بررسی شود. پیاده‌سازی نرم‌افزاری نیز به تنظیم درست سیستم‌عامل، روش بوت و مانیتورینگ نیاز دارد. هیچ‌کدام بکاپ مستقل را حذف نمی‌کنند.
در انتخاب، روش تعویض دیسک، امکان دسترسی به وضعیت سلامت و فرآیند انتقال آرایه را بپرسید. مقایسه سرعت باید با الگوی خواندن و نوشتن نزدیک به برنامه انجام شود؛ نتیجه یک آزمایش ترتیبی بزرگ را به دیتابیس دارای درخواست‌های کوچک و تصادفی تعمیم ندهید. برای انتخاب کلی دستگاه، راهنمای سرور اختصاصی هتزنر آلمان و فنلاند مکمل این مطلب است.
چک‌لیست طراحی حفاظت از داده سرور
- خرابی‌هایی را که باید پوشش دهید فهرست کنید: دیسک، حذف انسانی، خرابی برنامه یا از دست رفتن دستگاه.
- فضای مفید، نیاز عملکرد و آرایش واقعی اعضای RAID را محاسبه کنید.
- دریافت هشدار، مسئول تعویض و کنترل پایان بازسازی را مشخص کنید.
- بکاپ را با دامنه داده روشن، نسخه‌های زمانی و دسترسی مستقل طراحی کنید.
- زمان قابل تحمل از دست رفتن داده و مدت بازیابی را تعیین کنید.
- بازیابی را روی مقصد جدا آزمایش و نتیجه را ثبت کنید.
اگر مثال فرضی شما اجازه از دست رفتن حداکثر یک ساعت داده را می‌دهد، بکاپ روزانه به‌تنهایی با آن هدف هم‌خوان نیست. همچنین اگر بارگذاری نسخه روی سرور تازه چند ساعت طول می‌کشد، داشتن آرشیو سالم الزام قطعی کوتاه را برآورده نمی‌کند. فاصله نسخه‌ها و روش بازگشت سرویس باید با هدف عملیاتی هماهنگ شوند.
پرسش‌های متداول
آیا RAID 1 همان بکاپ لحظه‌ای است؟
خیر؛ آینه نسخه فعلی داده را نگه می‌دارد و معمولاً امکان انتخاب تاریخ قبل از حذف فایل را نمی‌دهد. بکاپ نسخه زمانی و مسیر بازیابی جداگانه می‌خواهد.
آیا Snapshot به‌جای بکاپ کافی است؟
Snapshot برای برخی سناریوهای بازگشت مفید است، اما استقلال آن به معماری وابسته است. اگر فقط به همان ذخیره‌ساز وابسته باشد، خرابی آن ذخیره‌ساز می‌تواند هر دو را تحت تأثیر قرار دهد. روش خروج نسخه و آزمون بازیابی را بررسی کنید.
کدام RAID برای فروشگاه مناسب‌تر است؟
از روی نام فروشگاه نمی‌توان یک سطح ثابت توصیه کرد. حجم داده، نرخ نوشتن، تعداد دیسک، مدت قابل تحمل اختلال و بودجه مهم‌اند. طرح ذخیره‌سازی و بکاپ را همراه با بار دیتابیس ارزیابی کنید.
از نام فناوری به سناریوی بازیابی برسید
تفاوت RAID و بکاپ زمانی روشن می‌شود که بپرسید «اگر این اتفاق بیفتد، چگونه برمی‌گردیم؟». پاسخ باید دستگاه مقصد، نسخه قابل استفاده، مسئول عملیات و آزمون سلامت داده را مشخص کند. برای بررسی پیکربندی و برنامه نگهداری، خدمات مدیریت سرور آفاق هاست را ببینید و دامنه حفاظت از اطلاعات را پیش از شروع همکاری روشن کنید.
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.