محصولات آکو
HPE
DELL
Broadcom
خدمات آکو
بلاگ
دانلود
HPE
DELL
Broadcom
Vmware
درباره ما
ارتباط با ما
در انتخاب میان RAID نرم‌افزاری و RAID سخت‌افزاری برای دیتاسنتر، پاسخ واحدی برای همه زیرساخت‌ها وجود ندارد. RAID سخت‌افزاری در سرورهای سازمانی مبتنی بر SAS/SATA، به‌ویژه زمانی که مدیریت متمرکز، Write-back Cache محافظت‌شده و جداسازی پردازش RAID از CPU اهمیت دارد، همچنان انتخاب قدرتمندی است. در مقابل، RAID نرم‌افزاری و راهکارهای RAID مجتمع با CPU می‌توانند در زیرساخت‌های مدرن، به‌خصوص محیط‌های NVMe و معماری‌های Software-Defined، عملکرد و انعطاف‌پذیری بسیار بالایی ارائه دهند. انتخاب نهایی باید بر اساس نوع Drive، سطح RAID، الگوی I/O، قابلیت بازیابی، الزامات دسترس‌پذیری و مدل عملیاتی دیتاسنتر انجام شود.
- RAID سخت‌افزاری الزاماً در همه Workloadها سریع‌تر از RAID نرم‌افزاری نیست؛ معماری I/O و نوع Drive تعیین‌کننده‌اند.
- کنترلرهای سخت‌افزاری حرفه‌ای می‌توانند Write-back Cache محافظت‌شده، Hot Spare، مدیریت خطا و قابلیت‌های عملیاتی پیشرفته ارائه دهند.
- RAID نرم‌افزاری مدرن فقط مخصوص آزمایشگاه یا کسب‌وکار کوچک نیست و در معماری‌های Enterprise نیز قابل استفاده است.
- برای NVMe، عبور مستقیم I/O از PCIe و حذف کنترلر واسط در بعضی معماری‌ها می‌تواند مزیت مهمی باشد.
- RAID سطح دسترس‌پذیری در برابر خرابی Drive را افزایش می‌دهد، اما جایگزین Backup، Disaster Recovery یا کنترل‌های امنیت سایبری نیست.
- قبل از انتخاب، باید سناریوی خرابی Controller، Rebuild، مهاجرت آرایه، مانیتورینگ و توسعه ظرفیت نیز بررسی شود.
- RAID چیست و تفاوت دو پیاده‌سازی از کجا شروع می‌شود؟
- مقایسه RAID نرم‌افزاری و سخت‌افزاری
- تفاوت عملکرد، IOPS و Latency
- مزایا و محدودیت‌های هر روش
- کدام RAID برای چه سناریویی مناسب‌تر است؟
- سطح RAID چه تأثیری بر انتخاب دارد؟
- چک‌لیست انتخاب RAID در دیتاسنتر
- اشتباهات رایج در طراحی RAID
- مطالب، محصولات و خدمات مرتبط
- جمع‌بندی؛ RAID سخت‌افزاری بهتر است یا نرم‌افزاری؟
- سوالات متداول
RAID چیست و تفاوت دو پیاده‌سازی از کجا شروع می‌شود؟
RAID یا Redundant Array of Independent Disks روشی برای ترکیب چند Drive در قالب یک یا چند فضای منطقی است تا بسته به سطح RAID، اهدافی مانند افزایش کارایی، تحمل خرابی یا ترکیبی از ظرفیت و افزونگی تأمین شود. البته همه سطوح RAID افزونگی ندارند؛ برای مثال RAID 0 تنها Striping ایجاد می‌کند و خرابی یک Drive می‌تواند کل آرایه را از دسترس خارج کند.
تفاوت اصلی RAID نرم‌افزاری و سخت‌افزاری در محل اجرای منطق RAID است. در RAID نرم‌افزاری، بخش عمده مدیریت آرایه توسط سیستم‌عامل، Driver یا پردازنده میزبان انجام می‌شود؛ در RAID سخت‌افزاری، یک Controller اختصاصی بین سیستم‌عامل و Driveها قرار می‌گیرد و Logical Volume را به سیستم ارائه می‌کند.
RAID نرم‌افزاری چگونه کار می‌کند؟
در Software RAID معمولاً سیستم‌عامل یا یک لایه نرم‌افزاری وظایفی مانند Striping، Mirroring و محاسبه Parity را مدیریت می‌کند. در Linux نمونه شناخته‌شده آن MD RAID است و در پلتفرم‌های سروری نیز راهکارهای Vendor-specific برای RAID نرم‌افزاری یا RAID مجتمع وجود دارند.
این مدل بخشی از منابع CPU و حافظه سیستم را مصرف می‌کند، اما میزان سربار به سطح RAID، قدرت پردازنده، نوع Drive، اندازه I/O، Queue Depth و پیاده‌سازی نرم‌افزار بستگی دارد. بنابراین نمی‌توان به‌صورت کلی نتیجه گرفت که Software RAID در هر بار کاری سنگینی باعث افت محسوس عملکرد می‌شود.
RAID سخت‌افزاری چگونه کار می‌کند؟
در Hardware RAID یک Controller اختصاصی مانند خانواده‌های Dell PERC، HPE Smart Array یا کنترلرهای مبتنی بر MegaRAID وظایف RAID را مدیریت می‌کند. سیستم‌عامل معمولاً به‌جای مشاهده مستقیم تمام Driveها، Virtual Disk یا Logical Drive ایجادشده توسط Controller را می‌بیند.
مدل‌های حرفه‌ای Controller ممکن است دارای حافظه Cache اختصاصی، پردازش Parity، Hot Spare Management، Patrol Read، ابزارهای مانیتورینگ و مکانیزم‌های محافظت از Cache باشند. امکانات دقیق به مدل Controller، Firmware، License و پیکربندی بستگی دارد.
RAID با Backup و امنیت اطلاعات تفاوت دارد
RAID عمدتاً برای Availability و تحمل خرابی Drive طراحی شده است، نه برای محافظت در برابر تمام سناریوهای از دست رفتن داده. حذف تصادفی فایل، Corruption منطقی، Ransomware، خطای نرم‌افزاری یا خرابی گسترده یک سیستم ممکن است روی تمام اعضای آرایه اثر بگذارد.
حتی یک آرایه RAID کاملاً Redundant نیز باید بخشی از یک استراتژی Backup و Recovery مستقل باشد. برای طراحی لایه بازیابی می‌توانید خدمات پشتیبان‌گیری و بازیابی اطلاعات آکو را نیز بررسی کنید.
مقایسه RAID نرم‌افزاری و سخت‌افزاری
برای دیتاسنتر، مقایسه صرفاً بر اساس «سرعت بیشتر» یا «قیمت کمتر» کافی نیست. تفاوت اصلی زمانی مشخص می‌شود که هزینه Controller، نحوه مدیریت Cache، سربار CPU، قابلیت تعویض سخت‌افزار، سازگاری سیستم‌عامل، NVMe، مانیتورینگ و Recovery هم‌زمان بررسی شوند.
| معیار | RAID نرم‌افزاری | RAID سخت‌افزاری |
|---|---|---|
| محل پردازش RAID | CPU و لایه نرم‌افزاری یا سیستم‌عامل میزبان | Controller اختصاصی |
| هزینه سخت‌افزار | معمولاً کمتر | به Controller و Cache اختصاصی نیاز دارد |
| مصرف CPU میزبان | وابسته به سطح RAID و Workload | بخش مهمی از عملیات RAID از Host CPU جدا می‌شود |
| Write-back Cache | وابسته به معماری سیستم‌عامل و Storage Stack | در Controllerهای مجهز به Cache محافظت‌شده قابل استفاده است |
| NVMe | می‌تواند از اتصال مستقیم PCIe بهره ببرد و در برخی معماری‌ها بسیار مقیاس‌پذیر باشد | به مدل Controller، تعداد Laneها، تعداد Drive و نسل PCIe وابسته است |
| وابستگی به Vendor | بیشتر وابسته به سیستم‌عامل، Driver و فرمت Metadata است | ممکن است برای Recovery به Controller سازگار از همان خانواده نیاز باشد |
| مانیتورینگ | از ابزارهای سیستم‌عامل و Management Stack استفاده می‌کند | معمولاً با ابزارهای مدیریتی Vendor یکپارچه است |
| سناریوی متداول | Software-Defined Storage، NVMe، سرورهای Cost-sensitive و معماری‌های مبتنی بر OS | سرورهای Enterprise با SAS/SATA و نیاز به مدیریت ساده و Controller-centric |
تفاوت عملکرد، IOPS و Latency در RAID نرم‌افزاری و سخت‌افزاری
عملکرد RAID حاصل تعامل چند عامل است: Drive، Interface، Queue Depth، Controller یا Software Stack، سطح RAID، Read/Write Ratio، اندازه Block، Cache Policy و تعداد Driveها. به همین دلیل، نوع RAID به‌تنهایی برای پیش‌بینی IOPS یا Latency کافی نیست.
تأثیر RAID نرم‌افزاری بر CPU
Software RAID برای پردازش Metadata، Mirroring یا Parity از منابع Host استفاده می‌کند. RAID 1 یا RAID 10 معمولاً منطق ساده‌تری نسبت به RAID 5 و RAID 6 دارند؛ در RAIDهای Parity-based علاوه بر I/O، محاسبات و عملیات اضافی برای Parity نیز وجود دارد.
با این حال، در سرورهای مدرن دارای پردازنده‌های چند‌هسته‌ای، سربار CPU لزوماً به معنای Bottleneck نیست. در بعضی محیط‌های NVMe حتی حذف Controller واسط و دسترسی مستقیم‌تر به SSDها می‌تواند نسبت به معماری Hardware RAID مزیت ایجاد کند. نتیجه واقعی باید با Benchmark متناسب با Workload سنجیده شود.
نقش Controller Cache در RAID سخت‌افزاری
یکی از مزیت‌های مهم برخی کنترلرهای RAID سخت‌افزاری، Write-back Cache است. در این حالت Controller می‌تواند پس از دریافت داده در Cache، تکمیل Write را به Host اعلام کند و نوشتن روی Drive را در ادامه مدیریت کند. این قابلیت به‌ویژه در Workloadهایی با Writeهای کوچک یا تصادفی می‌تواند Latency نوشتن را کاهش دهد.
با این حال، Write-back Cache زمانی باید برای داده‌های حساس استفاده شود که مکانیزم مناسبی برای حفظ داده Cache در قطع برق وجود داشته باشد. بسته به نسل Controller، این حفاظت می‌تواند به شکل Battery-backed یا Flash-backed Cache به همراه Energy Pack پیاده‌سازی شود.
تأثیر Controller Cache روی SSD و NVMe به Workload و Controller بستگی دارد. حتی در برخی کنترلرهای Enterprise، یک Virtual Disk مبتنی بر SSD ممکن است از Cache سنتی Controller سود محدودی ببرد. بنابراین Cache Policy باید بر اساس تست، نوع Drive و توصیه Vendor تنظیم شود.
IOPS، Throughput و Latency را جداگانه بررسی کنید
افزایش IOPS الزاماً به معنای کاهش Latency در تمام شرایط نیست. همچنین آرایه‌ای که در Sequential Throughput بسیار سریع است ممکن است در Random Write رفتار متفاوتی داشته باشد. برای طراحی دقیق، شاخص‌های Average Latency، Tail Latency، IOPS، Throughput و رفتار سیستم هنگام Rebuild باید جداگانه سنجیده شوند.
برای درک عوامل مؤثر بر تأخیر در کل زنجیره I/O، مقاله نحوه محاسبه Storage Latency می‌تواند مکمل این مقایسه باشد.
RAID برای SSD و NVMe چه تفاوتی دارد؟
این تصور که برای استفاده کامل از NVMe حتماً باید Hardware RAID داشت، دقیق نیست. RAID نرم‌افزاری، RAID مجتمع با CPU و فناوری‌هایی که SSDهای NVMe را مستقیماً به PCIe متصل می‌کنند می‌توانند در طراحی‌های Enterprise نیز استفاده شوند.
از طرف دیگر، Hardware RAID برای NVMe نیز در بسیاری از سرورها وجود دارد و مزایای مدیریتی خود را ارائه می‌کند. سؤال اصلی این است که آیا Controller می‌تواند Queue Depth، تعداد SSD، نسل PCIe و Throughput موردنیاز Workload را بدون ایجاد Bottleneck مدیریت کند یا خیر.
مزایا و محدودیت‌های RAID نرم‌افزاری و سخت‌افزاری
مزایای RAID نرم‌افزاری
- عدم نیاز به RAID Controller کامل در بسیاری از معماری‌ها
- انعطاف بیشتر در انتخاب Hardware و Storage Stack
- امکان دسترسی مستقیم‌تر به Drive در معماری‌های مناسب
- مناسب برای بسیاری از پیاده‌سازی‌های NVMe و Software-Defined
- کاهش وابستگی به یک مدل خاص از RAID Controller در برخی سناریوها
محدودیت‌های RAID نرم‌افزاری
- مصرف بخشی از منابع Host برای عملیات RAID
- وابستگی به پشتیبانی سیستم‌عامل، Driver و ابزار مدیریتی
- پیچیدگی بیشتر Boot یا Recovery در بعضی پیاده‌سازی‌ها
- تفاوت قابلیت‌ها میان سیستم‌عامل‌ها و Vendorها
- نیاز بیشتر به طراحی صحیح Monitoring و Alerting
مزایای RAID سخت‌افزاری
- Offload شدن بخش مهمی از مدیریت RAID از CPU میزبان
- امکان استفاده از Controller Cache محافظت‌شده در مدل‌های مناسب
- مدیریت متمرکز Logical Drive، Hot Spare و عملیات Rebuild
- یکپارچگی مناسب با ابزارهای مدیریتی سرورهای Enterprise
- پیاده‌سازی ساده‌تر برای بسیاری از سرورهای SAS/SATA
محدودیت‌های RAID سخت‌افزاری
- هزینه Controller و در بعضی موارد License یا Cache Module
- احتمال وابستگی Recovery به Controller سازگار
- نیاز به مدیریت Firmware و سازگاری Driveها
- امکان تبدیل شدن Controller به Bottleneck در I/O بسیار سریع
- پیچیدگی مهاجرت در صورت تغییر Vendor یا خانواده Controller
کدام RAID برای چه سناریویی مناسب‌تر است؟
انتخاب صحیح باید از Workload شروع شود، نه از ترجیح قبلی نسبت به Hardware یا Software RAID. دو سرور با تعداد Drive یکسان ممکن است به دلیل تفاوت در Database، Virtualization، Backup یا Sequential Processing به معماری RAID متفاوتی نیاز داشته باشند.
چه زمانی RAID سخت‌افزاری منطقی‌تر است؟
Hardware RAID در بسیاری از سرورهای Enterprise مبتنی بر SAS یا SATA زمانی گزینه مناسبی است که تیم IT به مدیریت متمرکز، Boot Volume مبتنی بر RAID، Hot Spare، ابزارهای Vendor، فرآیند مشخص تعویض Drive و Write-back Cache محافظت‌شده نیاز دارد.
این مدل برای سازمان‌هایی که استاندارد عملیاتی مشخصی روی یک خانواده سرور دارند نیز می‌تواند مدیریت زیرساخت را ساده کند؛ به شرط آنکه Controller، Drive و Firmware به‌صورت کامل با پلتفرم انتخابی سازگار باشند.
چه زمانی RAID نرم‌افزاری گزینه بهتری است؟
Software RAID زمانی جذاب‌تر می‌شود که هزینه Controller اهمیت داشته باشد، تیم فنی کنترل بیشتری روی Storage Stack بخواهد یا معماری بر پایه NVMe، Linux یا یک راهکار Software-Defined طراحی شده باشد.
در این سناریوها باید سربار CPU، Boot Support، Monitoring، نحوه تعویض Drive و فرآیند Recovery قبل از ورود به Production آزمایش شوند. استفاده از RAID نرم‌افزاری در دیتاسنتر ذاتاً غیرحرفه‌ای یا غیرقابل اعتماد نیست؛ کیفیت پیاده‌سازی و تناسب آن با Workload تعیین‌کننده است.
Software-Defined Storage الزاماً به Hardware RAID نیاز ندارد
در برخی معماری‌های Software-Defined Storage، فایل‌سیستم‌ها یا پلتفرم‌های توزیع‌شده ترجیح می‌دهند Driveها را مستقیم مشاهده کنند. در چنین شرایطی ممکن است HBA/JBOD یا Pass-through به‌جای ساخت RAID زیرین مناسب‌تر باشد. استفاده از Hardware RAID در زیر این پلتفرم‌ها باید دقیقاً مطابق توصیه Vendor انجام شود.
«Hybrid RAID» یک تعریف واحد و عمومی برای ترکیب Software RAID و Hardware RAID ندارد و ممکن است Vendorهای مختلف از این عبارت با معانی متفاوت استفاده کنند. به همین دلیل بهتر است به‌جای انتخاب بر اساس این اصطلاح، معماری دقیق Controller، HBA، سیستم‌عامل و Storage Software بررسی شود.
سطح RAID چه تأثیری بر انتخاب نرم‌افزاری یا سخت‌افزاری دارد؟
تصمیم میان Software RAID و Hardware RAID باید هم‌زمان با انتخاب RAID Level انجام شود. RAID 0، RAID 1، RAID 5، RAID 6 و RAID 10 رفتار یکسانی در ظرفیت، Write Penalty، تحمل خرابی و Rebuild ندارند.
| RAID Level | ویژگی اصلی | نکته تصمیم‌گیری |
|---|---|---|
| RAID 0 | Striping بدون Redundancy | برای داده‌ای که تحمل خرابی لازم دارد مناسب نیست |
| RAID 1 | Mirroring | ساختار ساده و مناسب برای ظرفیت‌های محدود و Boot Volumeها |
| RAID 5 | Single Parity | ظرفیت مؤثر مناسب‌تر، اما Write و Rebuild نیازمند بررسی دقیق است |
| RAID 6 | Dual Parity | تحمل خرابی بیشتر نسبت به RAID 5 با هزینه بالاتر در Write و ظرفیت |
| RAID 10 | Mirroring + Striping | برای بسیاری از Workloadهای I/O-intensive گزینه قدرتمندی است، اما ظرفیت بیشتری برای Redundancy مصرف می‌کند |
هیچ RAID Level به‌صورت مطلق برای همه دیتابیس‌ها یا همه دیتاسنترها «بهترین» نیست. نسبت Read/Write، ظرفیت، RPO/RTO، تعداد Drive، نوع SSD/HDD و زمان قابل قبول Rebuild باید در تصمیم دخالت داده شوند. برای بررسی دقیق‌تر سطوح مختلف می‌توانید راهنمای انتخاب RAID مناسب را مطالعه کنید.
چک‌لیست انتخاب RAID مناسب در دیتاسنتر
- Workload را اندازه‌گیری کنید: نسبت Read/Write، IOPS، Throughput، Block Size، Queue Depth و Latency هدف را مشخص کنید.
- نوع Drive و Interface را بررسی کنید: رفتار SATA HDD، SAS SSD و NVMe یکسان نیست و Controller باید توان پاسخ‌گویی به مجموع پهنای باند Driveها را داشته باشد.
- سطح RAID را جدا از نوع پیاده‌سازی انتخاب نکنید: هزینه Parity و مدت Rebuild در RAID 5 یا RAID 6 با RAID 1 و RAID 10 متفاوت است.
- Compatibility Matrix را بررسی کنید: Controller، Firmware، Backplane، Drive، سیستم‌عامل و ابزار مدیریت باید در ترکیب موردنظر پشتیبانی شوند.
- Recovery را پیش از Production آزمایش کنید: خرابی Drive، Degraded Array، Rebuild، خرابی Controller و انتقال آرایه باید سناریوی عملیاتی مشخص داشته باشند.
- TCO را محاسبه کنید: قیمت Controller تنها هزینه نیست؛ مصرف CPU، License، قطعه یدکی، نگهداری، Downtime، توان مصرفی و زمان عملیات تیم IT نیز اهمیت دارند.
- مسیر توسعه آینده را در نظر بگیرید: افزایش تعداد Drive، مهاجرت به NVMe، نسل جدید PCIe یا تغییر Storage Architecture ممکن است انتخاب امروز را تحت تأثیر قرار دهد.
مانیتورینگ را بخشی از طراحی RAID بدانید
RAID بدون Monitoring مناسب می‌تواند مدت زیادی در وضعیت Degraded باقی بماند. Hardware RAID معمولاً از ابزارهای مدیریتی Vendor برای مشاهده وضعیت Controller، Virtual Disk، Cache و Physical Drive استفاده می‌کند. Software RAID نیز می‌تواند از ابزارهای سیستم‌عامل و Alerting مناسب بهره ببرد.
Rebuild را فقط روی کاغذ ارزیابی نکنید
هنگام خرابی Drive، آرایه وارد دوره‌ای می‌شود که عملکرد و سطح تحمل خرابی آن می‌تواند تغییر کند. سرعت Rebuild به ظرفیت Drive، میزان I/O هم‌زمان، نوع RAID، Priority تنظیم‌شده و توان Storage Subsystem وابسته است. طراحی باید رفتار سیستم در همین وضعیت غیرعادی را نیز پوشش دهد.
اشتباهات رایج مدیران IT در انتخاب RAID
انتخاب صرفاً بر اساس قیمت
فرض اینکه Hardware RAID همیشه سریع‌تر است
نادیده گرفتن خرابی Controller
یکی دانستن RAID و Backup
استفاده از Write-back بدون بررسی حفاظت Cache
نادیده گرفتن کیفیت Drive
مطالب، محصولات و خدمات مرتبط
جمع‌بندی؛ RAID سخت‌افزاری بهتر است یا نرم‌افزاری؟
در دیتاسنتر نمی‌توان بدون شناخت Workload اعلام کرد که RAID سخت‌افزاری همیشه بهتر از RAID نرم‌افزاری است. Hardware RAID برای بسیاری از سرورهای Enterprise مبتنی بر SAS/SATA، به‌خصوص زمانی که مدیریت متمرکز، Protected Write-back Cache، Hot Spare و یکپارچگی با ابزارهای Vendor مهم است، گزینه‌ای منطقی و قابل اتکا محسوب می‌شود.
در مقابل، Software RAID و راهکارهای RAID مجتمع با CPU در زیرساخت‌های جدید، به‌خصوص NVMe و Software-Defined Storage، می‌توانند هم از نظر کارایی و هم از نظر مقیاس‌پذیری مزایای مهمی داشته باشند. در این معماری‌ها وجود یک Controller اختصاصی لزوماً مزیت عملکردی محسوب نمی‌شود.
سوالات متداول درباره RAID نرم‌افزاری و سخت‌افزاری
آیا RAID سخت‌افزاری برای دیتاسنتر همیشه بهتر است؟
خیر. Hardware RAID در بسیاری از سرورهای Enterprise مزایای مدیریتی و عملیاتی مهمی دارد، اما در محیط‌های NVMe یا Software-Defined ممکن است RAID نرم‌افزاری یا معماری Direct-Attached انتخاب مناسب‌تری باشد. Workload و Storage Architecture باید معیار اصلی باشند.
آیا RAID نرم‌افزاری برای محیط Production قابل اعتماد است؟
بله، در صورت استفاده از پیاده‌سازی پشتیبانی‌شده، Hardware مناسب، Monitoring، Backup و فرآیند Recovery درست، Software RAID می‌تواند در Production استفاده شود. کیفیت پیاده‌سازی مهم‌تر از برچسب نرم‌افزاری یا سخت‌افزاری است.
آیا RAID سخت‌افزاری CPU سرور را کاملاً آزاد می‌کند؟
Controller اختصاصی بخش مهمی از عملیات RAID را Offload می‌کند، اما کل Storage I/O بدون مصرف CPU نیست. Driver، Interrupt Processing، Filesystem، Application و سایر بخش‌های I/O Stack همچنان از منابع Host استفاده می‌کنند.
برای NVMe، RAID نرم‌افزاری بهتر است یا سخت‌افزاری؟
پاسخ به تعداد SSD، نسل PCIe، Workload، Controller و Platform بستگی دارد. Software RAID یا RAID مجتمع می‌تواند از اتصال مستقیم NVMe به PCIe بهره ببرد، در حالی که Hardware RAID ممکن است امکانات مدیریتی بیشتری ارائه کند. Benchmark واقعی برای تصمیم نهایی ضروری است.
آیا RAID 10 بهترین گزینه برای دیتابیس است؟
RAID 10 برای بسیاری از دیتابیس‌های پرتراکنش به دلیل ترکیب Mirroring و Striping گزینه قدرتمندی است، اما بهترین انتخاب مطلق نیست. الگوی Read/Write، ظرفیت، هزینه، Storage Engine و الزامات Availability باید بررسی شوند.
اگر RAID داریم، آیا باز هم Backup لازم است؟
بله. RAID فقط برخی خرابی‌های سطح Drive را پوشش می‌دهد. Backup مستقل برای مقابله با حذف داده، Corruption، Ransomware، خطای انسانی و Disaster ضروری است.