تفاوت Snapshot و بکاپ در QNAP، در سرعت برگشت و محل باقی‌ماندن نسخه بازیابی است. Snapshot محلی به شما کمک می‌کند فایل‌ها را به وضعیت قبل از حذف یا تغییر اشتباه برگردانید؛ بکاپ مستقل باید زمانی هم قابل استفاده باشد که NAS اصلی یا فضای ذخیره‌سازی آن از دسترس خارج شده است. برای فایل‌های شرکت معمولاً به هر دو نیاز دارید: Snapshot برای بازیابی سریع‌تر و بکاپ مستقل برای پوشش خرابی‌هایی که نسخه محلی را هم از بین می‌برند.
Snapshot از کل فایل‌ها یک کپی مستقل تازه نمی‌سازد؛ وضعیت داده را در یک زمان مشخص ثبت می‌کند و برای برگشت به آن وضعیت، به اطلاعات و بلوک‌های لازم در همان فضای ذخیره‌سازی متکی است. به همین دلیل، ساخت سریع Snapshot و کم‌حجم‌بودن اولیه آن را نباید با داشتن نسخه‌ای خارج از دستگاه یکی گرفت.
نکات کلیدی
- Snapshot محلی جای بکاپ مستقل را نمی‌گیرد؛ از دست رفتن Pool می‌تواند راه بازیابی از همان Snapshotها را هم از بین ببرد.
- برای یک فایل، از بازیابی انتخابی شروع کنید؛ Revert کل Volume یا محدوده ذخیره‌سازی می‌تواند تغییرات سالم دیگران را هم عقب ببرد.
- RAID، Replica و Immutable نقش یکسانی ندارند؛ محل نسخه و امکان حذف آن را جدا بررسی کنید.
- آخرین نسخه سالم و قابل استفاده مهم است؛ وجود برنامه زمانی یا پیام پایان Job کافی نیست.
- فضای آزاد Pool را کنترل کنید؛ فضای خالی داخل Volume لزوماً برای Snapshot در دسترس نیست.
- بازیابی را پیش از حادثه امتحان کنید؛ ابزار، کلید، مجوز دسترسی و زمان برگشت باید مشخص باشند.
تفاوتی که در روز حادثه روشن می‌شود
فرض کنید صبح دوشنبه، پوشه قراردادهای شرکت حذف شده است. NAS روشن است، دیسک‌ها سالم‌اند و Snapshot مربوط به قبل از حذف هم وجود دارد. در این وضعیت می‌توانید فایل موردنظر را از نسخه قبلی پیدا کنید و ابتدا به یک مسیر جدا برگردانید؛ لازم نیست همه اطلاعات شرکت را به دیروز بازگردانید.
حالا فرض کنید NAS و دیسک‌های آن در یک حادثه از دست رفته‌اند. در این وضعیت، تعداد Snapshotهای محلی تعیین‌کننده نیست؛ باید نسخه‌ای داشته باشید که خارج از این خرابی باقی مانده باشد و بتوان آن را خواند.
بنابراین وجود Snapshot یا بکاپ را ملاک کافی ندانید؛ برای هر حادثه مشخص کنید کدام نسخه باقی می‌ماند و چطور از آن استفاده می‌کنید.
| روش حفاظت | کمکی که می‌کند | محدودیت اصلی |
|---|---|---|
| RAID | تحمل برخی خرابی‌های دیسک، در محدوده آرایش و سلامت مجموعه | حذف اشتباهی یا نابودی کل دستگاه را جبران نمی‌کند |
| Snapshot محلی | دسترسی به وضعیت قبلی داده در محدوده‌ای که Snapshot پوشش می‌دهد | به سلامت Pool و باقی‌ماندن نسخه وابسته است |
| Snapshot Replica | انتقال نسخه مبتنی بر Snapshot به مقصد سازگار | امنیت مقصد و مسیر بازیابی باید جدا بررسی شوند |
| بکاپ مستقل با تاریخچه | نگهداری نقاط بازیابی بیرون از محل خرابی موردنظر | به نسخه سالم، ابزار سازگار، کلید و زمان بازیابی نیاز دارد |
بکاپ مستقل فقط یک دستگاه جدا نیست. دو NAS با دسترسی مدیریتی مشترک یا دو رسانه در یک اتاق، ممکن است همچنان در معرض یک حمله یا حادثه مشترک باشند. محل نسخه، سطح دسترسی به آن و امکان حذفش هم بخشی از طراحی حفاظت هستند.
محدوده Snapshot را قبل از بازیابی بشناسید
برای خواندن تنظیمات QNAP، سه اصطلاح را از هم جدا کنید: Storage Pool مجموعه‌ای از ظرفیت دیسک‌هاست که منابع ذخیره‌سازی از آن تأمین می‌شوند؛ Volume فضایی برای نگهداری فایل‌ها و پوشه‌ها در QTS است؛ LUN فضای ذخیره‌سازی بلوکی است که می‌تواند به سرور یا میزبان دیگر ارائه شود. پوشه‌ای که کارمند در شبکه می‌بیند، الزاماً تمام محدوده‌ای نیست که با یک عملیات Revert تغییر می‌کند.
در QTS، Snapshot ذخیره‌سازی در سطح Volume یا LUN تعریف می‌شود. در QuTS hero، محدوده فایل‌محور آن Shared Folder است و برای LUN هم Snapshot وجود دارد. این تفاوت مشخص می‌کند یک عملیات بازگردانی چه مقدار از اطلاعات شرکت را تحت تأثیر قرار می‌دهد.
مثلاً ممکن است در QTS پوشه‌های مالی، فروش و پروژه‌ها روی یک Volume قرار داشته باشند. بازگرداندن کل آن Volume به دیروز، فقط پوشه آسیب‌دیده را عقب نمی‌برد؛ تغییرات جدید پوشه‌های سالم هم در محدوده عملیات قرار می‌گیرند.
مدل دستگاه، نسخه سیستم‌عامل، ساختار ذخیره‌سازی و منابع سخت‌افزاری را هم بررسی کنید. قابلیت‌ها و سقف‌های یک مدل را نمی‌توان به همه کیونپ‌ها تعمیم داد. برای نمونه، Static Volume در QTS از Snapshot پشتیبانی نمی‌کند؛ صرف داشتن NAS کیونپ به معنی آماده‌بودن این قابلیت نیست. اگر نوع فضای ذخیره‌سازی مناسب نیست، تغییر ساختار را پروژه‌ای جدا با بکاپ و برنامه انتقال داده در نظر بگیرید.
بازیابی فایل حذف‌شده با کمترین اثر بر بقیه اطلاعات
برای حذف محدود، نام و مسیر فایل یا پوشه، زمان تقریبی حذف و آخرین نسخه‌ای که احتمالاً سالم است را مشخص کنید. اگر سطل بازیافت آن پوشه فعال بوده، آن را هم بررسی کنید؛ سپس سراغ Snapshot مربوط به قبل از حادثه بروید. ساخت Snapshot تازه بعد از حذف، نسخه قبل از حذف را ایجاد نمی‌کند.
در محیط مدیریت NAS، از Storage & Snapshots محدوده مربوط را پیدا کرده و Snapshot Manager را باز کنید. مسیر دقیق منو با نسخه QTS یا QuTS hero فرق می‌کند؛ پیش از انتخاب نسخه، نام Volume، Shared Folder یا LUN را با محل داده موردنظر تطبیق دهید. سپس تاریخ مناسب را انتخاب کنید و وجود فایل را در همان وضعیت بررسی کنید.
فایل پیدا‌شده را ترجیحاً ابتدا به پوشه‌ای جدا برگردانید. نام و تاریخ فایل کافی نیست؛ آن را باز کنید و محتوایش را با انتظار مسئول مربوط مقایسه کنید. بعد درباره جایگزینی نسخه فعلی تصمیم بگیرید.
برای یک قرارداد، بررسی مبلغ و طرف قرارداد اهمیت دارد؛ برای فایل پروژه، بازشدن در نرم‌افزار مربوط و وجود اجزای موردنیاز. هدف این است که فایل صحیح برگردد، بدون اینکه داده سالم دیگری بازنویسی شود.
تفاوت Restore، Revert و Clone
این سه گزینه را بر اساس دامنه اثرشان انتخاب کنید:
| عملیات | کاربرد مناسب | چیزی که پیش از اجرا باید روشن باشد |
|---|---|---|
| Restore انتخابی | برگرداندن فایل یا پوشه مشخص | تاریخ نسخه، مسیر مقصد و رفتار برخورد با فایل همنام |
| Revert | برگرداندن کل محدوده تحت پوشش به یک نقطه زمانی | اثر بر تمام تغییرات بعدی همان محدوده |
| Clone | ساخت نسخه قابل دسترسی جدا در محیط پشتیبانی‌شده | فضای لازم، وابستگی‌ها و نحوه دسترسی به داده |
Clone می‌تواند برای بررسی یک وضعیت قدیمی مفید باشد، اما مستقل از محل ذخیره‌سازی محسوب نمی‌شود صرفاً چون نام جداگانه‌ای دارد. نوع Clone و وابستگی آن را در مدل و نسخه واقعی بررسی کنید.
پیش از Revert، تغییرات جدید و مفید را شناسایی کنید. گزینه‌های حفاظتی همان نسخه نرم‌افزار را بخوانید و نتیجه عملیات را از روی نام دکمه حدس نزنید؛ بازگرداندن یک فایل با عقب‌بردن کل Volume یک تصمیم یکسان نیست.
انتخاب مسیر بازیابی بر اساس اتفاق رخ‌داده
پیش از شروع عملیات، وضعیت دستگاه و وسعت مشکل را مشخص کنید. جدول زیر نقطه شروع بررسی است؛ انتخاب نسخه و تأیید نتیجه همچنان باید با مسئول همان داده انجام شود.
| وضعیت | اولین بررسی و اقدام | معیار موفقیت |
|---|---|---|
| یک فایل حذف شده و NAS سالم است | سطل بازیافت و سپس Snapshot قبل از حذف؛ بازیابی فایل در مسیر جدا | فایل درست باز شود و محتوای موردنیاز را داشته باشد |
| چند پوشه به وضعیت اشتباه برگشته‌اند یا تغییر کرده‌اند | زمان شروع تغییر و محدوده آسیب؛ مقایسه Restore انتخابی با اثر Revert | داده آسیب‌دیده برگردد و تغییرات سالم موردنیاز حفظ شود |
| NAS یا Pool اصلی در دسترس نیست | بررسی آخرین بکاپ مستقل قابل خواندن، ابزار و کلید آن | فایل‌ها بدون اتکا به دستگاه اصلی در مقصد قابل استفاده باشند |
| فایل‌ها در حال رمزگذاری‌اند | مهار دسترسی عامل آلودگی و تعیین آخرین نسخه سالم، پیش از بازگرداندن داده | نسخه بازیابی‌شده دوباره تخریب نشود و برای ادامه کار تأیید شود |
خرابی NAS و آمادگی برای بازیابی روی مقصد دیگر
اگر NAS اصلی روشن نشود، باید مسیر دسترسی به بکاپ از قبل مشخص باشد. نسخه روی هارد بیرونی، NAS دوم یا فضای ابری زمانی کاربردی است که ابزار لازم و مجوز دسترسی به آن را داشته باشید.
ظاهر مقصد هم می‌تواند گمراه‌کننده باشد. وجود داده در Snapshot Vault به معنی آماده‌بودن همان پوشه‌ها برای ادامه کار کاربران نیست. بسته به سیستم‌عامل و روش حفاظت، ممکن است به عملیات بازیابی یا Clone، فضای آزاد و تنظیم مجدد دسترسی‌ها نیاز داشته باشید.
این مسیر را یک بار زمانی تمرین کنید که NAS اصلی سالم است: بدون استفاده از داده یا ابزار روی دستگاه اصلی، چند فایل را از مقصد بکاپ در یک مسیر جدا برگردانید. برای این تمرین لازم نیست NAS فعال شرکت را خاموش کنید؛ هدف این است که وابستگی به آن را آشکار کنید. نام مقصد، حساب لازم، محل نگهداری کلید و کامپیوتری را که ابزار بازیابی روی آن اجرا می‌شود ثبت کنید تا نبودن یک نفر، مسیر بازیابی را متوقف نکند.
برای بکاپ روی دیسک بیرونی، مراحل ساخت Job و آزمون برگرداندن فایل را در آموزش بکاپ QNAP روی هارد اکسترنال با HBS 3 دنبال کنید.
Snapshot در برابر باج‌افزار، با شرط‌های مشخص
باج‌افزار روی کامپیوتر کارمند با نفوذ به مدیریت NAS یک وضعیت یکسان ایجاد نمی‌کند. اگر آلودگی فقط با دسترسی کارمند فایل‌های اشتراکی را تغییر دهد، ممکن است Snapshot سالم قبل از حمله باقی مانده باشد. اما نفوذ به خود NAS یا دسترسی مدیریتی می‌تواند نسخه‌های معمولی قابل‌حذف را هم تهدید کند.
در رخداد تاریخی Qlocker، QNAP حذف Snapshot با دسترسی غیرمجاز را تأیید کرده است. این مثال نشان می‌دهد عبارت «Snapshot داریم» به‌تنهایی تضمین مقابله با هر نوع حمله نیست؛ نباید از آن درباره آسیب‌پذیری فعلی همه نسخه‌ها نتیجه‌گیری کرد.
پس از مشاهده رمزگذاری، ابتدا مسیر حمله را مهار کنید و نسخه سالم را مشخص کنید. بازگرداندن فایل‌ها در حالی که عامل آلودگی هنوز به آن‌ها دسترسی دارد، می‌تواند نتیجه بازیابی را دوباره تخریب کند. صرف نصب وصله هم به‌تنهایی ثابت نمی‌کند محیط آلوده پاک شده است.
اگر نسخه سالم مستقلی در اختیار ندارید، تعمیر فایل‌سیستم، حذف تاریخچه، Initialize کردن دیسک‌ها یا اجرای دستورهای پراکنده انجمن‌ها را نقطه شروع قرار ندهید. در این شرایط، حفظ داده و انتخاب مسیر متناسب با همان حادثه اهمیت بیشتری دارد.
تفاوت نگهداری دائمی با Immutable
گزینه Keep permanently به نگهداری Snapshot مربوط است و نباید آن را با قفل امنیتی در برابر حذف مدیریتی یکی دانست. Immutable (تغییرناپذیری) قابلیت جداگانه‌ای است که پشتیبانی، مدت حفاظت و محدودیت‌هایش به نسخه و پیکربندی وابسته‌اند.
همچنین طبق توضیح فعلی QNAP، ویژگی Immutable از طریق Snapshot Replica به مقصد منتقل نمی‌شود. پس داشتن NAS دوم، خودبه‌خود مقصدی غیرقابل‌حذف ایجاد نمی‌کند؛ حفاظت مقصد باید جدا طراحی و آزمایش شود. این توضیح را هم نباید بدون سند به SnapSync تعمیم داد.
فضای خالی Volume با فضای آزاد Pool فرق دارد
ممکن است داخل Volume فضای خالی ببینید، اما Snapshot به دلیل کمبود فضای Pool ساخته نشود. در Thick Volume بخشی از ظرفیت از قبل به Volume تخصیص یافته است؛ خالی‌بودن آن برای فایل‌های کاربر الزاماً به معنی آزادبودن همان ظرفیت برای سایر مصرف‌های Pool نیست.
پیش از حذف فایل یا تغییر ساختار، این موارد را در Storage & Snapshots بررسی کنید:
- فضای آزاد و نحوه تخصیص ظرفیت Pool؛
- مصرف Snapshotها و سیاست نگهداری آن‌ها؛
- فضای تضمین‌شده Snapshot، اگر در آن پیکربندی استفاده می‌شود؛
- آخرین خطای ثبت Snapshot یا انتقال نسخه به مقصد.
تغییر Threshold هشدار، ظرفیت تازه‌ای ایجاد نمی‌کند. حذف همه Snapshotها هم ممکن است تنها نسخه قبل از حادثه را از بین ببرد. تبدیل Thick و Thin را بدون بکاپ قابل بازیابی و بررسی همان نسخه، راه‌حل عمومی کمبود فضا ندانید.
برای مصرف Snapshot درصد ثابتی تعیین نکنید و آن را کافی فرض نکنید. پوشه اسناد کم‌تغییر، فایل بزرگی که مرتب بازنویسی می‌شود و دیسک ماشین مجازی، رفتار یکسانی ندارند. ظرفیت را با میزان تغییر داده و تعداد نقاط بازیابی موردنیاز تنظیم و سپس مصرف واقعی را پایش کنید.
سیاست حذف خودکار نیز باید روشن باشد. نگه‌داشتن نسخه‌های بیشتر در برابر خطر پرشدن Pool یک تصمیم عملیاتی است؛ خاموش‌کردن عمومی مدیریت خودکار فضا، بدون ظرفیت‌سنجی، پاسخ آماده‌ای برای همه شرکت‌ها نیست.
کنترل Replica پس از تغییرات مهم
موفق‌بودن انتقال قبلی، سلامت اجرای بعدی را ثابت نمی‌کند. منابع هر دو NAS، اتصال، سازگاری سیستم‌عامل‌ها و فضای مقصد را بررسی کنید.
در FAQ رسمی مربوط به QTS، افزایش ظرفیت Volume یا LUN منبع به‌عنوان یکی از علت‌های شکست Snapshot Replica ذکر شده است. بعد از چنین تغییری، آخرین اجرای موفق و یک بازیابی واقعی از مقصد را دوباره کنترل کنید. حذف Snapshot Vault را بدون بررسی نسخه و حفظ تاریخچه موردنیاز، به یک اقدام روتین تبدیل نکنید.
از طرف دیگر، FAQ جداگانه QuTS hero توضیح می‌دهد دریافت Replica به فضای موقت در Pool مقصد هم نیاز دارد؛ برای منبع Thick Shared Folder، شرط ظرفیت بیشتری مطرح شده است. بنابراین عدد فضای آزاد داخل پوشه یا ظرفیت اسمی دیسک مقصد، به‌تنهایی برای تصمیم کافی نیست.
تفاوت بکاپ HBS با کپی آخرین وضعیت
یک کپی به‌روز از فایل‌ها ممکن است آخرین اشتباه را هم به‌روز کند. اگر فایل سالم با محتوای اشتباه جایگزین شده و شما سه هفته بعد متوجه شوید، به نسخه‌ای از قبلِ آن تغییر نیاز دارید؛ نه فقط فایل فعلی روی دستگاه دیگر.
در HBS، نوع Job، سیاست حذف و Version Management را جدا بررسی کنید. در حالت Mirror، حذف منبع می‌تواند در مقصد هم اعمال شود. در بعضی Backup Jobها نیز گزینه Remove additional files in destination folder بر رفتار حذف مقصد اثر دارد. نام «بکاپ» برای فهمیدن نتیجه حذف کافی نیست.
یک آزمون ساده با داده غیرحساس انجام دهید: فایل آزمایشی بسازید، Job را اجرا کنید، فایل را ویرایش و سپس حذف کنید و بعد از اجرای بعدی بررسی کنید چه نسخه‌هایی قابل برگشت مانده‌اند. نتیجه باید با انتظار شرکت منطبق باشد.
تاریخچه هم باید به اندازه زمان کشف خطا فرصت بدهد. اگر اشتباهات معمولاً دیر دیده می‌شوند، چند نسخه نزدیک به هم ممکن است همه بعد از وقوع خطا ثبت شده باشند.
بازیابی QDFF بدون NAS اصلی
پوشه QDFF را نمی‌توان صرفاً از روی ظاهرش مانند یک مجموعه فایل عادی در نظر گرفت. برای بازیابی آن می‌توان از Restore Job در HBS یا QuDedup Extract Tool روی سیستم‌عامل‌های پشتیبانی‌شده استفاده کرد.
نکته مهم این است که خاموش‌بودن QuDedup، نبودن QDFF را ثابت نمی‌کند. QNAP در FAQ بکاپ ابری توضیح داده که Version Management هم می‌تواند چنین خروجی‌ای ایجاد کند. نوع مقصد و تنظیمات Job واقعی را بررسی کنید.
پیش از حادثه، ابزار استخراج را روی کامپیوتری غیر از NAS آماده کنید و با کل مجموعه بکاپ لازم، یک نسخه جدید و یک نسخه قدیمی را در مسیر جدا استخراج کنید. فقط به پیش‌نمایش نام فایل‌ها اکتفا نکنید؛ چند فایل واقعی از انواع موردنیاز شرکت را باز کنید.
گزارش‌های تاریخی کاربران درباره ندیدن نسخه‌ها یا شکست استخراج، دلیل خوبی برای این آزمون‌اند؛ اما دلیل نمی‌شوند برای تمام نسخه‌های فعلی همان علت یا یک دستور تعمیر ثابت تجویز کنیم. اگر استخراج خطا داد، نسخه ابزار، متن خطا و ساختار مجموعه را ثبت کنید و تنها نسخه بکاپ را دست‌کاری نکنید.
رمز و کلید موردنیاز را هم جدا از تنها دستگاه یا حسابی نگه دارید که ممکن است از دسترس خارج شود. بکاپ رمزگذاری‌شده بدون مسیر مجاز دسترسی به کلید، هنوز یک راه بازگشت آماده نیست.
فایل دیتابیس با برنامه قابل استفاده تفاوت دارد
دیدن فایل حسابداری یا پایگاه‌داده در Snapshot ثابت نمی‌کند برنامه از آن وضعیت درست اجرا خواهد شد. داده‌های در حال نوشتن و نیازهای همان نرم‌افزار باید در برنامه بکاپ لحاظ شوند.
QNAP برای محیط‌های پشتیبانی‌شده میان Crash-consistent و Application-consistent تفاوت می‌گذارد و Snapshot Agent را برای هماهنگی با برنامه ارائه می‌کند. وجود این قابلیت، هر پوشه SMB یا هر نرم‌افزار حسابداری را خودکار تحت پوشش آن قرار نمی‌دهد.
برای داده‌های برنامه‌ای، روش بکاپ مورد تأیید همان نرم‌افزار را مشخص کنید. آزمون نهایی هم فقط کپی فایل نیست: برنامه باید در محیط مناسب باز شود و اطلاعات موردانتظار در آن قابل استفاده باشد.
تنظیمات NAS، کاربران و تنظیمات اختصاصی اپ‌ها نیز با محتوای پوشه‌ها یک پوشش واحد ندارند. بعد از بازیابی، با یک حساب مجاز و یک حساب غیرمجاز دسترسی پوشه‌های حساس را بررسی کنید؛ وجود فایل‌ها به‌تنهایی درستی مجوزها را ثابت نمی‌کند.
زمان‌بندی را از مقدار کار قابل ازدست‌رفتن تعیین کنید
ابتدا مشخص کنید در هر نوع حادثه، از دست دادن چه مقدار کار برای شرکت قابل تحمل است. این مقدار را RPO می‌نامند. سپس مشخص کنید حداکثر تا چه زمانی باید کار ضروری شرکت دوباره راه بیفتد؛ این زمان هدف، RTO است.
در یک مثال فرضی، شرکت Snapshot ساعتی و بکاپ مستقل شبانه دارد. ساعت ۱۱:۲۰ یک فایل حذف می‌شود و آخرین Snapshot سالم آن مربوط به ساعت ۱۱ است؛ در صورت بازیابی از همان نسخه، تغییرات پس از ساعت ۱۱ در آن وجود ندارند. اگر به‌جای حذف فایل، کل NAS و Pool از دست بروند، باید زمان آخرین بکاپ مستقل سالم و کامل‌شده را مبنا بگیرید؛ مثلاً بکاپ کامل‌شده ساعت ۲ بامداد، تغییرات بعد از آن را پوشش نمی‌دهد.
این مثال، برنامه ثابت برای همه شرکت‌ها نیست. برای قراردادهای جاری و خروجی حسابداری ممکن است نیاز متفاوتی با آرشیو رسانه‌ای داشته باشید. مهم است بدانید آخرین نسخه قابل استفاده هر گروه واقعاً مربوط به چه زمانی است.
زمان برگشت به کار را هم فقط از سرعت کپی حدس نزنید. آماده‌سازی دستگاه، دریافت داده از مقصد، استخراج، بازکردن نرم‌افزار و برگرداندن مجوزها زمان می‌خواهند. مخصوصاً در بکاپ ابری، دسترس‌پذیری حساب و سرعت دانلود را در همان محیط شرکت آزمایش کنید.
یک تمرین بازیابی که نتیجه روشن دارد
برای شروع، لازم نیست کل آرشیو شرکت را برگردانید. یک قرارداد، یک فایل پروژه و یک خروجی بکاپ نرم‌افزار را با هماهنگی مسئول داده انتخاب کنید و نتیجه را ثبت کنید.
| مرحله آزمون | نتیجه‌ای که باید ثبت شود |
|---|---|
| انتخاب نسخه | نام Job، تاریخ نسخه و علت انتخاب آن |
| آماده‌سازی | ابزار، دسترسی به مقصد و وجود کلید لازم |
| برگرداندن به مسیر جدا | مسیر خروجی، زمان شروع و پایان و خطاهای احتمالی |
| بررسی فایل یا برنامه | بازشدن، محتوای موردانتظار و کامل‌بودن اجزا |
| بررسی دسترسی | نتیجه ورود کاربر مجاز و غیرمجاز |
| سنجش ادامه کار | زمان لازم برای انجام یک کار ضروری واقعی |
| اصلاح | مشکل، مسئول پیگیری و زمان آزمون مجدد |
Quick Check یا Content Check در HBS برای بررسی صحت مفیدند، اما جای این تمرین را نمی‌گیرند. پیام Completed هم فقط بخشی از شواهد است؛ باید نشان دهید از نسخه درست، داده قابل استفاده برگردانده‌اید.
بعد از تغییر مهم در نرم‌افزار بکاپ، مقصد یا ساختار ذخیره‌سازی، بخش مرتبط این تمرین را تکرار کنید. برنامه‌ای که سال قبل آزمایش شده، به‌تنهایی وضعیت امروز را تأیید نمی‌کند.
جمع‌بندی؛ ترکیب Snapshot و بکاپ برای فایل‌های شرکت
فهرست پوشه‌های حیاتی و مسئول هرکدام را بنویسید. کنار هر پوشه، مقدار کار قابل ازدست‌رفتن، زمان موردنیاز برای برگشت و آخرین نسخه مستقل قابل استفاده را ثبت کنید. بعد مشخص کنید Snapshot، تاریخچه بکاپ و نسخه بیرون از دستگاه، کدام قسمت این نیاز را پوشش می‌دهند.
اگر از دیسک‌های گردشی استفاده می‌کنید، مسئول اجرا و فاصله تازگی نسخه را مشخص کنید و نسخه لازم را پس از تکمیل و کنترل Job از دسترس عادی شبکه جدا نگه دارید. یک هارد همیشه‌متصل را نسخه آفلاین حساب نکنید.
Snapshot برای برگشت سریع مفید است؛ بکاپ مستقل برای باقی‌ماندن راه بازیابی پس از خرابی محل اصلی لازم است. طرح حفاظت شرکت زمانی قابل اتکاتر می‌شود که برای حادثه مشخص، نسخه سالم، ابزار، دسترسی و زمان برگشت را در یک آزمون واقعی نشان داده باشید.
اگر برای انتخاب مقصد بکاپ و طراحی مسیر بازیابی به بررسی نیاز دارید، خدمات طراحی و راه‌اندازی زیرساخت ذخیره‌سازی انتخاب سیستم می‌تواند نقطه شروع بررسی نیاز مجموعه باشد. برای این بررسی، حجم و نوع داده، ساختار فعلی NAS، زمان قابل تحمل توقف و نتیجه آخرین تست بازیابی را آماده کنید.
سوالات متداول
سطل بازیافت QNAP چه تفاوتی با Snapshot دارد؟
Network Recycle Bin برای نگهداری موقت فایل‌های حذف‌شده در مسیرهای پشتیبانی‌شده است؛ Snapshot وضعیت قبلی داده را در زمان ثبت نسخه در اختیار می‌گذارد. برای فایلی که محتوایش اشتباه ذخیره شده ولی حذف نشده است، صرف داشتن سطل بازیافت راه برگشت به محتوای قبلی نیست. فعال‌بودن و دسترسی سطل بازیافت هر پوشه را جدا بررسی کنید و آن را نسخه‌ای مستقل از NAS حساب نکنید.
پس از حذف فایل می‌توان با فعال‌کردن Snapshot آن را برگرداند؟
Snapshot تازه وضعیت پس از حذف را ثبت می‌کند و تاریخچه‌ای از قبل از فعال‌شدن خود نمی‌سازد. برای فایل حذف‌شده، سطل بازیافت، Snapshot قدیمی موجود و بکاپ‌های قبلی را بررسی کنید. اگر هیچ نسخه‌ای ندارید، قبل از تغییرات گسترده در فضای ذخیره‌سازی، وضعیت را برای بررسی تخصصی حفظ کنید؛ موفقیت بازیابی را نمی‌توان تضمین کرد.
حذف Snapshot چه اثری بر فایل‌های فعلی و نسخه‌های قدیمی دارد؟
حذف یک Snapshot، نقطه بازیابی مربوط به آن زمان را از بین می‌برد و معادل حذف فایل‌های فعلی پوشه نیست. با حذف نسخه قدیمی ممکن است تنها راه دسترسی به محتوایی را از دست بدهید که قبلاً پاک یا بازنویسی شده است. پیش از حذف برای آزادکردن فضا، تاریخ‌های موردنیاز و وجود نسخه جایگزین قابل بازیابی را مشخص کنید.
چرا پس از حذف Snapshot فضای Pool به اندازه انتظار آزاد نمی‌شود؟
مصرف و ظرفیت آزاد Pool فقط از تعداد Snapshotهای قابل مشاهده تعیین نمی‌شود؛ نوع تخصیص Volume، فضای رزروشده Snapshot و در بعضی پیکربندی‌ها فضای قابل بازپس‌گیری نیز اثر دارند. در Storage & Snapshots مصرف Pool و اجزای آن را بررسی کنید و انتظار نداشته باشید حذف یک مورد، حتماً به همان اندازه ظرفیت قابل استفاده ایجاد کند. راهکارهای تغییر ساختار ذخیره‌سازی را بدون بررسی اثرشان بر سرویس‌ها و نسخه‌های بازیابی اجرا نکنید.
چند Snapshot یا چند روز تاریخچه بکاپ برای شرکت کافی است؟
تعداد کافی از فاصله ثبت نسخه‌ها، زمان معمول کشف اشتباه و ظرفیت واقعی به دست می‌آید. اگر تغییر اشتباه را دو هفته بعد پیدا می‌کنید، نگهداری تعداد زیادی نسخه که همگی مربوط به چند روز اخیرند مشکل را حل نمی‌کند. ابتدا بازه موردنیاز هر گروه داده را مشخص کنید، سپس ثبت و باقی‌ماندن نسخه‌های همان بازه را در عمل کنترل کنید.
پیام Completed with warning در HBS یعنی بکاپ قابل استفاده است؟
پیام Completed with warning به معنی موفقیت بی‌نقص همه فایل‌ها نیست؛ ممکن است برخی فایل‌ها رد شده یا بخشی از ویژگی‌هایشان منتقل نشده باشد. در HBS، گزارش همان نوبت اجرا و File History را بخوانید و نام فایل، وضعیت و علت هشدار را مشخص کنید. اگر فایل حیاتی درگیر است، تا رفع مشکل و آزمون بازیابی آن فایل، این اجرا را پوشش تأییدشده آن داده محسوب نکنید.
پس از تعویض مقصد بکاپ یا به‌روزرسانی HBS چه چیزی را دوباره آزمایش کنیم؟
آزمون را روی بخشی تکرار کنید که تغییر کرده است: دسترسی به مقصد، اجرای Job و بازیابی داده از خروجی جدید. اگر نسخه‌های قدیمی همچنان بخشی از برنامه حفاظت‌اند، دسترسی به یک نسخه قدیمی را هم بررسی کنید. نام و نسخه ابزار، تاریخ بکاپ انتخاب‌شده و نتیجه بازکردن فایل را ثبت کنید تا فقط به موفقیت تنظیم قبلی متکی نباشید.
Immutable بودن نسخه، سالم‌بودن محتوای آن را هم ثابت می‌کند؟
قفل نگهداری مشخص می‌کند نسخه در چه شرایطی قابل تغییر یا حذف است؛ این ویژگی به‌تنهایی درستی محتوای فایل را تأیید نمی‌کند. اگر داده پیش از ثبت نسخه خراب یا رمزگذاری شده باشد، قفل‌شدن همان داده آن را به فایل سالم تبدیل نمی‌کند. انتخاب تاریخ قبل از حادثه و بررسی واقعی محتوا همچنان لازم است.
برای برگرداندن فایل شرکت، تأیید کدام فرد لازم است؟
مسئول فنی باید مسیر بازیابی و اثر عملیات را بررسی کند، اما صحت تجاری محتوا را مسئول همان داده بهتر تشخیص می‌دهد. برای مثال، بازشدن فایل حسابداری کافی نیست؛ مسئول مالی باید دوره، اطلاعات و خروجی موردنیاز را تأیید کند. پیش از جایگزینی فایل اصلی، نتیجه بررسی، نسخه انتخاب‌شده و فرد تأییدکننده را ثبت کنید.
در تحویل تنظیمات بکاپ چه گزارشی از مجری بخواهیم؟
گزارش تحویل باید مشخص کند چه پوشه‌هایی حفاظت می‌شوند، نسخه‌ها کجا و تا چه زمانی می‌مانند و آخرین اجرای موفق مربوط به چه تاریخی است. نتیجه یک تست بازیابی، ابزار و دسترسی لازم، زمان اندازه‌گیری‌شده و مسئول پیگیری هشدارها را هم بخواهید. فهرست Jobها بدون این شواهد، نشان نمی‌دهد شرکت در حادثه مشخص چگونه به کار برمی‌گردد.
