Backup & Recovery برای پشتیبان شبکه

Backup یک نسخه مستقل و قابل بازیابی از داده است که برای برگشت به وضعیت سالم در زمانی مشخص نگهداری می‌شود. تفاوت مهم آن با Copy ساده این است که یک سیستم Backup معمولاً Restore Point، تاریخچه، Retention، گزارش اجرا، اعتبارسنجی و روش مشخص بازیابی دارد. Copy کردن یک پوشه به هارد دوم ممکن است برای یک کار موقت مفید باشد، اما اگر فایل آلوده یا اشتباه حذف شود و همان تغییر به مقصد هم منتقل شود، نسخه قابل برگشت لزوماً باقی نمی‌ماند. Sync نیز هدفش هماهنگ نگه‌داشتن دو سمت است؛ بنابراین در بسیاری از سناریوها حذف یا خراب‌شدن فایل می‌تواند به مقصد هم منتقل شود. Snapshot هم یک وضعیت نقطه‌ای از همان Storage یا همان زیرساخت است و معمولاً برای بازگشت سریع قبل از تغییر کوتاه‌مدت استفاده می‌شود، نه برای حفاظت مستقل در برابر خرابی کامل Storage، حذف عمدی، بدافزار یا از دست رفتن سایت. برای پشتیبان شبکه مهم است که قبل از انتخاب ابزار، سؤال را درست بپرسد: «اگر منبع اصلی کاملاً از بین رفت، آیا نسخه‌ای مستقل، سالم و قابل Restore دارم؟» اگر پاسخ وابسته به همان سرور، همان Datastore یا همان Credentialهای Production باشد، هنوز ریسک بزرگی باقی مانده است. یک برنامه Backup خوب همیشه با Restore تعریف می‌شود؛ یعنی از همان روز اول باید بدانی چه چیزی را، تا چه تاریخی، در چه زمانی و روی چه مقصدی برمی‌گردانی

RPO یا Recovery Point Objective مشخص می‌کند در یک حادثه حداکثر چه مقدار از داده‌های جدید می‌تواند از دست برود. اگر RPO یک سرویس ۲۴ ساعت باشد، Backup روزانه ممکن است کافی باشد، اما برای دیتابیس سفارش‌ها یا CRM که هر ساعت تغییر می‌کند چنین فاصله‌ای شاید غیرقابل قبول باشد. RTO یا Recovery Time Objective مدت زمانی است که سرویس باید بعد از حادثه دوباره قابل استفاده شود. این دو معیار یکی نیستند: ممکن است Backup هر ۱۵ دقیقه داشته باشی اما Restore کامل چند ساعت طول بکشد، در نتیجه RPO خوب و RTO بد باشد. برای تعریف این دو عدد نباید از روی سلیقه IT تصمیم بگیری؛ باید با مالک سرویس، مدیر مالی یا واحد عملیاتی صحبت شود و اثر توقف سرویس و از دست رفتن داده بررسی شود. بعد از تعیین RPO و RTO می‌توان درباره تعداد Jobها، فرکانس اجرا، نوع Repository، پهنای باند، Instant Recovery، Replica، Backup Copy و نگهداری Offsite تصمیم گرفت. همچنین باید RPO واقعی را از RPO روی کاغذ جدا کنی. اگر Job قرار است هر ساعت اجرا شود ولی سه شب است Failed می‌شود، RPO واقعی دیگر یک ساعت نیست. بنابراین مانیتورینگ Job و Alert بخشی از تحقق RPO است، نه یک موضوع جانبی. در مستند Backup هر سرویس باید Owner، RPO، RTO، روش Restore و اولویت بازیابی ثبت شود

قانون کلاسیک 3-2-1 می‌گوید حداقل سه نسخه از داده داشته باشی، روی دو نوع رسانه یا بستر نگهداری کنی و یک نسخه را خارج از محل اصلی نگه داری. در رویکرد 3-2-1-1-0 که Veeam نیز روی آن تأکید می‌کند، یک نسخه دیگر باید Offline، Air-gapped یا Immutable باشد و «۰» به این معناست که تست بازیابی بدون خطا انجام شده باشد. نکته اصلی این قانون شمردن هاردها نیست؛ هدف حذف Failure Domain مشترک است. اگر Production و Backup هر دو روی یک SAN، یک حساب Domain Admin و یک اتاق باشند، با خرابی Storage، آتش‌سوزی یا باج‌افزار ممکن است هر دو از دست بروند. حتی یک NAS جدا اگر با همان Credential دائماً Writable باشد، در برابر مهاجم دارای دسترسی مدیریتی آسیب‌پذیر است. نسخه Immutable روی Hardened Repository یا Object Storage دارای Object Lock کمک می‌کند Backup در مدت مشخص قابل حذف یا تغییر نباشد. Offsite نیز باید واقعاً از سایت اصلی جدا باشد و پهنای باند و زمان بازیابی آن از قبل سنجیده شود. برای یک شرکت کوچک هم می‌توان این اصل را ساده اجرا کرد: Production، Repository محلی برای Restore سریع، Backup Copy به مقصد دوم و یک نسخه Immutable یا Offline. اما تا زمانی که Restore Test انجام نشده، فقط می‌دانی فایل Backup وجود دارد، نه اینکه کسب‌وکار واقعاً قابل بازیابی است

Full Backup نسخه کامل مجموعه داده در زمان اجرای Job است و ساده‌ترین تصویر ذهنی را دارد، اما خواندن دوباره کل منبع می‌تواند زمان و I/O زیادی مصرف کند. Incremental فقط تغییرات از آخرین Backup مرتبط را ذخیره می‌کند و به همین دلیل اجرای روزانه سریع‌تر و کم‌حجم‌تر است. Differential در بسیاری از محصولات سنتی تغییرات از آخرین Full را جمع می‌کند، بنابراین هر روز بزرگ‌تر می‌شود؛ Veeam برای Backup Chainهای VM عمدتاً از مدل‌های Forward Incremental و Forever Forward Incremental استفاده می‌کند و Reverse Incremental در مستندات جدید Deprecated شده است. Synthetic Full یک Full جدید را در Repository از Full و Incrementalهای موجود می‌سازد و لازم نیست کل داده دوباره از Production خوانده شود؛ در مقابل Active Full دوباره کل داده را از Source می‌خواند و یک Full تازه می‌سازد. انتخاب روش باید با سرعت Source، قدرت Repository، پنجره Backup، پهنای باند و ظرفیت Storage هماهنگ باشد. Synthetic Full فشار بیشتری روی Repository ایجاد می‌کند، در حالی که Active Full فشار بیشتری روی Source و شبکه می‌تواند داشته باشد. مهم‌تر از نام روش این است که زنجیره را بفهمی: هر Restore Point ممکن است برای ساخته‌شدن به چند فایل در Chain وابسته باشد، پس خراب‌شدن یا حذف تصادفی بخشی از Chain می‌تواند Restoreهای بعدی را هم تحت تأثیر قرار دهد. Health Check و تست Restore برای همین اهمیت دارند

در Veeam یک Restore Point نمایش منطقی وضعیت یک Workload در زمان مشخص است و الزاماً برابر با یک فایل واحد روی Disk نیست. در Backupهای VMware معمولاً فایل VBK Full Backup را نگه می‌دارد و فایل‌های VIB شامل Incrementalهای Forward هستند. Metadata و اطلاعات Job نیز برای مدیریت Backup و نمایش Restore Pointها اهمیت دارند. وقتی کاربر می‌گوید «نسخه سه‌شنبه را برگردان»، نرم‌افزار باید از Backup Chain داده لازم برای ساخت همان وضعیت را بخواند. بنابراین نباید فایل‌های Backup را به‌صورت دستی از Repository حذف، Rename یا جابه‌جا کنی مگر با روش پشتیبانی‌شده، چون Configuration Database ممکن است هنوز انتظار حضور آن‌ها را داشته باشد. Retention نیز بر اساس Restore Pointها و Chain عمل می‌کند و حذف یک Restore Point قدیمی در برخی روش‌ها با Merge یا Transform همراه می‌شود. یک پشتیبان شبکه باید بتواند در Console تفاوت Backups، Disk/Imported Backups، Job، Session و Restore Point را تشخیص دهد و صرفاً با دیدن حجم Folder نتیجه‌گیری نکند. همچنین اگر Backup را به Storage جدید منتقل می‌کنی باید از Move/Copy/Import و Mapping مناسب استفاده شود تا Veeam ارتباط بین فایل‌ها و Job را حفظ کند. در Incident، قبل از هر حذف دستی روی Repository از Job و Chain وضعیت دقیق بگیر و اگر فضای Disk بحرانی است اول دلیل مصرف را شناسایی کن

Retention مشخص می‌کند چه تعداد یا چه مدت Restore Point نگه داشته شود. برای بازیابی خطاهای روزمره معمولاً Restore Pointهای کوتاه‌مدت کافی‌اند؛ مثلاً نسخه‌های چند روز یا چند هفته اخیر. اما بعضی سازمان‌ها نیاز دارند نسخه‌های هفتگی، ماهانه یا سالانه را برای مدت طولانی حفظ کنند. Veeam برای این سناریو از GFS یا Grandfather-Father-Son استفاده می‌کند و Backupهای مشخص را با Flag هفتگی، ماهانه یا سالانه نگه می‌دارد. اشتباه رایج این است که Retention را فقط یک عدد بزرگ کنیم بدون اینکه ظرفیت Repository و رشد Workload را محاسبه کنیم. اگر داده فعال شرکت هر ماه رشد می‌کند یا Change Rate بالاست، ۳۰ Restore Point لزوماً برابر با ۳۰ روز ظرفیت ثابت نیست. باید Full Size، Change Rate روزانه، Compression/Deduplication، Synthetic Full و فضای Work Area در Repository را در نظر بگیری. همچنین Retention طولانی به معنی Backup سالم نیست؛ Backup قدیمی اگر هیچ‌وقت تست نشده باشد فقط Storage مصرف می‌کند. برای اسناد مالی یا الزامات قانونی ممکن است مدت نگهداری توسط سیاست سازمان تعیین شود و IT نباید خودسرانه آن را کوتاه کند. در سمت دیگر، نگهداری بیش از نیاز نیز هزینه و سطح داده حساس را افزایش می‌دهد. بهترین طراحی، Retention جدا برای Workloadهای مختلف است؛ Domain Controller، File Server، SQL و Archive الزام یکسان ندارند

Veeam Backup & Replication یک برنامه تک‌مرحله‌ای که فقط «کپی» کند نیست؛ معماری آن چند نقش دارد. Backup Server مدیریت مرکزی Configuration، Jobها و Sessionها را انجام می‌دهد. VMware Backup Proxy داده VM را از vSphere می‌خواند و Data Mover روی آن در مسیر انتقال نقش دارد. Repository محل نگهداری Backup Fileهاست و ممکن است Windows، Linux، Hardened Repository، NAS، Deduplicating Appliance یا Object Storage باشد. Mount Server در عملیات‌هایی مثل File-Level Restore برای Mount کردن محتوای Backup استفاده می‌شود. Guest Interaction Proxy یا مؤلفه‌های Guest Processing برای Application-Aware Processing و کارهای داخل Guest استفاده می‌شوند. در محیط کوچک ممکن است چند نقش روی یک Server باشند، اما این به معنی یکی بودن مفهوم آن‌ها نیست. وقتی Job کند است باید بدانی Bottleneck در Source، Proxy، Network یا Target است؛ وقتی Restore فایل باز نمی‌شود باید Mount Server و ارتباط با Repository را بررسی کنی؛ وقتی Application-Aware Failure داریم، مشکل ممکن است Credential یا VSS داخل Guest باشد و ربطی به Repository نداشته باشد. از نظر امنیتی نیز بهتر است Backup Infrastructure تا حد ممکن از Production جدا و سخت‌سازی شود. هر نقش به Port، Credential و Resource مناسب نیاز دارد. قبل از نصب یک Diagram ساده بکش تا بعداً در Troubleshooting مجبور نباشی معماری را از روی حدس کشف کنی

قبل از نصب Backup Server باید بدانیم قرار است از چه Workloadهایی، با چه حجمی و در چه پنجره‌ای Backup بگیریم. تعداد VMها به‌تنهایی معیار ظرفیت نیست؛ حجم مصرف‌شده Disk، Change Rate، تعداد Jobهای هم‌زمان، سرعت Repository، لینک شبکه و RPO روی طراحی اثر دارند. اگر Production روی 10GbE است ولی Repository روی یک NAS کند با یک لینک 1GbE قرار دارد، Backup Window ممکن است از ساعات کاری عبور کند. DNS و Time نیز باید درست باشند، مخصوصاً وقتی vCenter، Domain و Application-Aware Processing درگیر هستند. Credentialها باید بر اساس Least Privilege و نقش جدا نگهداری شوند و حساب‌های حساس Backup نباید برای کار روزمره استفاده شوند. برای Repository باید Space Headroom در نظر بگیری؛ پرشدن Repository فقط باعث Failure Job نمی‌شود، بلکه عملیات Merge، Synthetic Full و Restore را نیز می‌تواند مختل کند. Antivirus/EDR Exclusionها باید فقط مطابق مستند رسمی Vendor و با هماهنگی امنیت اعمال شوند، نه اینکه برای رفع خطا کل Folder یا Processها بدون بررسی از اسکن خارج شوند. همچنین Backup Server خودش یک Asset حیاتی است و Configuration Backup، Patch، MFA در محل‌های قابل پشتیبانی، Firewall و جداسازی مدیریتی آن باید جزو طراحی باشد. قبل از نصب، Port Matrix و ارتباطات مورد نیاز را بررسی کن تا بعداً هر Failure را با خاموش‌کردن Firewall «حل» نکنی

نصب Veeam باید روی Server یا Appliance مطابق System Requirements نسخه مورد استفاده انجام شود و قبل از شروع باید Compatibility Matrix را ببینی. در محیط Windows-based، Installer اجزای مورد نیاز را بررسی می‌کند و Database Configuration نیز بخشی از نصب است. نباید Database، Repository و Backup Server را صرفاً چون Wizard اجازه می‌دهد بدون درنظرگرفتن اندازه محیط روی یک Volume کوچک قرار دهی. بعد از نصب، اولین کار شناخت Console و بخش‌های Inventory، Backup Infrastructure، Home و History است. License یا Community Edition نیز روی امکانات قابل استفاده اثر دارد و باید نسخه دقیق و Build ثبت شود. در همین مرحله Configuration Backup را فعال کن و مقصد آن را روی Repository مناسبی بگذار؛ چون اگر Backup Server از دست برود، داشتن Backup VMهای Production بدون Configuration و اطلاعات Jobها بازیابی مدیریت را دشوارتر می‌کند. Patch Level و Update History خود Veeam نیز مهم است و قبل از Update باید Release Note و Compatibility با vSphere و Repositoryها بررسی شود. در محیط Production هر تغییر Version باید Backup Configuration و نقطه بازگشت مشخص داشته باشد. همچنین Service Accountها و Credential Manager را از ابتدا مرتب نگه دار. نصب زمانی کامل است که بعد از پایان Wizard بدانی کدام سرویس‌ها حیاتی‌اند و وضعیت Job، Repository و Session را از کجا باید بررسی کنی

برای Backup ماشین‌های VMware، Veeam باید به vCenter یا در محیط‌های کوچک به ESXi متصل شود. وقتی vCenter وجود دارد، معمولاً اضافه‌کردن vCenter باعث می‌شود Inventory متمرکز Datacenter، Cluster، Host و VMها در اختیار Veeam قرار بگیرد و تغییر محل VM در Cluster نیز بهتر مدیریت شود. Credential استفاده‌شده باید سطح دسترسی مورد نیاز عملیات Backup را داشته باشد و در محیط سازمانی بهتر است حساب اختصاصی و مستند ایجاد شود. DNS و Certificate در اولین اتصال اهمیت دارند؛ اگر با IP وصل می‌شوی ولی بعداً FQDN و Certificate تغییر می‌کند، مدیریت اعتماد پیچیده‌تر می‌شود. بعد از Add کردن Server، Inventory را Refresh کن و مطمئن شو VMها، Datastoreها و Hostها همان چیزی هستند که انتظار داری. در محیط‌هایی که vCenter وجود دارد، اضافه‌کردن جداگانه همان ESXiها می‌تواند طراحی را گیج‌کننده کند و Jobها باید بر اساس معماری مشخص ساخته شوند. همچنین Credential Rotation را فراموش نکن؛ تغییر Password بدون Update در Veeam باعث Failureهای ناگهانی می‌شود. اگر Add Server خطا می‌دهد، قبل از خاموش‌کردن Firewall، DNS Resolution، Port، Time، Credential و Certificate را مرحله‌ای بررسی کن. یک اتصال موفق فقط پایان Wizard نیست؛ Job بعداً باید بتواند Snapshot، CBT و Data Transfer را طبق روش پشتیبانی‌شده انجام دهد

Backup Repository محل اصلی Backup Fileها و Metadata است و سرعت، ظرفیت و امنیت آن مستقیماً روی Backup و Restore اثر دارد. Veeam از Repositoryهای Windows، Linux، Hardened Repository، SMB/NFS Share، Deduplicating Appliance و Object Storage پشتیبانی می‌کند، اما مناسب‌بودن هر گزینه به سناریو وابسته است. Repository باید برای Write سنگین Backup، Read در Restore، Synthetic Full و Health Check توان کافی داشته باشد. اگر از NAS استفاده می‌کنی باید Gateway و مسیر شبکه را نیز در نظر بگیری. اگر Repository روی همان Storage Production باشد، Failure Domain جدا نشده و در حادثه Storage هر دو از بین می‌روند. فایل‌سیستم، Block Size یا تنظیمات Vendor-specific باید بر اساس راهنمای همان Repository و Veeam انتخاب شود. از ساخت چند Repository با Path یکسان یا Nested Path که Veeam هشدار می‌دهد خودداری کن. Capacity Tier و Object Storage برای طراحی‌های بزرگ‌تر موضوع جداست، اما برای شروع باید مفهوم Local Repository، Free Space، Concurrent Tasks و Maintenance را بفهمی. همچنین Repository نباید Share عمومی کاربران باشد و دسترسی تعاملی روزمره روی آن به حداقل برسد. قبل از افزودن Repository، سرعت واقعی نوشتن و فضای آزاد را ثبت کن و بعد از اولین Job Bottleneck Statistics را ببین تا بفهمی Target توان لازم را دارد یا نه

Veeam Hardened Repository روی Linux برای افزایش مقاومت Backup در برابر Malware و حذف ناخواسته طراحی شده است. قابلیت کلیدی Immutability است؛ Restore Pointها در دوره مشخص قابل Move، Modify یا Delete نیستند و این موضوع حتی در سناریوی compromise شدن Backup Server لایه مهمی ایجاد می‌کند. در طراحی جدید Veeam، Single-use Credentials یا روش‌های امن احراز هویت کمک می‌کنند Credential دائمی با سطح بالا روی Backup Server ذخیره نشود. اما Hardened Repository فقط یک Checkbox نیست؛ Linux Host باید مخصوص Backup، Patch‌شده، با دسترسی محدود، Network مناسب و بدون Roleهای غیرضروری باشد. دوره Immutability باید با Retention و ظرفیت Storage هماهنگ شود؛ اگر ۳۰ روز داده Immutable نگه می‌داری ولی Space فقط برای ۱۵ روز است، نمی‌توانی برای آزادکردن فضا Restore Pointهای قفل‌شده را حذف کنی. همچنین Health Check روی Linux Immutable Repository محدودیت‌هایی در Repair دارد و اگر Corruption شناسایی شود ممکن است نیاز به Active Full جدید داشته باشی. ساعت سیستم نیز اهمیت دارد و نباید مهاجم با تغییر Time بتواند حفاظت را دور بزند؛ به همین دلیل طراحی Time و Hardening Vendor را دقیق دنبال کن. Immutable بودن جای Backup Copy Offsite یا Restore Test را نمی‌گیرد؛ فقط یکی از لایه‌های دفاع است

VMware Backup Proxy نقش خواندن داده VM از Source و انتقال آن به مسیر Backup را دارد. Veeam Transport Modeهای Direct Storage Access، Virtual Appliance یا HotAdd و Network را ارائه می‌کند و انتخاب مناسب به معماری Storage و محل Proxy بستگی دارد. Direct SAN در محیط‌هایی که Proxy فیزیکی به SAN دسترسی مستقیم دارد می‌تواند داده را بدون عبور از شبکه Management بخواند، اما نیازمندی‌های HBA و Storage Presentation دقیق دارد. HotAdd معمولاً برای Proxy مجازی استفاده می‌شود و Diskهای VM در زمان Job به Proxy متصل می‌شوند؛ این روش باید با محدودیت‌های SCSI Controller، Datastore Access و Cleanup آشنا باشد. Network Mode ساده‌تر است اما داده از ESXi Management/Network Stack عبور می‌کند و ممکن است Throughput محدودتری داشته باشد. Veeam به‌صورت خودکار بهترین Mode قابل استفاده را انتخاب می‌کند، ولی در Troubleshooting باید Session Log و Statistics را ببینی تا بفهمی Job واقعاً با چه Mode اجرا شده است. اگر انتظار HotAdd داری ولی Job دائماً Network Mode است، ممکن است Proxy به Datastore دسترسی نداشته باشد یا Requirement دیگری برآورده نشده باشد. Forced Mode بدون فهم شرایط می‌تواند Job را Fail کند. طراحی Proxy باید Concurrent Task، CPU/RAM، Placement و مسیر Network تا Repository را نیز در نظر بگیرد

برای ساخت اولین Backup Job بهتر است یک VM آزمایشی انتخاب کنی، نه مهم‌ترین Server شرکت. Job Name باید معنا داشته باشد؛ مثلاً محیط، نوع Workload و فرکانس را نشان دهد. در انتخاب Source می‌توان VM، Folder، Tag یا Containerهای vSphere را انتخاب کرد. استفاده از Folder یا Tag در محیط پویا مزیت دارد چون VMهای جدید می‌توانند طبق Policy وارد Job شوند، اما باید Exclusion و Scope را دقیق بفهمی تا ناخواسته سیستم بزرگی وارد Backup نشود. در مرحله Storage، Repository، Retention و Advanced Settings تعیین می‌شوند. در Guest Processing تصمیم می‌گیری Application-Aware Processing و Indexing لازم است یا نه. Schedule نیز باید با RPO و Backup Window هماهنگ باشد. قبل از Finish Summary را مثل Change Request بخوان؛ Source، Target، Retention، Proxy، Guest Processing و Schedule را یک‌بار دیگر کنترل کن. بعد از اولین Run، صرفاً Success سبز را کافی ندان. Duration، Data Read، Transferred، Bottleneck و Warningها را بخوان و Restore Point را در Backups بررسی کن. Job موفقی که از VM اشتباه Backup گرفته یا Application Consistency ندارد، از نظر کسب‌وکار موفق نیست. در Production قبل از Enable Schedule مطمئن شو Repository ظرفیت کافی و Alerting فعال است

در محیط VMware می‌توان Backup Job را بر اساس VM منفرد، Folder، Cluster، Datastore یا Tag طراحی کرد. انتخاب Container مزیت مدیریت خودکار دارد؛ مثلاً اگر تمام VMهای Production در Folder مشخص باشند، اضافه‌شدن VM جدید می‌تواند بدون ویرایش Job تحت حفاظت قرار گیرد. اما همین ویژگی اگر Scope بد باشد خطرناک است. یک ISO Appliance بزرگ یا VM موقت ممکن است ناخواسته وارد Job شود و ظرفیت Repository را مصرف کند. Exclusion نیز باید مستند باشد؛ VMی که «موقتاً» از Backup خارج شده ممکن است ماه‌ها بدون حفاظت بماند. بهتر است Backup Policy با Naming Convention یا Tagهای مشخص مثل Backup-Policy-Gold/Silver هماهنگ شود و یک گزارش دوره‌ای از VMهای بدون Job داشته باشی. در Clusterهای بزرگ، انتخاب کل Cluster بدون Capacity Planning می‌تواند Job را بیش از حد بزرگ کند. همچنین Disk Exclusion باید با فهم Application انجام شود؛ حذف Volume از Backup فقط چون حجیم است ممکن است همان Volume داده اصلی را حذف کند. اگر Temp یا Cache قابل بازسازی است می‌توان با روش پشتیبانی‌شده Exclude کرد، اما تصمیم باید با Owner سرویس ثبت شود. بعد از هر تغییر بزرگ Inventory، VMهای جدید و حذف‌شده را با Job Mapping بازبینی کن

در مرحله Storage Backup Job فقط مقصد را انتخاب نمی‌کنی؛ Retention، روش Full Backup، Compression، Storage Optimization، Health Check و Encryption نیز روی نتیجه اثر دارند. برای Repositoryهای سریع، Synthetic Full می‌تواند از داده موجود Full جدید بسازد و فشار Read از Production را کاهش دهد، ولی Repository باید I/O لازم برای عملیات Synthetic را تحمل کند. Active Full کل VM را دوباره از Source می‌خواند و می‌تواند در روز اجرا Backup Window و Network را تحت فشار بگذارد. Compression و Deduplication داخلی Veeam باید متناسب با نوع Storage انتخاب شوند؛ روی Deduplicating Appliance تنظیمات Vendor-specific ممکن است متفاوت باشد. Block Size یا Storage Optimization نیز روی فایل Backup و Performance اثر دارد و نباید تصادفی تغییر کند. Health Check برای بررسی Integrity Restore Point مهم است و Schedule آن باید خارج از ساعات سنگین Backup باشد. Encryption در صورت نیاز باید با Password Management و Recovery Plan همراه باشد؛ از دست‌دادن Password می‌تواند بازیابی را غیرممکن یا بسیار دشوار کند. قبل از Save کردن Advanced Settings، هر گزینه‌ای که تغییر می‌دهی دلیلش را ثبت کن. Defaults برای بسیاری از محیط‌ها نقطه شروع مناسبی هستند و تغییر برای «Performance بیشتر» بدون اندازه‌گیری اغلب نتیجه معکوس می‌دهد

وقتی از یک VM روشن Snapshot یا Image-Level Backup می‌گیری، ممکن است سیستم‌عامل و Application در همان لحظه داده‌های درون Memory یا Transactionهای باز داشته باشند. Crash-consistent Backup شبیه حالتی است که برق سیستم ناگهان قطع شود و بعد سیستم از Disk برگردد؛ بسیاری از File Systemها می‌توانند Recovery انجام دهند، اما برای Applicationهای تراکنشی مانند Active Directory و SQL Server بهتر است Backup با Application Awareness انجام شود. Veeam برای Windows از Microsoft VSS و Guest Processing استفاده می‌کند تا Writerهای Application فرصت Freeze مناسب، Flush کردن داده و ثبت وضعیت سازگار را داشته باشند. در Wizard گزینه Enable application-aware processing و Guest OS Credentials دیده می‌شود. این Credential باید بتواند Guest Processing لازم را انجام دهد و Network/Firewall داخل Guest نیز باید اجازه ارتباط مورد نیاز را بدهد. Failure در VSS Writer، Serviceهای SQL، DNS یا Credential می‌تواند Job را با Warning یا Failure روبه‌رو کند. نباید برای سبزکردن Job بلافاصله Application-Aware را خاموش کنی؛ اول علت را پیدا کن. در Domain Controller و Database Server، یک Restore قابل اعتماد فقط به Boot شدن Server ختم نمی‌شود؛ Application هم باید در وضعیت سازگار و قابل استفاده بالا بیاید. Guest Processing باید با نوع Workload و توصیه Vendor Application هماهنگ شود

Active Directory و SQL Server هر دو داده تراکنشی دارند و Backup آن‌ها باید با روش پشتیبانی‌شده Application هماهنگ شود. برای Domain Controller، System State و Application-Aware VM Backup هر کدام جایگاه خود را دارند و در سناریوی Forest Recovery باید مستندات Microsoft درباره System State و ترتیب بازیابی Domain Controllerها دنبال شود. Clone کردن یا Restore خام یک DC بدون درک Recovery Procedure می‌تواند مشکلات Replication و Directory ایجاد کند. در SQL Server نیز باید بین Image-Level Backup سازگار، Backup Native Database و Transaction Log Backup تفاوت بگذاری. Veeam می‌تواند با Application-Aware Processing و تنظیمات SQL Transaction Logs در سناریوهای پشتیبانی‌شده Log Processing انجام دهد، اما اگر DBA از Maintenance Plan یا ابزار دیگری برای Log Backup استفاده می‌کند، نباید دو روش بدون هماهنگی Chain تراکنش را مدیریت کنند. RPO دیتابیس ممکن است بسیار کمتر از RPO کل VM باشد. بنابراین برای CRM یا ERP باید با Owner/DBA تعیین شود آیا Restore کل VM کافی است، Restore Database لازم است یا Point-in-Time Recovery نیاز داریم. تست Restore باید نه فقط Boot VM، بلکه Login Application، Database Integrity و Dependencyهای DNS/AD را هم بررسی کند. Backup موفق بدون شناخت Recovery Objective Application یک حفاظت ناقص است

Schedule باید از RPO شروع شود و با Backup Window، بار Production و ظرفیت Repository تطبیق پیدا کند. اگر Job هر ساعت اجرا شود اما هر بار ۹۰ دقیقه طول بکشد، Schedule عملی نیست و Jobها روی هم می‌افتند. برای Backup شبانه نیز باید مدت Job، Synthetic Full، Health Check و Backup Copy را کنار هم ببینی. Veeam امکان Retry خودکار دارد و این برای خطاهای موقت شبکه مفید است، اما Retry نباید علت ثابت Failure را پنهان کند. Notifications باید به Mailbox یا سیستم مانیتورینگ قابل پیگیری بروند و Success، Warning و Failure بر اساس سیاست سازمان بررسی شوند. Warning نیز همیشه بی‌اهمیت نیست؛ مثلاً Application-Aware Failure با Backup Crash-consistent ممکن است Job را Warning کند اما Recovery Quality را تغییر داده باشد. Backup Window می‌تواند جلوی ادامه Job در ساعات کاری را بگیرد، ولی اگر بیش از حد کوتاه باشد Restore Point ناقص ایجاد نمی‌کند و Job متوقف می‌شود. بهتر است برای Workloadهای Critical Job جدا بسازی تا Failure یک VM حجیم کل مجموعه را به تأخیر نیندازد. بعد از چند هفته History، Duration و Throughput را تحلیل کن و Schedule را بر اساس داده واقعی تنظیم کن، نه فقط ساعت دلخواه مدیر IT

بعد از Run اولین Job وارد Session Details شو و فقط به Status نهایی نگاه نکن. Veeam اطلاعاتی مثل Data Read، Transferred، Duration، Processing Rate و Bottleneck را نشان می‌دهد و برای هر VM Task جدا دارد. Data Read مقدار داده‌ای است که Veeam از Source پردازش کرده و Transferred بعد از Compression/Deduplication به Target ارسال شده است. اگر Throughput پایین است، Bottleneck می‌تواند Source، Proxy، Network یا Target باشد و درصدها باید همراه با معماری واقعی تفسیر شوند. Warningهای مربوط به CBT، Snapshot، Guest Processing یا Free Space را باز کن و متن کامل را بخوان. در اولین Full، حجم Transfer زیاد طبیعی است؛ Incrementalهای بعد باید بیشتر با Change Rate هماهنگ باشند. اگر VM بزرگ اما Change Rate کم هر بار Data Read غیرعادی دارد، CBT یا روش Transport را بررسی کن. همچنین Snapshot ایجادشده روی vSphere باید بعد از Job Cleanup شود و Snapshot قدیمی Backup نباید باقی بماند. در vCenter Recent Tasks نیز عملیات Snapshot و Remove Snapshot را ببین. بعد از Success، Restore Point را در Home > Backups باز کن و تاریخ آن را ثبت کن. این عادت باعث می‌شود بعداً وقتی Job کند یا Failed شد Baseline مقایسه داشته باشی

Veeam Health Check برای آخرین Restore Point در Backup Chain CRC Metadata و Hash داده‌های VM را بررسی می‌کند تا Integrity آن را ارزیابی کند. این عملیات ممکن است مجبور باشد چند فایل Chain را بخواند، چون Restore Point منطقی می‌تواند از Full و Incrementalهای مختلف ساخته شود. بنابراین Health Check روی Repository بزرگ زمان و I/O قابل توجهی می‌گیرد و باید Schedule آن با Backup Window هماهنگ شود. اگر Corruption پیدا شود، رفتار Repair به نوع Repository و Chain بستگی دارد. در Linux Immutable Repository امکان Repair مستقیم برخی Corruptionها محدود است و مستندات Veeam اشاره می‌کند ممکن است نیاز به Active Full جدید باشد. Health Check جای Restore Test را نمی‌گیرد؛ Hash صحیح می‌گوید فایل طبق Metadata خراب نشده، اما تضمین نمی‌کند سیستم‌عامل Boot می‌شود یا Application سالم است. برای همین SureBackup و Restore Drill لایه دیگری هستند. Schedule پیش‌فرض Health Check در بعضی نسخه‌ها ماهانه است، ولی باید بر اساس حساسیت و ظرفیت محیط تعیین شود. اگر Repository Storage خطای Hardware، Bad Sector یا Reset دارد، Health Check می‌تواند نشانه‌ها را آشکار کند ولی Root Cause Storage باید جدا حل شود. هر Corruption را Incident مهم تلقی کن و قبل از پاک‌کردن Restore Point، Scope آسیب و وجود نسخه Copy دوم را بررسی کن

Backup Copy Job برای ایجاد نسخه دیگری از Backup در Repository مقصد استفاده می‌شود و کمک می‌کند اصل 3-2-1 را عملی کنی. مقصد می‌تواند در همان سایت برای جداسازی Storage یا در سایت دیگر برای Disaster Recovery باشد، اما ارزش Offsite زمانی است که Failure Domain واقعی جدا باشد. Backup Copy از Backup موجود داده لازم برای ساخت Restore Point مقصد را می‌خواند و لازم نیست دوباره Production VM را Snapshot کند. بنابراین می‌توان شبکه بین Source Repository و Target Repository را جدا مدیریت کرد. Retention Backup Copy می‌تواند با Primary متفاوت باشد و GFS برای نگهداری بلندمدت در Copy مقصد استفاده شود. اگر WAN محدود است، زمان Copy و RPO نسخه Offsite را جدا از Primary Backup حساب کن. نسخه Offsite که سه روز عقب است برای RPO یک ساعت کافی نیست. Encryption در مسیر و روی Backup File نیز بر اساس سیاست امنیت بررسی شود. Seed یا Mapping در محیط‌های WAN خاص ممکن است برای انتقال اولیه کاربرد داشته باشد، ولی باید طبق روش پشتیبانی‌شده انجام شود. مهم است که Copy Job Failure نیز Alert داشته باشد؛ Primary Backup سبز ممکن است تو را فریب دهد در حالی که نسخه Offsite هفته‌ها به‌روز نشده است. Restore از Copy مقصد را حداقل یک‌بار مستقل از Repository اصلی تست کن

Encryption باعث می‌شود Backup File در صورت دسترسی غیرمجاز قابل خواندن نباشد. Veeam می‌تواند Backup Data را با Encryption Key رمز کند و داده رمز‌شده را روی Repository ذخیره کند. اما فعال‌کردن Encryption بدون Key Management خطر جدیدی ایجاد می‌کند: اگر Password یا مکانیزم Recovery گم شود، Restore ممکن است غیرممکن شود. Password نباید در همان فایل مستندات عمومی Backup یا کنار Repository نگهداری شود. از Password Vault سازمانی، دسترسی محدود، Backup خود Vault و فرایند تحویل مدیریتی استفاده کن. همچنین باید CPU Overhead و Deduplication بین Jobهای دارای Encryption را در طراحی Performance بررسی کنی. اگر Backup به Offsite یا Object Storage می‌رود، Encryption at rest و in transit هر دو اهمیت دارند ولی نباید فرض کنی چون Storage Provider Encryption دارد، تمام سیاست داده سازمان پوشش داده شده است. Configuration Backup خود Veeam را نیز می‌توان Encrypt کرد و این برای حفاظت Credentialهای ذخیره‌شده مهم است. هنگام Rotation Password، تأثیر روی Restore Pointهای قدیمی و روش Import آن‌ها را بشناس. Restore Test از Backup Encrypt شده ضروری است تا مطمئن شوی Credential Recovery واقعی کار می‌کند. هدف Encryption حفاظت Confidentiality است؛ Integrity و Availability همچنان به Health Check، Immutability و نسخه‌های جدا نیاز دارند

Configuration Backup اطلاعات Configuration Database و داده لازم برای بازیابی تنظیمات Veeam را ذخیره می‌کند. این Backup با Backup VMهای Production فرق دارد و باید از همان ابتدای نصب فعال شود. اگر Backup Server از بین برود، بدون Configuration Backup می‌توان Backup Fileها را Import کرد، اما بازسازی Jobها، Repositoryها، Credential Mapping و History زمان بیشتری می‌گیرد و احتمال خطای انسانی بالا می‌رود. مقصد Configuration Backup نباید فقط روی System Disk همان Backup Server باشد. بهتر است روی Repository امن و در طراحی‌های حساس روی مقصد Immutable یا Copy دوم نیز حفاظت شود. Encryption Configuration Backup اهمیت ویژه دارد چون Configuration می‌تواند اطلاعات حساس و Credentialهای محافظت‌شده داشته باشد. Schedule را طوری بگذار که بعد از تغییرات مهم Infrastructure نیز نسخه جدید ایجاد شود. Veeam مستند می‌کند که Configuration Backup Snapshotی از Database ایجاد و اطلاعات لازم برای Restore را جمع می‌کند، بنابراین در محیط Database بزرگ بهتر است زمان کم‌بار انتخاب شود. خود فایل Backup و Password آن باید در Disaster Documentation ثبت شوند. یک‌بار در Lab Configuration Restore به Server آزمایشی انجام بده تا مراحل را بشناسی؛ اولین بار نباید وسط بحران واقعی باشد

یکی از رایج‌ترین درخواست‌های Help Desk حذف یا Overwrite اشتباه یک فایل است. در این سناریو Restore کل VM کار درستی نیست. Veeam Guest OS File Restore اجازه می‌دهد فایل یا Folder را مستقیماً از Image-Level Backup در Restore Point مشخص Browse و Recover کنی. Backup Diskها روی Mount Server به شکل منطقی Mount می‌شوند و Veeam Backup Browser محتوای File System را نشان می‌دهد، بدون اینکه کل VM از Backup استخراج و Boot شود. می‌توان فایل را به محل اصلی، محل جدید یا Folder موقت Copy کرد. قبل از Overwrite فایل Production باید Owner تأیید کند نسخه انتخاب‌شده درست است؛ بهتر است ابتدا به مسیر موقت Restore و محتوا بررسی شود. Permissionها و Ownership نیز بسته به روش Restore باید در نظر گرفته شوند. برای File Server بزرگ، جست‌وجوی تاریخ و مسیر درست اهمیت دارد و User باید زمان تقریبی آخرین نسخه سالم را اعلام کند. اگر Backup Encrypt شده است یا Mount Server دسترسی ندارد، Restore Session ممکن است Fail شود و باید Repository، Mount Server و Credential را بررسی کنی. بعد از پایان Recovery Session، Mountها باید Cleanup شوند. نتیجه Restore شامل نام فایل، Restore Point، مقصد و تأیید User در Ticket ثبت شود

Entire VM Restore زمانی استفاده می‌شود که کل ماشین مجازی باید از Restore Point بازگردد؛ مثلاً VM حذف شده، Virtual Disk آسیب دیده یا تغییر بزرگی نیاز به Rollback کامل دارد. در Wizard باید تصمیم بگیری Restore به Original Location باشد یا New Location. Restore به Original Location ممکن است VM فعلی را جایگزین کند و به همین دلیل قبل از اجرا باید وضعیت Production، Snapshot، Backup جدید و Approval را بررسی کنی. Restore به New Location برای Test یا مقایسه امن‌تر است، اما باید Network را Disconnect یا به Isolated VLAN وصل کنی تا IP، Hostname، Domain Membership یا سرویس‌های تکراری با Production Conflict ایجاد نکنند. Datastore مقصد باید ظرفیت کافی داشته باشد و Thin/Thick Provisioning و Performance آن برای Workload مناسب باشد. اگر Restore Point قدیمی است، Application ممکن است با سرویس‌های جدید ناسازگار شود؛ مثلاً DC یا Database در محیط تغییرکرده نیاز به Procedure خاص دارد. بعد از Restore فقط Power On کافی نیست: VMware Tools، IP، DNS، Application Service، Event Log و User Test باید بررسی شوند. سپس Restore Time واقعی را با RTO مقایسه کن. این تمرین باید در Lab یا Window کنترل‌شده انجام شود تا در حادثه واقعی مراحل برایت ناآشنا نباشد

Instant Recovery در Veeam اجازه می‌دهد Workload را مستقیماً از Backup File روی VMware vSphere اجرا کنی، بدون اینکه ابتدا کل Image روی Production Datastore Extract شود. این قابلیت برای سناریویی که RTO کوتاه مهم است بسیار ارزشمند است؛ VM در چند دقیقه قابل Boot می‌شود و کاربر می‌تواند سرویس را موقتاً استفاده کند. Veeam Backup را Read-only Mount می‌کند و تغییرات زمان اجرا در Redo Log یا Datastore انتخابی ذخیره می‌شوند. Performance ممکن است نسبت به VM روی Storage Production محدودتر باشد، چون Read از Repository انجام می‌شود. بنابراین Instant Recovery مرحله اول بازگشت سرویس است و بعد باید VM به Production Storage Migration/Finalize شود. قبل از Start باید Network Mapping را دقیق بررسی کنی؛ اگر Backup از VM آلوده یا خراب منطقی است، اتصال فوری به Production می‌تواند مشکل را برگرداند. Restore Point و Secure Restore/Malware Scan در صورت استفاده باید طبق سیاست امنیت انتخاب شوند. بعد از Boot Application Health و User Test انجام بده و سپس Migration را برنامه‌ریزی کن. Stop Publishing بدون Finalize مناسب می‌تواند VM موقت را از دسترس خارج کند. این قابلیت را حداقل یک‌بار در Lab تمرین کن تا بدانی Repository و Network چه Performance واقعی می‌دهند

وقتی یک User، Group، GPO-linked Object یا Database خاص حذف شده، Restore کل Domain Controller یا SQL Server می‌تواند بیش از حد پرریسک باشد. Veeam Explorers برای Applicationهای پشتیبانی‌شده اجازه می‌دهند Itemهای خاص از Backup سازگار Browse و Restore شوند. برای Active Directory می‌توان Objectها و Attributeها را با نسخه Production مقایسه و در سناریوهای مناسب Restore کرد. برای SQL می‌توان Database یا Point-in-Time را بر اساس Backup و Logهای موجود بازیابی کرد. این قابلیت‌ها زمانی قابل اتکاتر هستند که Application-Aware Processing در Backup درست انجام شده باشد. قبل از Restore باید دقیق بدانی چه Objectی، از چه زمان، به چه مقصدی برمی‌گردد. Restore مستقیم به Production تغییر واقعی ایجاد می‌کند و باید Approval داشته باشد؛ Export یا Restore به Alternative Location برای بررسی اولیه امن‌تر است. در SQL، وابستگی Login، Job، Linked Server و Application Connection String را نیز بررسی کن چون Database تنها جزء سرویس نیست. در AD، Replication و Tombstone/Forest Recovery مفاهیم جدا هستند و برای Disaster بزرگ باید مستند Microsoft دنبال شود. در این سناریو باید همیشه کوچک‌ترین سطح Restore لازم را انتخاب کنی: اگر بازیابی یک فایل یا Item کافی است، کل Server را به گذشته برنگردان

Windows Server Backup ابزار داخلی Microsoft برای Backup در Windows Server است و در سناریوهایی مانند System State و Bare Metal Recovery اهمیت دارد. System State روی Domain Controller شامل اجزای حیاتی برای بازیابی Directory است و Microsoft در راهنمای Forest Recovery روش گرفتن System State با Windows Server Backup را توضیح می‌دهد. این موضوع جای Veeam Image-Level Backup را نمی‌گیرد؛ بلکه نوع دیگری از حفاظت است که در طراحی Recovery بعضی سرویس‌ها کاربرد دارد. Windows Server Backup را می‌توان از Server Manager > Tools باز کرد و Backup Once یا Schedule ساخت. هنگام انتخاب Destination باید توجه کنی Backup روی همان Disk فیزیکی Source حفاظت مستقل ایجاد نمی‌کند. برای Bare Metal Recovery نیز Critical Volumeها و Windows Recovery Environment وارد سناریو می‌شوند و معمولاً هدف بازسازی کامل سیستم روی Disk جدید یا سخت‌افزار/VM مناسب است. در Domain Controller، Forest Recovery یک عملیات حساس است و Restore عادی VM نباید بدون توجه به Replication و Microsoft Procedure انجام شود. پشتیبان شبکه باید حداقل بداند System State چیست، کجا Backup شده و در Disaster چه زمانی سراغ آن می‌رود. همچنین وضعیت آخرین Windows Server Backup باید Monitor شود، چون وجود Folder قدیمی WindowsImageBackup به معنی Backup جاری نیست

در بسیاری از شرکت‌ها مهم‌ترین داده واقعی روی File Share، NAS یا Shared Folder قرار دارد. ممکن است File Server خودش VM باشد و Image-Level Backup از VM گرفته شود، اما برای Shareهای بزرگ یا NAS مستقل باید Backup Unstructured Data را جدا طراحی کنی. مهم‌ترین سؤال Scope است: کدام Shareها حیاتی‌اند، چه File Typeهایی رشد سریع دارند، Permission و ACL باید Restore شوند یا فقط محتوا، و RPO برای فایل‌های کاربر چیست. اگر Share چند ترابایت است، Backup کامل روزانه عملی نیست و Change Tracking یا Incremental نیاز داریم. همچنین فایل‌های باز، VSS و Applicationهای دیتابیسی که اشتباهاً روی Share نگهداری می‌شوند نیاز به توجه جدا دارند. Retention فایل‌ها ممکن است بیشتر از VM باشد چون کاربر درخواست نسخه یک ماه قبل می‌کند. Restore Test باید شامل Permission و مسیر UNC نیز باشد، نه فقط بازشدن فایل. برای NAS، Credential اختصاصی Read/Backup و مقصد جدا تعریف کن و نسخه Copy دوم را فراموش نکن. Backup از Share روی همان NAS به Folder دیگر در برابر خرابی کامل NAS حفاظت کافی نیست. همچنین Quota، Recycle Bin یا Previous Versions ابزارهای کمک‌کننده‌اند اما جای Backup مستقل را نمی‌گیرند

CRM، ERP و سیستم‌های حسابداری معمولاً روی Database تکیه دارند و Backup آن‌ها باید با Vendor Application و Database Engine هماهنگ شود. اولین قدم تشخیص معماری است: Database کجاست، Application Server کجاست، فایل Attachment یا Document خارج Database کجاست و License/Config در چه محلی ذخیره می‌شود. برای SQL Server باید Full Database Backup، Differential و Transaction Log Backup را بر اساس Recovery Model و RPO بشناسی. اگر Veeam Application-Aware Processing نیز Log Processing انجام می‌دهد، با DBA یا Vendor مشخص کن چه ابزاری مسئول Log Chain است تا دو روش متعارض نشوند. بعضی CRMها برای Restore فقط Database کافی نیستند و فایل Config، Encryption Key یا Attachment Folder هم لازم است. بنابراین باید «Application Recovery Set» تعریف کنی؛ مجموعه‌ای از تمام اجزایی که برای بالا آمدن سرویس نیاز است. Restore Test در محیط Isolated انجام شود و User Login، Report، Attachment و Integrationها بررسی شوند. نسخه Database که Restore می‌کنی باید با Application Version سازگار باشد. قبل از Upgrade CRM نیز Backup جدا و Restore Plan داشته باش. معیار موفقیت فقط داشتن فایل Backup دیتابیس نیست؛ باید بتوانی سرویس CRM را با اجزای وابسته‌اش در زمان مشخص و قابل اندازه‌گیری برگردانی

وب‌سایت و ایمیل ممکن است روی Hosting Provider، cPanel/DirectAdmin، Cloud VM یا سرویس SaaS باشند و اگر در Inventory داخلی دیده نشوند به‌سادگی از Backup Plan جا می‌مانند. برای وب‌سایت باید حداقل فایل‌های Web Root، Database، Configuration، SSL/Certificate Information و DNS Configuration مستند شوند. Backup داخلی Hosting Provider مفید است اما به‌تنهایی کافی نیست اگر همان Account یا Provider دچار مشکل شود؛ نسخه Export یا Backup خارج از Provider برای سرویس حیاتی ارزش دارد. برای ایمیل نیز باید مشخص شود سرویس IMAP/POP، Microsoft 365، Google Workspace یا Mail Server Hosting است. روش Backup هرکدام متفاوت است و Export دستی Mailbox به‌عنوان استراتژی سازمانی مقیاس‌پذیر نیست. RPO وب‌سایت کم‌تغییر ممکن است روزانه باشد ولی فروشگاه آنلاین یا Database Formها به فرکانس بیشتری نیاز دارند. Restore Test باید روی Subdomain یا محیط Staging انجام شود تا مطمئن شوی فایل و Database با هم سازگارند. DNS و TTL نیز در Disaster Website اهمیت دارند. Credential Hosting، API Key و MFA Recovery Code باید در Password Vault امن باشند و Backup خود Password Vault نیز در برنامه Business Continuity باشد

SureBackup در Veeam برای Recovery Verification طراحی شده است. در حالت Full Recoverability Testing، VMها مستقیماً از Backup داخل Virtual Lab ایزوله بالا می‌آیند و تست‌هایی مثل Heartbeat، Ping و Application Test اجرا می‌شوند. این کار کمک می‌کند بدون اتصال VM آزمایشی به Production بررسی کنیم Backup واقعاً Boot و Application قابل استفاده است. Veeam برای این سناریو Application Group و Virtual Lab دارد تا Dependencyهایی مثل Domain Controller یا DNS در محیط جدا همراه VM تست بالا بیایند. SureBackup علاوه بر Health Check است؛ Health Check Integrity فایل را بررسی می‌کند، اما SureBackup Workload را اجرا می‌کند. حتی بدون SureBackup نیز باید Restore Drill دستی داشته باشی: File Restore ماهانه، VM Restore فصلی، Database Restore و Disaster Exercise دوره‌ای. نتیجه هر تست باید شامل Restore Point، زمان شروع، زمان آماده‌شدن سرویس، خطاها و RTO واقعی باشد. اگر تست شکست خورد، Backup را Failed Operationally تلقی کن حتی اگر Job شبانه سبز بوده است. «۰» در 3-2-1-1-0 همین دیدگاه را تقویت می‌کند: صفر خطای Recovery Verification. برای Workloadهای مهم برنامه تست را در تقویم عملیاتی قرار بده تا با مشغله روزمره حذف نشود

در Incident امنیتی هدف اول فقط Restore نیست؛ باید گسترش آلودگی را متوقف و سالم‌بودن Backup را ارزیابی کنی. اگر Backup Server و Repository با همان Domain Admin یا Credentialهای Production مدیریت شوند، فرض کن ممکن است آن‌ها هم compromise شده باشند تا خلافش ثابت شود. دسترسی Network به Repositoryهای حساس را طبق Incident Response Plan محدود کن و Backup Immutable را حفظ کن. Restore Point باید بر اساس زمان آلودگی انتخاب شود؛ آخرین Backup ممکن است خودش حاوی Malware یا Persistence باشد. Secure Restore، Malware Scan، EDR و بررسی Logها می‌توانند بخشی از فرایند باشند، اما تصمیم نهایی باید با تیم امنیت انجام شود. Restore مستقیم روی Production آلوده بدون پاک‌سازی Root Cause ممکن است فقط چرخه Incident را تکرار کند. بهتر است Recovery در Clean Room یا شبکه Isolated شروع شود، Identity System مانند AD با اولویت و Procedure مشخص بازسازی شود و سپس سرویس‌ها بر اساس Dependency بالا بیایند. Credential Reset، Patch، Network Segmentation و Validation پس از Restore لازم‌اند. Immutable Backup کمک می‌کند مهاجم نتواند Restore Point را حذف کند، اما اگر همان Backup قبل از آلودگی تست نشده باشد، هنوز ریسک Recoverability داریم. برای شرکت کوچک نیز یک Runbook یک‌صفحه‌ای بنویس که چه کسی تصمیم Restore می‌گیرد و Repository چگونه ایزوله می‌شود

رایج‌ترین خطاهای Backup معمولاً در چند دسته قرار می‌گیرند: Source/VMware، Proxy/Transport، Network، Repository/Storage و Guest Processing. اگر Repository Full است، قبل از حذف دستی Backup File، Retention، Immutable Period، Active Fullهای اضافی، GFS و Failed Mergeها را بررسی کن. اگر Job با Snapshot Error شکست می‌خورد، vCenter Task، Datastore Free Space، Consolidation Needed و Snapshotهای قدیمی را ببین. اگر Network Mode کند است، Proxy Transport Mode، NIC Throughput و Packet Loss را بررسی کن. اگر Application-Aware Failure داریم، Guest Credential، DNS، Firewall، VSS Writers و Application Service را بررسی کن. اگر CBT Warning وجود دارد، علت و Procedure رسمی Reset CBT را دنبال کن و کورکورانه فایل CTK را دستکاری نکن. در همه موارد Session Log و Timestamp نقطه شروع هستند. تغییر چند چیز هم‌زمان عیب‌یابی را خراب می‌کند. یک فرضیه بساز، یک تست انجام بده و نتیجه را ثبت کن. قبل از Restart Service یا Reboot Server، ببین Job دیگری در حال Merge/Synthetic/Restore نیست. اگر Corruption یا Storage Error مشاهده می‌شود، ابتدا سلامت Hardware و Filesystem Repository را ارزیابی کن. هدف حل ریشه‌ای است نه سبزکردن موقت Job

فرض کن یک شرکت ۳۰ کاربر دارد: دو Domain Controller، یک File Server با ۲ ترابایت داده، یک SQL Server برای CRM، چند VM کاربردی، وب‌سایت روی Hosting و ایمیل Cloud. ابتدا Inventory و Owner هر سرویس را ثبت کن. برای AD و DNS RPO و RTO کوتاه، برای CRM RPO متناسب با Transaction، برای File Server Retention روزانه و برای وب‌سایت Backup خارج Hosting تعریف کن. Primary Backup VMها روی Repository محلی سریع برای Restore روزمره ذخیره شود و Backup Copy به مقصد Offsite یا Immutable داشته باش. Hardened Repository یا Object Storage Immutable لایه مقاومت در برابر باج‌افزار باشد. Application-Aware Processing برای DC و SQL فعال و با VSS/Log Processing تست شود. File Share و Hosting نیز خارج Scope VM فراموش نشوند. Configuration Backup خود Veeam Encrypt و خارج System Disk نگه داشته شود. Notification روزانه Failed/Warning به تیم برسد. هر ماه File Restore، هر فصل VM/Database Restore و دوره‌ای SureBackup یا Disaster Exercise اجرا شود. در Documentation برای هر سرویس RPO، RTO، Job، Repository، Retention، Owner، مسیر Restore و آخرین Test Date ثبت شود. این سناریو زمانی کامل است که یک نفر دیگر از تیم بتواند بدون پرسیدن از سازنده اصلی، مراحل Restore را از روی سند انجام دهد