طرح بازیابی فاجعه تنها در صورتی مؤثر است که بتوانید داده ها را بازیابی کنید. اما با وجود خطرات فزاینده – به خصوص از باج افزار – همه سازمان ها مطمئن نیستند که واقعاً می توانند از نسخه های پشتیبان خود بازیابی شوند.
وقتی صحبت می کنیم پشتیبان گیری و بازیابی، آزمایش منظم و دقیق باید بخش اساسی هر برنامه ای باشد. اما گام‌های دیگری نیز وجود دارد که مدیران فناوری اطلاعات می‌توانند انجام دهند، مانند ممیزی فرآیندهای پشتیبان‌گیری قانون پشتیبان 3-2-1و بررسی صحت فایل های آرشیو.
تست پشتیبان گیری باید با درک عمیقی از اینکه کدام سیستم‌ها و داده‌ها حیاتی‌تر هستند و چگونه سیستم‌ها در یک محیط تولید به یکدیگر وابسته هستند، همراه باشد.
در اینجا، ما برخی از سوالات کلیدی را که رهبران فناوری اطلاعات و تیم‌های تداوم کسب‌وکار باید بپرسند، خلاصه می‌کنیم.
عناصر کلیدی بازیابی پشتیبان قابل اعتماد چیست؟
سازمان‌ها باید بدانند که پشتیبان‌گیری‌هایشان کار می‌کند – که می‌توانند داده‌ها را بازیابی کنند و سیستم‌ها را با کمترین اختلال و بدون از دست رفتن یا خرابی داده‌ها بازیابی کنند.
این به چندین عنصر مرتبط با یکدیگر تقسیم می شود. برنامه پشتیبان و بازیابی هر سازمان به طور کلی تشریح خواهد شد هدف زمان بازیابی (RTO) – به این معنی که داده ها با چه سرعتی باید بازیابی شوند. و هدف نقطه بازیابی (RPO) – که به این معنی است که چقدر می خواهید برای یافتن آخرین نسخه خوب از داده ها به عقب بروید.
این پارامترها مشخص می کنند که یک بازیابی موفق کسب و کار چگونه به نظر می رسد. با این حال، باج افزار، معیار کلیدی دیگری نیز وجود دارد. و این است که آیا کسب و کار می تواند به بازیابی داده های پاک دست یابد یا خیر.
اگر سیستم‌ها را مجدداً با کد باج‌افزار آلوده کند، پس از یک حمله سایبری، بازیابی سیستم‌ها فایده‌ای ندارد. و ممکن است RPO برای مثلاً قطع برق با RPO برای باج افزار متفاوت باشد. همه چیز به تحمل ریسک کسب و کار برمی گردد.
بازیابی قابل اعتماد نیز به یکپارچگی داده های بازیابی شده بستگی دارد. آیا فایل های بازیابی شده همانطور که باید کار می کنند یا برخی از داده ها بازیابی نشدند یا خراب شدند؟
کسب و کارها همچنین باید ترتیب بازیابی داده ها را در نظر بگیرند. برخی از سیستم‌ها به دلیل وابستگی به برنامه‌های کاربردی دیگر، مأموریت حیاتی هستند یا باید ابتدا بازیابی شوند. آزمایش بازیابی باید تأیید کند که سیستم‌ها به ترتیب صحیح آنلاین می‌شوند.
این به نوبه خود به دسترسی به رسانه بستگی دارد. پشتیبان‌گیری‌های ابری به پهنای باند نیاز دارند، در حالی که پشتیبان‌گیری‌های داخلی به سیستم‌های پشتیبان برای راه‌اندازی و اجرا نیاز دارند. رسانه پشتیبان خارج از سایت باید در محل بازیابی و منتقل شود یا در یک سیستم آماده به کار یا ابر آپلود شود.
شرکت ها همچنین باید بررسی کنند که سیستم های Failover یا Standby طبق برنامه ریزی آنلاین هستند. این شامل ظرفیت ابر و امکانات بازیابی بلایا در صورت استفاده از آنها می شود. در نهایت، آیا سازمان می تواند به خدمات پشتیبانی که برای بازیابی داده ها نیاز دارد دسترسی داشته باشد؟
اینها شامل برق و سرمایش، ارتباطات و پرسنل کلیدی است. فقط تأیید اینکه نرم افزار پشتیبان همانطور که در نظر گرفته شده است کار می کند کافی نیست.
چگونه فرآیندهای پشتیبان گیری را ممیزی می کنید؟
آ حسابرسی ذخیره – یا ممیزی پشتیبان گیری و بازیابی – فرآیندی رسمی برای تأیید اینکه پشتیبان گیری و بازیابی آن طور که باید کار می کنند است.
ممیزی های پشتیبان باید شامل بررسی مکان ذخیره داده ها و برنامه های کاربردی، حفاظت از داده ها و مکان اهداف پشتیبان باشد. این شامل داده های ذخیره شده در ابر و بایگانی شده در ابر می شود.
ممیزی سپس به بازیابی داده ها، از جمله انطباق با اهداف RPO و RTO می پردازد و سیاست ها و رویه های پشتیبان گیری و بازیابی سازمان را بررسی می کند. این شامل معیارهای فنی و همچنین مدیریت فرآیند بازیابی است.
خروجی گزارشی با توصیه هایی برای اقدام خواهد بود.
قانون پشتیبان گیری 3-2-1 چیست؟
قانون پشتیبان گیری 3-2-1 یک روش طولانی مدت برای تضمین حفاظت کافی از داده ها است. این قانون بیان می‌کند که سازمان‌ها باید سه نسخه از داده‌های خود را در حداقل دو نوع رسانه یا سیستم ذخیره‌سازی نگهداری کنند. یک کپی از داده ها باید خارج از سایت باشد.
پیروی از قانون 3-2-1 اکنون که صنعت چندین خدمات پشتیبان گیری مبتنی بر ابر را ارائه می دهد بسیار آسان تر است. اما هنوز دلایلی برای پشتیبان گیری فیزیکی خارج از سایت در بسیاری از صنایع وجود دارد، به ویژه به عنوان یک اقدام احتیاطی در برابر باج افزار.
و، تمام قسمت های 3-2-1 این قانون باید برای بازیابی موثر و یکپارچگی داده ها بررسی شود.
چگونه یکپارچگی یک نسخه پشتیبان را آزمایش می کنید؟
اگر نسخه پشتیبان به درستی بازیابی نشود، بی فایده است. این ممکن است واضح به نظر برسد، اما تست یکپارچگی پشتیبان بخشی ضروری از هر برنامه پشتیبان گیری و بازیابی یا تداوم کسب و کار است.
فایل‌ها ممکن است خراب یا آلوده شوند، رسانه‌های فیزیکی مانند نوار می‌توانند به مرور زمان خراب شوند، غیرقابل دسترس شوند یا حتی در طول یک فاجعه از بین بروند. سرویس‌های ابری ممکن است در دسترس یا تخریب شوند و بر توانایی بازیابی داده‌های حساس به زمان به ترتیب صحیح تأثیر بگذارند.
نرم افزار پشتیبان گیری از ابزارهایی استفاده می کند که شامل تأیید جمع و هش برای تأیید بازیابی منطقی است. فروشندگان همچنین یادگیری ماشین و هوش مصنوعی را برای بررسی الگوهای غیرعادی در داده ها – که گاهی اوقات آنتروپی نامیده می شود – برای شناسایی باج افزارها و سایر اشکال فساد معرفی کرده اند.
تنها راه مطمئن برای آزمایش یکپارچگی یک نسخه پشتیبان، تلاش برای بازیابی از آن است. این موضوع مسائل عملی را به‌ویژه هنگام بازیابی داده‌ها در سیستم‌های تولید حیاتی که دائماً در حال استفاده هستند، ایجاد می‌کند. تیم های فناوری اطلاعات ممکن است نیاز به آزمایش بازیابی یک سیستم در یک زمان یا ماشین های مجازی داشته باشند.
برخی از فروشندگان جایگزین هایی را توسعه داده اند. برای مثال Commvault یک محصول بازیابی «اتاق تمیز» دارد که به مشتریان اجازه می‌دهد داده‌ها را به یک نسخه مجازی از محیط ابری خود بازیابی کنند.
اما آزمایش بازیابی روی سخت‌افزار فیزیکی نیز حیاتی است، به‌ویژه برای سیستم‌های قدیمی‌تر که به راحتی نمی‌توانند به فناوری‌های ابری شبیه‌سازی شوند.
چرا آزمایش رویه های پشتیبان گیری و بازیابی مهم است؟
روش های آزمایش به اندازه فناوری آزمایش مهم هستند، اما نادیده گرفتن آنها آسان است.
بسیاری از تست‌های پشتیبان‌گیری به درستی بر جنبه‌های فنی تمرکز می‌کنند، مانند اینکه آیا نرم‌افزار پشتیبان‌گیری طبق برنامه کار می‌کند و آیا می‌توان فایل‌های پشتیبان را بازیابی و بازیابی کرد.
اما اغلب زمانی که بازیابی با شکست مواجه می شود، به دلایل غیر فنی است. در شرایط مرسوم بازیابی فاجعه و حمله باج افزار، کارکنان تحت فشار هستند، خطوط ارتباطی از کار افتاده است، و حفظ فرماندهی و کنترل دشوار است.
رویه‌های پشتیبان‌گیری و بازیابی باید مشخص کنند که چه اتفاقی باید بیفتد، چه زمانی و چه کسی مسئول آن است.
زمانی که بدترین اتفاق بیفتد، یک برنامه روشن و رویه های مستحکم به شما کمک خواهد کرد. اما این بدان معنی است که رویه ها باید به واقعی ترین شکل ممکن آزمایش شوند.
به این ترتیب، هر نقطه ضعفی را می توان قبل از استفاده از روش های خشم شناسایی و برطرف کرد. آیا می توان بک آپ پیدا کرد و سیستم های بازیابی را فعال کرد؟ آیا سیستم ها به ترتیب صحیح بازیابی شده اند؟ آیا محیط بازیابی فاجعه – فیزیکی یا ابری – طبق برنامه کار می کند؟ و آیا همه نقش خود را می دانند؟
بازیابی فاجعه یکی از مواردی است که واقعاً در مورد ابزارها، فرآیندها و افراد است. همه موارد باید تست استرس شوند.
هدف از تست پشتیبان چیست؟
هدف اصلی تست پشتیبان گیری اطمینان از اینکه فایل ها می توانند از نسخه های پشتیبان در سیستم های تولیدی بازیابی شوند، است.
آزمایش باید اطمینان حاصل کند که سیستم های تولید پس از بازیابی همانطور که باید عمل کنند. اگر یک کسب‌وکار قصد دارد به یک راه‌اندازی پشتیبان در مرکز داده خودش، با یک ارائه‌دهنده بازیابی فاجعه یا در فضای ابری حرکت کند، باید تأیید کند که در حالت Failover کار می‌کند. و مهمتر از همه، می توان آنها را در زمان رسیدن به سیستم تولید بازگرداند.
با این حال، آزمایش پشتیبان‌گیری اغلب بیشتر از این سؤال فنی است که آیا نسخه پشتیبان کار می‌کند یا خیر. همانطور که دیدیم، شرکت‌ها باید رویه‌های کلی خود را آزمایش کنند تا مطمئن شوند که برنامه‌ها به ترتیب صحیح اجرا می‌شوند، ارتباطات و فرماندهی و کنترل مطابق با هدف کار می‌کنند و همه نقش‌های خود را می‌دانند.
با این حال، حفاری عمیق‌تر و آزمایش کامل پشتیبان‌ها می‌تواند اطلاعات بیشتری را در مورد آمادگی و انعطاف‌پذیری یک سازمان نشان دهد.
به عنوان مثال، آیا RPOها و RTOها برآورده می شوند؟ و اگر هستند، آیا برای سازمان مناسب هستند؟ کسب‌وکارها تغییر می‌کنند و RTO که مثلاً پنج سال پیش قابل قبول بود، ممکن است اکنون نباشد.
شرکت ها همچنین باید هر گونه الزامات نظارتی را در مورد تداوم و اختلال در کسب و کار در نظر بگیرند.
چند بار باید بازیابی از پشتیبان‌گیری را آزمایش کنید؟
پاسخ ساده «هر چند وقت یک بار که می توانید» است. تست پشتیبان گیری و بازیابی در مقیاس بزرگ مخل و به طور بالقوه گران است و فقط می تواند سالانه انجام شود. سایر آزمایشات ممکن است رایج تر باشند. آنها ممکن است شامل بررسی های نقطه ای برنامه های کاربردی مهم یا آزمایش های جاسازی شده به عنوان بخشی از به روز رسانی برنامه باشند.
برخی از سیستم‌ها ممکن است روزانه آزمایش شوند، اما این بستگی به بحرانی بودن سیستم، اهمیت داده‌های آن و البته نگاه کسب‌وکار به ریسک دارد.
