۵ سناریوی بکاپگیری سازمانی با Veeam ؛از حفاظت سرورها تا بازیابی پس از بحران
آبان 12, 1405 1405-08-12 12:29۵ سناریوی بکاپگیری سازمانی با Veeam ؛از حفاظت سرورها تا بازیابی پس از بحران
Veeam Backup & Replicationچه نقشی در زیرساخت سازمان دارد؟
بکاپگیری سازمانی با Veeam راهکاری برای حفاظت از دادهها و بازیابی اطلاعات در محیطهای مجازی، فیزیکی و برخی زیرساختهای ابری است. این نرمافزار با استفاده از مفهومی به نام Backup Job ، عملیات پشتیبانگیری را مدیریت میکند. در هر Job مشخص میشود چه ماشینها یا اطلاعاتی باید محافظت شوند، نسخه پشتیبان در کجا ذخیره شود و عملیات با چه زمانبندی و سیاست نگهداری انجام بگیرد.
در محیطهای مجازی مانند VMware vSphere ، Veeam میتواند از ماشینهای مجازی در سطح Image نسخه پشتیبان تهیه کند. در این روش، اطلاعات ماشین مجازی شامل سیستمعامل، دادههای برنامهها و تنظیمات مربوط به آن در قالب نسخه پشتیبان ذخیره میشوند. پس از اجرای نسخه اولیه، در صورت استفاده از روشهای افزایشی، تغییرات بعدی نیز طبق تنظیمات Job ثبت خواهند شد.
اما کاربرد Veeam به تهیه نسخه پشتیبان از ماشینهای مجازی محدود نیست. سازمان میتواند از Agent برای حفاظت از سرورهای فیزیکی استفاده کند، نسخههای پشتیبان را به محل دیگری انتقال دهد، از مخازن تغییرناپذیر استفاده کند و بازیابی اطلاعات را پیش از وقوع بحران آزمایش کند.
برای طراحی یک راهکار بکاپگیری سازمانی با Veeam، باید ابتدا سه مفهوم را بشناسیم:
- RPO یا (Recovery Point Objective) : حداکثر میزان قابلقبول از دسترفتن اطلاعات بر اساس زمان آخرین نسخه قابل بازیابی.
- RTO یا (Recovery Time Objective) : مدتزمان هدف برای بازگرداندن سرویس به وضعیت عملیاتی.
- Retention Policy: مدتزمان و تعداد نقاط بازیابی که باید نگهداری شوند.
برای مثال، اگر RPO یک سامانه چهار ساعت باشد، سازمان باید برنامهای داشته باشد که در صورت وقوع حادثه، میزان اطلاعات ازدسترفته از محدوده موردقبول بیشتر نشود. اگر RTO آن دو ساعت تعیین شده باشد، طراحی بازیابی نیز باید با این هدف هماهنگ باشد.
این سه مفهوم پایه انتخاب سناریوی بکاپگیری هستند.
سناریوی اول: بکاپگیری متمرکز از ماشینهای مجازی VMware
یکی از رایجترین کاربردهای Veeam در سازمانهایی است که زیرساخت خود را بر پایه VMware vSphere و ESXi پیادهسازی کردهاند.
در چنین محیطی، ممکن است چندین میزبان ESXi وجود داشته باشد که روی آنها ماشینهای مجازی مربوط به سرویسهای مختلف اجرا میشوند؛ از جمله Domain Controller ، فایلسرور، پایگاه داده، سرور نرمافزارهای سازمانی و سرویسهای مانیتورینگ.
اگر برای هر ماشین مجازی روش پشتیبانگیری جداگانهای در نظر گرفته شود، مدیریت نسخهها و زمانبندیها بهمرور دشوار خواهد شد. Veeam این امکان را فراهم میکند که ماشینهای مجازی در قالب Backup Job های مشخص گروهبندی شوند.
ساختار این سناریو چگونه است؟
در یک طراحی معمول، اجزای اصلی شامل موارد زیر هستند:
- زیرساخت مجازی VMware شامل میزبانهای ESXi و ماشینهای مجازی
- سرور مدیریت Veeam Backup & Replication
- Backup Repository برای ذخیره نسخههای پشتیبان
- زمانبندی مشخص برای اجرای Jobها و نگهداری Restore Pointها
در این معماری، Veeam با استفاده از قابلیتهای VMware از ماشین مجازی Snapshot تهیه میکند و اطلاعات موردنیاز را در سطح بلوک دریافت و در مخزن پشتیبان ذخیره میکند. در بسیاری از سناریوهای معمول، نیازی به نصب Agent داخل تکتک ماشینهای مجازی نیست.
برای نمونه، یک سازمان میتواند ماشینهای مجازی حساس را در یک Job و سرورهای کماهمیتتر را در Job دیگری قرار دهد. به این ترتیب، زمانبندی و سیاست نگهداری نسخهها بر اساس اهمیت سرویسها تعیین میشود.
چه نکاتی در این سناریو اهمیت دارند؟
یکی از موضوعات مهم، سازگاری اطلاعات برنامههاست. صرفاً تهیه نسخه Image از ماشین مجازی همیشه برای بازیابی صحیح پایگاه داده یا سرویسهای تراکنشی کافی نیست. قابلیت Application-Aware Processing در Veeam میتواند در محیطهای پشتیبانیشده، هماهنگی لازم با برنامههایی مانند Microsoft SQL Server و Active Directory را برای تهیه نسخه سازگارتر فراهم کند.
همچنین باید فضای Repository ، ظرفیت شبکه و مدت نگهداری نسخهها از ابتدا محاسبه شوند. اجرای چندین Job بزرگ در یک بازه زمانی محدود میتواند فشار زیادی به زیرساخت وارد کند.
مناسب برای سازمانهایی که چندین ماشین مجازی دارند و به دنبال مدیریت متمرکز نسخههای پشتیبان و بازیابی ماشینها هستند.
سناریوی دوم: بکاپگیری از سرورهای فیزیکی و سرویسهای حیاتی

با وجود گسترش مجازیسازی، بسیاری از سازمانها همچنان تعدادی سرور فیزیکی دارند. برخی از این سرورها به دلیل نیازهای سختافزاری، ساختار نرمافزارهای قدیمی یا ملاحظات عملکردی به محیط مجازی منتقل نشدهاند.
در چنین شرایطی، راهکار بکاپگیری باید بتواند علاوه بر ماشینهای مجازی، از سرورهای فیزیکی نیز محافظت کند.
Veeam Agent for Microsoft Windows و Veeam Agent for Linux برای این دسته از سناریوها استفاده میشوند. این Agent ها امکان تهیه نسخه پشتیبان از سیستمعامل، دیسکها، Volumeها و اطلاعات انتخابشده را فراهم میکنند؛ البته قابلیتهای دقیق به سیستمعامل، نسخه و نوع مجوز بستگی دارند.
یک مثال بکاپگیری سازمانی با Veeam
فرض کنید یک مجموعه مالی از یک سرور فیزیکی برای اجرای نرمافزار خاص سازمان استفاده میکند. این سرور شامل سیستمعامل، تنظیمات شبکه، سرویسهای موردنیاز و اطلاعات مهم برنامه است.
اگر فقط از پوشههای اطلاعاتی نسخه پشتیبان تهیه شود، هنگام خرابی کامل سرور ممکن است بازسازی سیستمعامل، نصب مجدد نرمافزارها و تنظیم سرویسها زمان زیادی ببرد.
در این سناریو، با استفاده از Agent میتوان از کل سیستم یا Volume های موردنیاز نسخه پشتیبان تهیه کرد. در صورت بروز مشکل، امکان بازیابی در سطح فایل یا Volume و در سناریوهای پشتیبانیشده، بازیابی کامل سیستم وجود دارد.
نکته تخصصی: بکاپ فایل با بکاپ سیستم یکسان نیست
تهیه نسخه پشتیبان از فایلها برای زمانی مناسب است که هدف، بازیابی اطلاعات مشخصی باشد. اما اگر سرور بهطور کامل از دسترس خارج شود، نسخهای که شامل اطلاعات سیستم و اجزای موردنیاز برای بازیابی کامل باشد، میتواند فرایند بازگرداندن سرویس را سادهتر کند.
در طراحی این سناریو باید مشخص شود کدام سرورها به بازیابی کامل نیاز دارند و کدامیک را میتوان با نصب مجدد سیستمعامل و بازگرداندن دادهها احیا کرد.
مناسب برای سازمانهایی که ترکیبی از سرورهای فیزیکی و مجازی دارند یا سرویسهای مهمی را روی سختافزار مستقل اجرا میکنند.
سناریوی سوم: انتقال نسخههای پشتیبان به سایت دوم یا فضای خارج از سازمان

یکی از اشتباهات رایج در طراحی بکاپ سازمانی، نگهداری تمام نسخههای پشتیبان در همان محل استقرار سرورهای اصلی است.
فرض کنید یک سازمان از ماشینهای مجازی خود نسخه پشتیبان تهیه میکند و آنها را روی یک Storage در همان اتاق سرور نگه میدارد. اگر این محل با مشکلی مانند خرابی گسترده تجهیزات، حادثه فیزیکی یا اختلال جدی زیرساخت مواجه شود، ممکن است هم اطلاعات اصلی و هم نسخههای پشتیبان در معرض خطر قرار بگیرند.
برای جلوگیری از این وضعیت، باید بخشی از نسخههای پشتیبان در موقعیتی مستقل از سایت اصلی نگهداری شوند.
- راهکار Backup Copy در Veeam
- قابلیت Backup Copy امکان ایجاد نسخه دیگری از Backup ها در یک Repository ثانویه را فراهم میکند. این مخزن میتواند در همان سایت یا در موقعیتی دیگر قرار داشته باشد.
برای مثال، ساختار یک سازمان میتواند به شکل زیر باشد:
- نسخه اصلی اطلاعات روی ماشینهای مجازی Production قرار دارد.
- نسخه پشتیبان اول روی Repository محلی ذخیره میشود.
- نسخه پشتیبان دوم از طریق Backup Copy به سایت دوم انتقال پیدا میکند.
در این طراحی، اگر سایت اصلی از دسترس خارج شود، نسخه خارج از سایت همچنان میتواند برای بازیابی اطلاعات مورد استفاده قرار بگیرد.
Veeam امکان تعریف سیاستهای نگهداری برای Backup Copy را نیز فراهم میکند. برای نگهداری بلندمدت، میتوان از سیاستهایی مانند GFS استفاده کرد که نسخههای هفتگی، ماهانه یا سالانه را مطابق نیاز سازمان حفظ میکنند.
چرا سایت دوم باید مستقل باشد؟
صرفاً انتقال نسخه پشتیبان به یک سرور دیگر در همان شبکه، الزاماً حفاظت کافی ایجاد نمیکند. اگر دسترسی مدیریتی، شبکه و فضای ذخیرهسازی هر دو مخزن به یک شکل کنترل شوند، یک حادثه امنیتی میتواند هر دو را تحت تأثیر قرار دهد.
بنابراین، در طراحی حرفهای باید مواردی مانند جداسازی دسترسیها، محدودسازی ارتباطات مدیریتی، رمزنگاری اطلاعات و کنترل دسترسی به Repository مقصد در نظر گرفته شوند.
مناسب برای سازمانهای چندشعبهای، شرکتهایی با سرویسهای حیاتی و مجموعههایی که از دسترفتن کامل اطلاعات در سایت اصلی برای آنها قابلقبول نیست.
سناریوی چهارم: محافظت در برابر باجافزار با Immutable Backup

باجافزارها فقط اطلاعات کاربران و سرورهای عملیاتی را هدف قرار نمیدهند. در بسیاری از حملات، مهاجمان تلاش میکنند نسخههای پشتیبان را نیز حذف یا رمزگذاری کنند تا سازمان امکان بازیابی اطلاعات را از دست بدهد.
به همین دلیل، داشتن چند نسخه بکاپ که همگی از طریق یک شبکه و با دسترسیهای مشابه قابل تغییر باشند، امنیت کافی ایجاد نمیکند.
یکی از قابلیتهای مهم در معماری جدید حفاظت از داده، Immutable Backup است.
Immutable به معنای تغییرناپذیر است. نسخه پشتیبان تغییرناپذیر در بازه زمانی تعیینشده، مطابق سازوکار مخزن و سیاست نگهداری، در برابر حذف یا تغییر محافظت میشود.
پیادهسازی سناریو بکاپگیری سازمانی با Veeam
Veeam از مخازن مختلفی برای نگهداری نسخههای پشتیبان پشتیبانی میکند. بسته به نوع Repository، میتوان از قابلیت تغییرناپذیری استفاده کرد.
برای مثال:
- استفاده از Linux Hardened Repository با تنظیمات و شرایط پشتیبانیشده
- استفاده از Object Storage سازگار با قابلیت Object Lock
- نگهداری نسخههای پشتیبان در فضای ذخیرهسازی با قابلیت Immutability
در یک طراحی مناسب، نسخه پشتیبان اصلی روی Repository محلی قرار میگیرد و نسخه دیگری به مخزن تغییرناپذیر منتقل میشود. در نتیجه، حتی اگر یک حساب مدیریتی در زیرساخت اصلی به خطر بیفتد، مهاجم نباید بتواند بهآسانی تمام نسخههای قابل بازیابی را حذف کند.
البته Immutable بودن بهتنهایی امنیت کامل را تضمین نمیکند. دسترسی مدیریتی، حسابهای کاربری، تنظیمات شبکه، نگهداری کلیدهای رمزنگاری و جداسازی زیرساخت بکاپ باید بهدرستی مدیریت شوند.
یکی از الگوهای شناختهشده در طراحی زیرساخت بکاپ، قانون 3-2-1-1-0 است:
| عدد | مفهوم |
| 3 | حداقل سه نسخه از داده، شامل نسخه اصلی |
| 2 | نگهداری نسخهها روی دو نوع رسانه متفاوت |
| 1 | حداقل یک نسخه خارج از سایت |
| 1 | حداقل یک نسخه آفلاین، ایزوله یا تغییرناپذیر |
| 0 | صفر خطا در بررسی و اعتبارسنجی بازیابی |
این الگو کمک میکند طراحی بکاپ تنها به تعداد نسخهها محدود نشود و امنیت و قابلیت بازیابی نیز در آن لحاظ شوند.
مناسب برای: سازمانهایی که با اطلاعات حساس کار میکنند، سرویسهای حیاتی دارند یا میخواهند در برابر حذف عمدی نسخههای پشتیبان و تهدیدات باجافزاری آمادگی بیشتری داشته باشند.
سناریوی پنجم: بازیابی پس از بحران با Replication و Recovery Verification

در بعضی سازمانها، از دسترس خارجشدن یک سرویس حتی برای چند ساعت نیز خسارت زیادی ایجاد میکند. برای مثال، اگر یک سامانه مالی یا سرویس عملیاتی مهم متوقف شود، بازگرداندن آن از روی نسخه پشتیبان ممکن است زمانبر باشد.
در چنین شرایطی، تنها تهیه Backup کافی نیست و باید برای راهاندازی سریع سرویس در زیرساخت جایگزین نیز برنامه داشت.
در این سناریو دو مفهوم اهمیت دارند: Replication و Recovery Verification.
Replication؛ آمادهبودن نسخه جایگزین ماشین مجازی
در قابلیت Replication، یک نسخه از ماشین مجازی روی میزبان مقصد ایجاد میشود و تغییرات آن در بازههای تعیینشده با ماشین اصلی هماهنگ میشود.
برای مثال، سازمان میتواند ماشینهای مجازی مهم را از سایت اصلی به زیرساختی در سایت دوم Replicate کند. در صورت بروز بحران، نسخه Replica در مقصد آماده راهاندازی خواهد بود.
تفاوت مهم Replication با Backup این است که Replication برای کاهش زمان بازیابی طراحی شده، اما بهتنهایی جایگزین نسخه پشتیبان مستقل نیست. اگر اطلاعات خراب یا رمزگذاریشده به ماشین Replica منتقل شوند، ممکن است نسخه جایگزین نیز تحت تأثیر قرار بگیرد.
به همین دلیل، Replication و Backup باید مکمل یکدیگر باشند، نه جایگزین هم.
Recovery Verification؛ اطمینان از قابل بازیابی بودن نسخهها
یکی از قابلیتهای مهم بکاپگیری سازمانی با Veeamدر این حوزه SureBackup است. این قابلیت در محیطهای پشتیبانیشده میتواند با راهاندازی ماشینهای مجازی از روی نسخه پشتیبان در محیط ایزوله، امکان بررسی وضعیت بازیابی را فراهم کند.
در این فرایند میتوان آزمود که آیا ماشین مجازی بهدرستی روشن میشود و بررسیهای موردنظر درباره سرویسها و ارتباطات آن موفق هستند یا خیر.
برای مثال، سازمانی که از Domain Controller نسخه پشتیبان تهیه میکند، باید مطمئن شود که نسخه ذخیرهشده صرفاً یک فایل قابل مشاهده نیست و امکان بازیابی سرویس مربوطه نیز وجود دارد.
در طراحی بازیابی بحران، باید مشخص باشد کدام ماشینها در اولویت راهاندازی قرار دارند، وابستگی سرویسها به یکدیگر چیست و چه کسی مسئول تأیید بازگشت هر سرویس به وضعیت عملیاتی است.
مناسب برای: سازمانهایی که RTO پایینی دارند، سرویسهای حیاتی ارائه میدهند یا باید برای خرابی سایت اصلی و توقف گسترده زیرساخت آماده باشند.
چگونه این پنج سناریو را در یک معماری بکاپگیری سازمانی با Veeam ترکیب کنیم؟
در یک محیط واقعی، معمولاً استفاده از تنها یکی از این سناریوها کافی نیست. یک سازمان ممکن است همزمان به بکاپ ماشینهای مجازی، حفاظت از سرورهای فیزیکی، انتقال نسخهها به سایت دوم و نگهداری نسخه تغییرناپذیر نیاز داشته باشد.
برای مثال، معماری یک شرکت متوسط میتواند به شکل زیر طراحی شود:
| بخش زیرساخت | راهکار پیشنهادی |
| ماشینهای مجازی VMware | Backup Job |
| سرورهای فیزیکی | Veeam Agent |
| نسخه ثانویه خارج از سایت | Backup Copy |
| حفاظت در برابر حذف و تغییر | Immutable Repository |
| سرویسهای با RTO پایین | Replication |
| بررسی قابلیت بازیابی | SureBackup و تست بازیابی |
در این معماری، باید برای هر سرویس RPO و RTO مشخصی تعریف شود. سپس بر اساس اهمیت سرویس، نوع داده و محدودیت منابع، زمانبندی بکاپ و سیاست نگهداری تعیین شود.
برای نمونه، پایگاه داده سازمانی ممکن است به حفاظت و بازیابی دقیقتری نسبت به یک فایلسرور آرشیوی نیاز داشته باشد. همچنین، یک سرویس حیاتی ممکن است به Replica در سایت دوم نیاز داشته باشد، درحالیکه برای یک سرویس کماهمیتتر، بازیابی از Backup محلی کافی باشد.
نکته مهم این است که هزینه ذخیرهسازی، پهنای باند، ظرفیت پردازشی و زمان بازیابی باید همزمان در طراحی در نظر گرفته شوند. اجرای تمام قابلیتها بدون محاسبه ظرفیت و نیاز واقعی سازمان، لزوماً نتیجه بهتری ایجاد نمیکند.
اشتباهات رایج در بکاپگیری سازمانی با Veeam
حتی با استفاده از یک ابزار قدرتمند، طراحی نادرست میتواند باعث شود در زمان بحران نسخه پشتیبان قابل استفاده نباشد. چند اشتباه رایج عبارتاند از:
نگهداری تمام نسخهها در یک محل: این کار ریسک از دسترفتن همزمان اطلاعات اصلی و نسخههای پشتیبان را افزایش میدهد.
نادیدهگرفتن تست بازیابی: موفقیت Backup Job به معنی تضمین بازیابی موفق نیست. نسخههای پشتیبان باید بهصورت دورهای آزمایش شوند.
استفاده از Replication بهجای Backup: Replica ممکن است تغییرات ناخواسته یا اطلاعات خراب را نیز دریافت کند؛ بنابراین به نسخههای پشتیبان مستقل نیاز است.
تعریف زمانبندی یکسان برای همه سرویسها: اهمیت اطلاعات، حجم تغییرات و نیازهای بازیابی در سرورهای مختلف یکسان نیست.
بیتوجهی به امنیت زیرساخت بکاپ: دسترسیهای مدیریتی گسترده، نبود MFA ، جدانکردن حسابهای کاربری و نگهداری نامناسب رمزهای عبور میتوانند Repository را در معرض خطر قرار دهند.
جمعبندی
بکاپگیری</strong> سازمانی با Veeam زمانی ارزش واقعی پیدا میکند که بهعنوان بخشی از معماری حفاظت از داده طراحی شود، نه صرفاً یک وظیفه زمانبندیشده برای کپیکردن اطلاعات.
پنج سناریوی بررسیشده، بخشهای مختلف این معماری را پوشش میدهند: حفاظت از ماشینهای مجازی، پشتیبانگیری از سرورهای فیزیکی، انتقال نسخهها به سایت دوم، نگهداری نسخههای تغییرناپذیر و آمادهسازی برای بازیابی پس از بحران.
برای متخصص IT، تسلط بر Veeam فقط به یادگیری ساخت Backup Job محدود نمیشود. شناخت Repository، Backup Copy، Replication، سیاستهای Retention، امنیت مخازن و روشهای اعتبارسنجی بازیابی، مجموعه مهارتهایی هستند که در طراحی و مدیریت یک زیرساخت سازمانی اهمیت دارند.
در نهایت، معیار موفقیت یک سیستم بکاپ این نیست که چندین ترابایت اطلاعات ذخیره کرده باشد؛ معیار اصلی این است که سازمان در زمان وقوع حادثه بتواند اطلاعات سالم را در زمان قابلقبول بازیابی کند و سرویسهای خود را دوباره به چرخه فعالیت بازگرداند.
