Backup

Disaster Recovery

به حالتی که حادثه یا اتفاقی ناگوار (به صورت طبیعی و یا ناشی از اشتباهات انسانی) برای سرور و یا اطلاعات موجود برروی آن افتاده و این امر باعث شود تا دسترس پذیری، محرمانگی و یا یکپارچگی اطلاعات از بین برود، Disaster می گویند. در این شرایط نیاز به طرحی جامع و متناسب که از قبل برنامه ریزی شده باشد خواهیم داشت تا امکان بازگرداندن عملکرد را به حالت قبل از وقوع فاجعه در کمترین زمان ممکن داشته باشیم.

یک طرح و برنامه Disaster Recovery مناسب، یک رویکرد ساختار یافته برای مواجهه با اتفاقات و حوادث غیر برنامه ریزی شده است که می تواند زیرساخت IT شرکت و سازمان های مربوطه را تهدید نماید. این طرح استراتژی های بازیابی از فاجعه ها را به صورت گام به گام برای بازیابی سیستم ها و شبکه های خراب شده را جهت به حداقل رساندن تاثیرات منفی بر فعالیت های شرکت و یا سازمان ها فراهم می آورد.

انواع حادثه

فجایع طبیعی، شکست‌های فنی، اشتباهات انسانی و فعالیت‌های مخرب منجر به افزایش اختلال در عملیات کسب و کار می‌گردد. نهادها باید از این اتفاقات آگاهی داشته و به منظور رویارویی با آن‌ها، برنامه‌ریزی‌ها و آماده‌سازی‌های لازم را انجام دهند. حوادث به‌طور گسترده به دو مقوله زیر طبقه‌بندی می‌شوند:

حوادث طبیعی: حوادث طبیعی، وقایع ناگهانی ناشی از عوامل محیطی هستند که منجر به خسارت‌های جانی و مالی می‌گردند.

حوادث انسانی: حوادث انسانی ناشی از خطای انسانی، عدم دانش و آگاهی، غفلت یا حتی نیت‌های مخرب می‌باشد. این حوادث غیرقابل پیش‌بینی بوده و امکان توسعهٔ آن در منطقه‌ای وسیع وجود دارد. این حوادث گاهی اوقات غیرقابل پیشگیری نیز می‌باشند. خرابی سیستم، قطع جریان مخابراتی یا برق، تروریسم و تروریسم سایبری در این رده از حوادث قرار دارند.

تعریف بازیابی از حادثه

بازیابی از حادثه شامل فرایندها، سیاست‌ها و رویه‌های لازم برای فراهم‌سازی قابلیت بازیابی عملیات‌ها و تداوم عملکردهای حیاتی سازمان پس از وقوع حادثه است. مسائل و موضوعاتی نظیر آسیب‌ها و خسارت‌های فیزیکی، تلاش‌هایی در جهت هک و نفوذ، وجود نرم‌افزارهای مخرب کامپیوتری و بروز شرایط اضطراری در مقوله ی امنیت اطلاعات، دولت‌ها و شرکت‌ها را به تمرکز بر موضوع بازیابی از حادثه ترغیب می‌کند. راهکارهای مربوط به این مقوله باید نوع سازمان و عناصر مورد نیاز برای حفظ وضعیت اجرایی سازمان را در نظر داشته باشد. بازیابی از حادثه، به دلایل زیر برای هر سازمانی حائز اهمیت است:

بازگشت سریع سازمان به شرایط عملیاتی عادی خود

محدودسازی تأثیرات منفی حادثه در عملکرد کسب و کار

کمینه‌سازی احتمال وقوع آتی انواع خاصی از حادثه

 

چرخه عملیاتی بازیابی از حادثه

حوادث علل و ریشه‌های مختلفی دارند؛ از حوادث طبیعی گرفته تا حوادثی که عمدی و خطای انسانی محسوب شده و منجر به گسستگی در کسب و کار می‌گردد. تلاش‌های بازیابی از حادثه به محض بروز نشانه یا گزارشی از یک حادثه آغاز می‌گردد. تیم‌های بازیابی از حادثه، نخست به بررسی ماهیت حادثه پرداخته و سپس طرح‌های بازیابی از حادثه را برای غلبه بر حوادث و بازگرداندن عملیات به وضعیت عادی خود به اجرا درمی‌آورند.

مراحل بازیابی از حادثه

مرحله ی فعال‌سازی

رسیدگی و واکنش فوری و فعال به حوادث می‌تواند تأثیرات مخرب بر سازمان را تا حد زیادی کاهش دهد. توانایی تیم‌های بازیابی از حادثه به تشخیص به موقع پیش سازهای حوادث می‌توان در جلوگیری از حوادث به سازمان‌ها کمک کند. در شرایطی که تشخیص حوادث از پیش امکان‌پذیر نیست، اجرای سریع طرح‌ها و رویه‌های بازیابی از حادثه نقش مهمی در به حداقل رساندن تأثیرات حوادث ایفا می‌کند. مرحلهٔ فعال سازی، نخستین مرحله پس از تشخیص علایم حادثه است. تیم‌های بازیابی از حادثه پیش از فعال‌سازی فرایند بازیابی از حادثه، نیازمند تأیید وقوع حادثه هستند. مرحلهٔ فعال‌سازی خود شامل مراحل زیر است:

اطلاع‌رسانی به ذینفعان و اشخاص تحت تأثیر حادثه که به‌طور فعال در فرایند بازیابی از حادثه در گیر هستند

بررسی آسیب در راستای تعیین سطح ضرورت پاسخ

تصمیم‌گیری درخصوص فعال‌سازی فرایند بازیابی از حادثه

مرحله ی اطلاع‌رسانی

اطلاع‌رسانی، تمامی اشخاص تحت تأثیر را از بروز حادثه در سازمان آگاه می‌سازد. به این ترتیب، سازمان در وضعیت مربوط به اجرای عملیات حادثه قرار گرفته و مکانیزم‌های بازیابی از حادثه ی اجرا شده در سازمان را فعال می‌سازد. در نهایت، دستورالعمل رسمی جهت تغییر به وضعیت بازیابی از حادثه ابلاغ می‌شود. اطلاع‌رسانی‌های حادثه را می‌توان با استفاده از سیستم‌های مخابراتی مختلف مانند پست الکترونیک، فکس و تماس تلفنی اعلام نمود. سیاست اطلاع‌رسانی سازمان‌ها باید به گونه‌ای باشد که به وضوح نوع رسانه‌های ارتباطی مورد استفاده در سناریوهای مختلف و جزییات اطلاعات کارکنان به منظور تماس و اطلاع‌رسانی در شرایط مختلف را تشریح کند. اطلاعات هشدار شامل موارد زیر است:

ماهیت حادثه و آسیبی که نهایتاً ممکن است به آن بینجامد

تلفات جانی، صدمات و آسیب به زیرساخت‌های حیاتی

جزییات واکنش اولیه

برآورد زمان بازیابی

تمهیدات جایگزین برای به حداقل رساندن تأثیرات جانی و مالی

ارایه ی اطلاعات درخصوص جلسات توجیهی، نشست‌ها و مذاکرات برای ابلاغ دستورالعمل‌های واکنش‌های بعدی

اعلام دستورالعمل‌هایی برای جابه جایی‌های کوتاه مدت یا دائم

دستورالعمل‌هایی برای کسب اطلاعات بیشتر و درصورت لزوم مساعدت از افرادی که با آن‌ها تماس گرفته خواهد شد.

مرحله ی ارزیابی خسارت

ارزیابی خسارت به منظور انجام واکنش مناسب در زمینهٔ بازیابی از حادثه حائز اهمیت است. این امر جهت تعیین سطح فوریت و اجرای راه حل‌های مناسب بازیابی از حادثه نیز از اهمیت بالایی برخوردار است. به عنوان مثال، اگر نتایج ارزیابی خسارت برای یک مورد قطعی برق نشان دهد که منابع برق، پیش از به پایان رسیدن توان باتری سیستم‌ها مجدداً برقرار می‌شوند، مسلماً از اضطراب تیم بازیابی از حادثه کاسته خواهد شد. ارزیابی صحیح خسارت به اجتناب از پیغام‌های هشدار غیرضروری نیز کمک می‌کند. رویه‌های ارزیابی خسارت و نتایج پس از حادثه، با توجه به عوامل زیر متفاوت هستند:

ماهیت و علت حادثه

حساسیت عملیات و سیستم‌های تحت تأثیر حادثه

احتمال آسیب بیشتر به دلیل وقوع رویدادی فاجعه بار

ماهیت فناپذیر زیرساخت‌های حیاتی

زمان بازیابی مورد نیاز برای سیستم‌ها و عملیات‌های آسیب دیده

ده نکته مهم برای تدوین Disaster Recovery Plan

1- عدم تشخیص چیزی که می تواند به طور بالقوه ساختارها و داده هایی را به خطر اندازد که تجارت شما را اداره می کنند. علاوه بر خطرات ذکر شده، ویروس ها، Trojans ،worms و غیره ... شما باید هر نیرویی را که برای جغرافیای شما یکتاست مشخص کنید. آیا شما روی یک گسل زمین لرزه یا خط سیل زندگی می کنید؟ آیا منطقه شما تا بحال چند بار پی در پی با قطعی برق ناشی از باد و طوفان مواجه شده است؟ مطمئن شوید که تمام این احتمالات زمانی در نظر گرفته می شود که شما در حال ایجاد این طرح یا انتخاب مکانی برای یک امکان DR جدید هستید.

 

2- ایجاد طرحی که به افراد خیلی مجرب و متخصص بستگی دارد. این برای سازمان ها یک امر غیر عادی است که ایجاد طرح واکنش در حین خطر نسبت به سخت افزار و نرم افزار فقط به یک متخصص کامپیوتر نیاز دارد. شما باید تعداد بسیار زیادی از افراد را استخدام کنید که قادر هستند سریعاً در شرایط اضطراری پاسخگو باشند ولی از طرفی تمام این افراد در هنگام خطر نیز آسیب پذیر می شوند.

 

3- اعتماد به فرآیندهای دستی برای آگاهی پرسنل در حین ایجاد خطر و مشکل. اگر برق در ساختمان شما قطع شود و کسی آنرا گزارش ندهد، آیا پرسنل DR شما اطلاع پیدا می کنند؟ شما باید یک سیستم خودکار ایجاد کنید که پرسنل IT شما را از هر گونه خطر و رویداد بد مطلع کرده و مشکل را حل کنند. شما می توانید از یک سرویس گروه سوم استفاده کرده و سیستم خود را کنترل نمایید یا افرادی را بکار گیرید که برای اجرای طرح DR آموزش دیده باشند.

 

4- عدم موفقیت در دستیابی به یک قدرت پشتیبان مناسب. اگر سیستم شما تحت تأثیر یک وقفه محیطی گسترده قرار بگیرد ممکن است به مدت طولانی نتوانید از برق استفاده نمایید، باید مطمئن شوید که یک منبع انرژی مناسب با عمر طولانی خریداری کرده اید. سپس از یک پشتیبان اضافی برای باتری استفاده نمایید.

 

5- فراموش کنید چه منابعی باید اول از همه ذخیره شده و در اولویت قرار گیرد. کدام یک از کاربردهای IT در ابتدا قابل دسترس است؟ آیا مواردی وجود دارد که به مدت یکی دو روز بدون اینکه تجارت شما را تحت تأثیر قرار دهد معلق بماند؟ شما باید ترتیبی را انتخاب کنید که در آن کاربردها و سرویس ها به طور online پس از یک بحران مجدداً قابل کاربرد و دسترس باشند. به عنوان مثال ممکن است شما تصمیم بگیرید ایمیل شرکت خود را قبل از ذخیره سازی سرورهای فایل داخلی فعال نمایید. ممکن است سیاست هایی در این تصمیم نهفته باشد. باید اطمینان حاصل کنید که قبل از وقوع خطر به مشکلات آگاه شده اید و می توانید آنها را حل کنید.

 

6- عدم موفقیت در ایجاد اسناد مناسب برای طرح DR. بعد از ایجاد یک طرح، مطمئن شوید که یک دستور العمل مرحله ای کامل ایجاد کرده اید که می تواند نشان دهد چطور این طرح واکنشی را اجرا نمایید. مطمئن شوید که هر فرآیندی کاملاً مستند سازی شده است. موقعیت تمام منابع سیستم را شناسایی کرده و مشخص کنید کدام یک برای اجرا مناسب تر است. مطمئن شوید که آیا تمام اسناد را در موقعیت های چندگانه ذخیره کرده اید یا خیر و مشخص کنید تمام افراد مهم به کتابچه راهنما دسترسی دارند.

 

7- استناد کردن به سیستم Back up (پشتیبان). اگر اطلاعات شما به روز نباشد فرقی ندارد که این طرح شما تا چه اندازه موفق عمل می کند. آنچه که مهم است موقعیت هایی است که تحت تأثیر این فاجعه قرار می گیرد. فرآیند back up را در یک فاصله زمانی مشخص و منظم انجام دهید، تا اطلاعات شما محفوظ بماند. از یک تکنولوژی مثل VMware استفاده نمایید و سرعت بازیابی را افزایش دهید.

 

8- فراموش کرده اید که طرح واکنشی خود را تست کنید. شما باید مطمئن شوید که این طرح واقعاً در یک موقعیت اضطراری اجرا می شود. همان طور که قبلاً ذکر شد بسیاری از شرکت ها فراموش می کنند که طرح های واکنشی خود را بررسی و تست کنند. شما باید به طور منظم اطلاعات خود را کنترل کرده و مشکلات احتمالی را پیش بینی نمایید و قبل از وقوع رویداد بد به فکر راه حل آن باشید. در اینجا یک فن آوری به نام مجازی سازی VMware بکار می آید که می تواند سرور را کنترل کرده و هر دقیقه طرح DR را بررسی نماید.

 

9- کاری کنید که کلمه رمز به سختی مشخص شود. با وجود اینکه حفظ کلمه رمز یکی از اهداف مهم در امنیت داده ها است شما باید کلمه رمز مستقیم خود را در دو جای جداگانه حفظ کرده و هر زمان در هر کجا به راحتی به آن دسترسی داشته باشید. مطمئن شوید که بیش از یک فرد متخصص IT می تواند به تمام کلمه های رمز و کدها دسترسی پیدا کند و اگر افراد مهم شرکت از آنجا رفتند کلمه رمز توسط فرد دیگر براحتی قابل تغییر باشد.

 

10- زمانی که نمی توانید این طرح واکنشی را به روز کنید. شما همیشه باید طرح DR خود را به روز کنید. زمانی که شما این طرح را ایجاد می کنید هر 3 ماه یکبار آنرا بررسی کرده و به روز کنید. فهرستی از نکات قابل بحث را تهیه کرده تا بدانید کدام مورد برای تغییر طرح لازم است از جمله این موارد می توان به افراد، سیستم ها، موقعیت ها و شرایط اشاره کرد. این کار نه تنها مهارتهای پرسنل IT شما را حفظ می کند بلکه فرصتی را برای توسعه روش ها و طرح های جدید فراهم می کند.

تفاوت بین DRP و BCP

قبل از اینکه به سراغ تفاوت ها و شباهت های این دو واژه برویم باید بدانید که زمانیکه افراد مسئول با این دو واژه مواجه می شوند که می خواهند یک طرح ارائه بدهند که در مقابل تهدیدات و حملات و مشکلات و هر چیزی که ممکن است تجارت و سازمان آنها را دچار اختلال کند بعد از بروز اتفاق بد بتوانند فعالیت کاری را به حالت عادی برگردانند و این نقطه مشترک بین BCP و DRP است. این دو مفهوم در بسیاری از موارد بسیار شبیه به هم هستند اما به عنوان یک شخض مسئول شما باید دقیقا تفاوت بین آنها را درک کنید.

Business Continuity Plan یا BCP که به معنی طرح تداوم کسب و کار یا طرح تداوم تجارت مشهور است در واقع به مجموعه ای از فرآیند ها و دستورالعمل ها اطلاق می شود که توسط یک سازمان پیاده سازی می شود تا سازمان بتواند بعد یا در هنگام بروز یک فاجعه یا Disaster به کار خود و روند فعالیتی روزمره خود باز ادامه دهد. با استفاده از پیاده سازی یک طرح تداوم کسب و کار یا BCP ، سازمان ها در واقع به دنبال حفاظت از سرویس های حساس و حیاتی خود هستند تا بتوانند بعد از بروز فاجعه یا Disaster این سرویس ها را بلافاصله به مدار برگردانند و تجارت و کسب و کار خود را ادامه دهند. این نوع طراحی و برنامه ریزی که انجام می شود به سازمان اجازه می دهد تا بتوانند سرویس ها را به سرعت بازیابی و به سطح عملیاتی کامل خود در سریعترین زمان و با بالاترین کیفیت ممکن برسانند. در BCP معمولا تمامی فرآیندهای حساس تجاری سازمانی و همه عملیات های مهم تجاری تحت پوشش قرار می گیرند. BCP یک طرح کلان است و معمولا در سطح کلان هم اجرا می شود ، زمانیکه شما می خواهید به درستی مفهوم Business Continuity Plan را درک کنید چنین سئوالی را از خود باید بپرسید :

اگر کل ساختمان اداره یا سازمان ما از بین برود ، چگونه می توانیم تجارت خود را مجددا به حالت عادی برگردانیم ؟

 

Disaster Recovery Plan  یا DRP به معنی طرح بازیابی از فاجعه گفته می شود و در واقع ما می توانیم از DRP به عنوان یک زیر مجموعه از طرح کلان BCP نگاه کنیم. برای اینکه در یک سازمان ما بتوانیم یک طرح تداوم کسب و کار کامل و جامع داشته باشیم و پیاده سازی کنیم نیاز به طراحی و پیاده سازی مجموعه از DRP ها داریم. DRP بر خلاف BCP که بسیار کلان به همه مسائل نگاه می کند ، نگاه جرئی تر و دقیق تری به مشکلات دارد ، DRP ها معمولا بصورت طرح های کوچک فنی برای گروه های خاص در یک سازمان طراحی و تدوین می شوند و بعضا برای هر قسمت از فعالیت های سازمانی بصورت جداگانه یک طراح بازیابی از فاجعه جداگانه ایجاد می شود. یکی از شناخته شده ترین طرح های بازیابی از حادثه یا فاجعه (DRP) ای که معمولا همه DRP را با آن می شناسند، DRP  مخصوص حوزه فناوری اطلاعات یا IT DRP است. اما نباید فراموش کنیم که ما باید در همه حوزه ها DRP های جداگانه ای داشته باشیم تا در نهایت با تجمیع شدن همه این DRP ها یک BCP درست ایجاد کنیم. یک آزمایش ساده برای اینکه بدانیم در حال حاضر آیا در حوزه فناوری اطلاعات ما یک DRP دقیقا و کاربردی وجود دارد یا خیر این است که این سئوال را از خودمان بپرسیم :

اگر همین الان سرویس اتوماسیون اداری سازمان از بین برود چگونه باید آن را بازیابی و به محیط عملیاتی برگردانیم ؟

در طرح بازیابی از حادثه ای که برای سرویس های فناوری اطلاعات طراحی می شود یا در اصطلاح فنی تر IT DRP ها ، اولویت فعال کردن سرویس ها و تکنولوژی های مورد استفاده توسط کاربران و ارائه کردن هر چه سریعتر این سرویس های از کار افتاده است. بعد از فعال کردن این سرویس ها برای کاربران فعال کردن سرویس های دیگر برای سایر قسمت های سازمان در اولویت قرار می گرد ، توجه کنید که اگر مرکز داده یک انجمن دچار مشکل شود ، اولویت امر بالا آوردن و فعال کردن سرویس وب سایت است تا کاربران بتوانند از آن استفاده کنند ، بعد از اینکه کاربران توانستند از سرویس مجددا استفاده کنند نوبت به برطرف کردن مشکلاتی است که در مرکز داده وجود دارد و باعث بروز مشکل شده است.

یکی از برداشت ها و تصورهای اشتباهی که از IT DRP می شود این است که اکثر مدیران سازمانی ما که در حوزه فناوری اطلاعات فعالیت می کنند این سئوال را از خودشان می پرسند و با جواب دادن به آن خودشان را قانع می کنند : ما در مجموعه طرح بازیابی از حادثه حوزه فناوری اطلاعات را داریم بنابراین همه چیز آروم است و من چقدر خوشبختم ... ( دقیقا به همین ترتیب ) اما این واقعیت ماجرا نیست ، شما علاوه بر یک DRP خوب باید یک BCP خوب نیز در مجموعه پیاده سازی کرده باشید تا برای پرسنل حیاتی و مهم سازمان ، فرآیند های کلیدی و تجاری سازمان ، بازیابی اطلاعات حیاتی و ... طرح بازیابی از حادثه جداگانه ای را دیده باشید. بنابراین برای درک بهتر تفاوت DRP و BCP کافیست در حال حاضر DRP را یکی از زیر مجموعه های BCP قرار بدهیم . همیشه برای اینکه بتوانید یک DRP خوب برای هر یک از موارد و سرویس های سازمانی خود داشته باشید کافیست یک سئوال در خصوص قسمت های مختلف سازمان از خودتان بپرسید ، در صورت بروز مشکل در این قسمت چه اتفاقی در روند کاری سازمان پیش می آید ؟ اگر بروز مشکل در قسمت مربوطه روند کاری سازمان را دچار اختلال می کند بنابراین در آن قسمت شما نیاز به یک DRP خواهید داشت.

 

Replication

Replication  راه حلی برای انتقال اطلاعات از یک بانک اطلاعاتی SQL sever به یک بانک اطلاعاتی دیگر از همان نوع و البته مستقر در یک محل و کامپیوتر دیگر است . این فرآیند توسط ایجاد یک کپی از اطلاعات موجود در مبدا و انتقال به مقصد صورت می گیرد. در این ارتباط اطلاعاتی اصطلاحا به کامپیوتر و بانک اطلاعاتی مبدا، ناشر (publisher) و به کامپیوتر و بانک اطلاعاتی مقصد، مشترک یا متعهد (subscriber) می گویند البته این نوع رابطه، با وجود تنها یک ناشر اما یک یا چند مشترک امکان پذیر است. بدین معنی که اطلاعات یک بانک اطلاعاتی در مبدا قابل انتقال به چند مقصد مختلف است. از نسخه 7 به بعد SQL sever امکان تغییر اطلاعات در مقصد و انتقال آن به مبدا نیز وجود دارد . با این وصف، این رابطه داده ای بین ناشر و مشترک ممکن است گاهی اوقات بر عکس شود و جای مبدا و مقصد در یک مقطع زمانی عوض شود. بدین ترتیب یک کامپیوتر مشترک یا مقصد می تواند گاهی اوقات نقش ناشر یا مبدا در همان رابطه بازی کند. این قابلیت جدید Multi site update می گویند.

اصطلاحات Replication

انتشار یا Replication برای نامگذاری جزییات از اصطلاحات صنعت نشر(publishing) استفاده کرده است که شامل ناشر (Publisher) ، توزیع کننده (Distributor) ، مشترکین (Subscribers) ، نشریه (publications) ، مقالات (articles) و اشتراکات (subscriptions) می باشد. توضیح انتشار یا Replication وقتی که شما شرایط یک مجله را برای آن فرض می کنید ساده تر می شود.

یک ناشر یکی یا بیشتر مجله تولید می کند.

یک نشریه شامل مقالات می شود.

یک ناشر یا خودش مجله را مستقیما پخش میکند یا از یک توزیع کننده استفاده می کند.

هر کدام از مشترکین هر نشریه ای را که مشترک باشند دریافت می کنند.

در استفاده از این اصطلاحات این نکته را باید در نظر گرفت که انتشار یا Replication دارای عملیاتی می باشد که در صنعت نشر تعریف شده نمی باشد. به طور مثال توانایی مشترکین در اعمال تغییرات و توانایی ناشر در توسعه مقالات یک نشریه.

برای هر انتشار Replication یک توپولوژی هم باید در نظر گرفت که روابط بین سرورها و کپی اطلاعات و تعیین این که اطلاعات چگونه باید بین سرورها جریان پیدا کند را تعیین می کند.

ناشر (Publisher)

ناشر یک بانک اطلاعاتی نمونه می باشد که اطلاعاتی را برای انتقال از طریق Replication در دسترس قرار می دهد. ناشر می تواند دارای یک یا چند نشریه باشد که هر کدام به طور منطقی مجموعه ای از اشیا و اطلاعات را برای انتقال در اختیار دارند.

در واقع به database روی source سرور گفته می شود که قصد replicate داده های آن را داریم . به عبارت دیگر یک Publisher در واقع یک database Instance است که داده ها ی موجود در طی فرایند Replication به مکان های دیگر را در دسترس قرار می دهد . 

توزیع کننده (Distributor)

توزیع کننده یک بانک اطلاعاتی نمونه می باشد که به عنوان یک محل ذخیره برای اطلاعات خاصی از replication در ارتباط با یک یا چند ناشر عمل می کند. هر ناشر با یک بانک ساده به نام بانک توزیع در توزیع کننده در ارتباط است. بانک توزیع وضعیت داده ها در replication و اشیا و مقالات نشریه را در خود ذخیره می کند و در برخی موارد به عنوان یک صف برای انتقال اطلاعات از ناشر به مشترکین عمل می کند . در بیشتر موارد توزیع کننده و ناشر یک سرور هستند و بانک توزیع هم روی همان سروری قرار دارد که نشریه ما یا همان بانکی که قرار است replicate شود، قرار دارد. در این حالت به توزیع کننده، توزیع کننده محلی گوییم. در حالتی که بانک توزیع و نشریه روی دو سرور مجزا باشند به توزیع کننده، توزیع کننده دور می گوییم.

مقاله (Article)

به اطلاعاتی اطلاق می شود که قصد replicate آنها را داریم . این اطلاعات می تواند یک جدول یا یک روال یا procedure یا یک جدول فیلتر شده و ... را در برگیرد.

 Article بنیادی ترین عنصر سازنده replication است و درشت ترین (granular) سطح توزیع داده را تعریف می کند. یک Article را می توان بر اساس یک جدول، view، روال ذخیره شده(stored procedure) و تابع تعریف کرد.

مربوط ترین نوع Article برای دسترس پذیری بالا بر اساس جدول تعریف می شود. Article مجموعه داده ای را مشخص می کند که SQL Server به یک یا چند پایگاه داده replicate می کند.

نشریه (Publication)

به گروهی از article ها اطلاق می شود. یک article به تنهایی قادر به انتشار نیست از این رو نیاز به ایجاد publication داریم. به بیان دیگرانتشار یا publication به معنی مجموعه ای از Article ها است (اشیاء مختلف پایگاه داده ) که توسط ناشر منتشر شده است.

گروه بندی مقالات به عنوان نشریه باعث می شود که یک رابطه منطقی بین اشیاعی از بانک اطلاعاتی که قرار است منتشر شوند، ایجاد شود و اطلاعاتی که قرار است منتشر شود به صورت یک واحد در بیاید.

پایگاه داده ی توزیع شده (Distribution Database)

این پایگاه داده دربردارنده ی تمامی خط فرمانهای replication است. زمانی که هرگونه از تغییرات شمای DML یا DDL در Publisher اجرا شود ، دستورات مربوط به این اعمال که توسط SQL سرور تولید می شود ، دراین بخش ذخیره خواهد شد .این پایگاه داده می تواند روی همان سرور Publisher موجود باشد اما معمولا برای عملکرد بهتر توصیه می شود که آن را بر روی یک سرور مجزا قرار دهند. به طور معمول مشاهده شده که اگر distribution database روی همان ماشینی باشد که پایگاه داده ی publisher روی آن قرار دارد ، در صورتیکه تعداد زیادی Publisher موجود باشد ، این موضوع عملکرد سیستم را تحت تاثیر قرار می دهد و این دلیلی است که برای هر Publisher یک فایل distrib.exe ایجاد می شود.

مشترک (Subscriber)

مشترک یک بانک اطلاعاتی نمونه است که اطلاعات را دریافت می کند . یک مشترک می تواند نشریات مختلف را از ناشرین مختلف دریافت کند . با توجه به نوعی ازreplication که شما انتخاب می کنید ، مشترک می تواند اطلاعات را تغییر دهد و دوباره به ناشر بازگرداند و یا به مشترکین دیگری ارسال کند.

 چرخه ی انتشار با دریافت داده ها توسط یک مشترک پایان می یابد. تغییرات منتشر شده میان تمامی مشترکین یک فرایند انتشار، از طریق یک توزیع کننده تکثیر می شود. بنابراین یک مشترک با اشتراک و عضویت در یک فرایند انتشار در نهایت قادر به دریافت داده ها خواهد بود. به عبارت دیگر Subscriber یک Database Instance است که داده های replicate شده را دریافت می کند و نیز می تواند داده ها را از چندین ناشر (publisher) یا نشریه (publishers) بگیرد. بسته به نوع Replication ای که انتخاب می شود ، یک Subscriber می تواند داده ها را متقابلا به ناشر انتقال داده و یا آنها را برای سایر مشترکین منتشر کند.

اشتراک (Subscription) 

به درخواست یک مشترک یا subscriber برای دریافت نشریه یا publication اطلاق می شود و بر دو نوع است:Pull وPush که در واقع دو روش برای انتقال داده ها از distributor یا توزیع کننده به subscriber ها یا مشترکین محسوب می شوند. در ذیل به شرح آنها میپردازیم:

Push Subscription: در روش push subscription یک distributor یا توزیع کننده مسئول داده های بر صف از یک publisher بوده و درنهایت آنها را در اختیارsubscriber ها قرار می دهد.این نوع اشتراک مدیریت را ساده و متمرکز می کند چون سناریوی replication معمولی ، یک publisher و چندین subscriber را شامل می شود .مزیت این اشتراک امنیت بالای آن است چرا که فرایند آغازین در یک مکان مدیریت می شود. به عبارت دیگر کارایی distributor ها کاهش می یابد زیرا کل توزیع subscriber ها یک دفعه اجرا می شود.

Pull subscription: همانند روش push یک distributor یا توزیع کننده داده های بر صف یک publisher بوده و این وظیفه ی subscriber ها است که با distributor ارتباط برقرار کرده و داده های صف بندی شده ی آماده برای عمل replication را به تصرف خود درآورند. در مقایسه با روش push از روش pull برای نشریه هایی با امنیت پایین و تعداد بالای مشترک ها استفاده می شود. این نوع اشتراک رایج تربوده چرا که یک مشترک می تواند publication و یا نشریه هایی را انتخاب کند تا در آن شرکت کند.

انتشار (Replication)

  1. انتشار نوع ترکیب یا merge
  2. انتشار نوع تصویر لحظه ای یا snapshot
  3. انتشار نوع داد و ستد یا transactional

در SQL sever، سه نوع انتقال اطلاعات از طریق Replication وجود دارد. هر کدام از این سه راه ، سناریو ی خاصی برای انتقال اطلاعات از مبدا به مقصد و یا برعکس را مدیریت می کنند.

انتقال اطلاعات به روش ادغام (Merge)

این نوع انتقال اطلاعات که از قابلیت Multi site هم پشتیبانی می کند، زمانی مورد استفاده قرار می گیرد که استقلال داخلی هر بانک اطلاعاتی طرف یک رابطه، به رسمیت شناخته می شود. بدین معنی که در یک رابطه انتقال اطلاعات، هر کامپیوتر ضمن حفظ ساختار بانک اطلاعاتی خود، هم می تواند نقش ناشر را داشته باشد و هم نقش مشترک را ایفا نماید. در این حالت هر تغییری در جداول مشترک هر طرف دیگر اعمال می شود . نکته مهمی که در اینجا مطرح است این است که چطور طرفین این ارتباط متقابل باید با هم هماهنگ باشند و اولویت یکدیگر را به رسمیت بشناسند. به عنوان مثال فرض کنید در یک زمان واحد ، هر دو طرف بخواهند اطلاعاتی را در مورد یک جدول بانک اطلاعاتی به یکدیگر ارسال کنند. (یعنی بروز حالت تداخل ) این مشکل با استفاده از روش خاصی که هر نوع Replication مخصوص خودش دارد قابل حل است. به طور کلی در حالت ادغام، یک پایگاه داده حایل میان ناشر و مشترک به عنوان توزیع گر (Distributor) ساخته می شود. این پایگاه داده به نام Distributor در لیست پایگاه های داده ای ناشر قرار می گیرد و وظیفه ایجاد همزمانی (synchronization) بین ناشر و مشترکین را ایفا می کند.

پایگاه داده توزیع گر هم می تواند در سمت ناشر و هم در یک کامپیوتر میانی دیگر (غیراز کامپیوترهای سمت مشترک) قرار داشته باشد. این پایگاه داده ضمن ایجاد همزمانی در ردو بدل اطلاعات بین ناشر و مشترک، این امکان را نیز فراهم می سازد تا مدیر سیستم بتواند اولویت و در واقع ارجحیت جهت انتقال اطلاعات در زمینه بروز تداخل را مشخص کند. این اولویت priority در زمان تعریف طرف های ناشر و مشترک یک Replication از نوع ادغام توسط مدیر سیستم تنظیم می شود.

 تصویر برداری از اطلاعات (Snapshot)

در این روش ابتدا یک تصویر کامل از آنچه که باید از سمت ناشر به سمت مشترک برود تهیه می شود. این تصویر هم شامل خود ساختار آنچه که منتقل می شود (مثلا ساختار یک جدول) و هم شامل اطلاعات داخل آن است. در ابتدای کار، تصویرمذکور عینا به مشترک فرستاده می شود. روند و توالی ارسال این تغییرات هم همانند حالت قبل (ادغام) طی یک فاصله زمانی مشخص مثلا ساعتی یک بار که توسط مدیر سیستم قابل تنظیم است، انجام می گیرد.

یکی از مزایای این روش نسبت به حالت ادغام، این است که زمان کمتری از وقت مدیر سیستم را جهت پیکربندی و تنظیم عمل انتشار صرف می کند و به دلیل اینکه در ابتدای عمل انتشار، خود ساختار نیز عینا به مشترک منتقل می شود، از قابلیت اطمینان بیشتری برخوردار است. به طور کلی کاربرد این نوع انتقال اطلاعات، زمانی است که مدیر سیستم قصد ایجاد یک ارتباط ساده و یک طرفه ولی مطمئن دارد.

انتقال بر اساس فرآیند (Transactional)

این روش یکی از بهترین و قابل کنترل ترین روش های انتقال است. در این روش هر تغییری که در جداول ناشر صورت می گیرد ، به صورت یک دستور SQL درآمده که تحت یک فرآیند واحد هم در سمت کلیه مشترکین اجرا می شود . در این صورت اگر به طور مثال یکی از مشترکین به دلیلی با اشکال مواجه شده و تغییر مورد نظر در آن انجام نشود ، این تغییر نه در خود ناشر و نه در هیچ کدام از مشترکین دیگر نیز انجام نخواهد شد ، بدین معنی که یا یک تغییر در اطلاعات برای تمام کامپیوتر ها اعم از ناشر و کلیه مشترکین انجام می شود و یا این که برای هیچ کدام انجام نخواهد شد در این حالت هم یک پایگاه داده به واسطه به نام Distribution نقش دریافت وارسال فرآیند را به طرف مشترک ایفا می کند . در واقع روش فرآیند ، در مقایسه با دو روش قبل از حالت به هنگام (online) بودن بیشتری برخورداراست . یعنی این که هر فرآیند و هر دستور در همان لحظه که می خواهد در ناشر اجرا شود ، به واسط فرستاده شده و سپس در یک زمان واحد در کلیه مشترکین نیز انجام می شود و در واقع زمان تغییر اطلاعات در ناشر و در مشترکین تقریبا یکسان است . همچنین در این روش تداخلی هم پیش نمی آید . چون هر تغییری ابتدا باید به واسط فرستاده شود و از آن جا به جاهای دیگر ارسال شود و واسط هم آن ها را در یک صف اولویت (priority queue ) قرار داده و به ترتیب انجام می دهد . نتیجه این نوع انتقال اطلاعات ، داشتن چند پایگاه داده کاملا یکسان و به هنگام در مکان های مختلف است که همگی از یک ناشر ، اطلاعات مورد نظر را دریافت می کنند.

Transactional Replication مي تواند جهت اعمال بر پايگاه داده مورد استفاده قرار گيرد. در اين روش تغييرات اعمال شده بر روی Article ها سريعا از Transaction Log گرفته شده و به Distributor ها ارسال مي گردند. اين روش تنها زماني مورد استفاده قرار مي گيرد که بخواهيم تمام سيستمهاي Replicate شده را به روز نگه داريم. اين روش نسبت به روش قبل Overhead بيشتری بر روي سيستم ايجاد مي کند زيرا به تنهايي هر تراکنشی را که باعث تغيير داده ها در سيستم مي شود در سيستمهای Replicate شده اعمال می کند. Transactional Replication نسبت به دو روش ديگر Replication، داده ها را به روز تر نگه می دارد.

شرح replication Agent ها در SQL سرور

حال به توضیح عواملی که برای انجام replication در پشت صحنه فالیت می کنند می پردازیم که Agent نامیده می شوند. این agent ها در فایلهای مربوطه با پسوند exe در مسیر………..\110\COM folder قرار دارند. همچنین تمامی اطلاعات مربوط به agent ها در جداول dbo.MSxxx__agents و dbo.MSxxx__history موجود در Distribution database ثبت شده اند. حال به شرح انواع agent ها و اینکه در کدام نوع از انواع replication کاربرد دارند می پردازیم (برای روشن شدن این مبحث در اینجا اشاره می کنیم که replication در SQL سرور به سه نوع Snapshot و transactional و merge تقسیم می شود که نیازمند Agent ها برای فعالیت خود هستند.) و اما شرح Agent ها :

Snapshot Agent: یک فایل اجرایی است که snapshot فایل های در بردارنده ی شماتیک یا ساختار و داده های جداول و اشیاء پایگاه داده را ایجاد کرده و آنها را در Distributor ذخیره می کند همچنین اطلاعات مربوط به وضعیت synchronization را در distribution database ثبت می کند.

Distribution Agent: برای انواع snapshot و transactional مورد استفاده قرار می گیرد. و فایل های snapshot را از distribution db به مشترکین انتقال می دهد همچنین تمامی تراکنش های منتظر برای انتشار را نیز به subscriberها منتقل می کند و برای هر دو push subscription و pull subscription قابل اجرا است.

Log Reader Agent: برای transactional replication استفاده می شود تراکنش های مشخص شده برای replication را از transaction log به distribution db روی publisher انتقال می دهد. هر پایگاه داده ای log reader مختص به خود را دارد که روی distributor اجرا شده و با publisher ارتباط بر قرار می کند.

Merge Agent: در merge replication کاربرد دارد و snapshot اولیه را برای subscriber ها اجرا کرده و تغییرات تدریجی به وجود آمده روی داده ها را نیز ادغام کرده وبه subscriber ها انتقال می دهد. هر اشتراک ادغامی merge agent خود را دارد که قادر به برقراری ارتباط با publisher و subscriber و به روزرسانی هر دوی آنها می باشد.

Queue Reader Agent: برای transactional replication کاربرد دارد و بر روی Distributor اجرا شده و تغییرات صورت گرفته در سمت subscriber را به publisher باز می گرداند. برخلاف merge agent وagent distribution تنها یک نمونه از Queue Reader Agent برای سرویس دهی به تمامی publisher ها و publication ها و برای یک distribution db معین وجود دارد.

 

فیلتر کردن داده های منتشر شده

فیلتر کردن جداول موجود در article ها ما را قادر می سازد تا پارتیشن هایی از داده ها را برای انتشار ایجاد کنیم .به کمک فیلتر کردن داده های منتشر شده می توان :

  • داده های ارسال شده روی شبکه را به حداقل رساند .
  • مقدار فضای ذخیره سازی مورد نیازبرای یک مشترک را کاهش داد.
  • نشریات یا publication ها را سفارشی سازی کرده و نیز شرایطی را فراهم کرد که application ها بر اساس نیازهای اختصاصی یک مشترک باشند.
  • اگر مشترکین داده ها را به روزرسانی کنند ، می توان از بروز conflict ها جلوگیری کرده و یا آنها را کاهش داد زیرا پارتیشن های داده های مختلف می توانند برای مشترکین مختلف ارسال شوند. ( در واقع در این شرایط هیچ دو مشترکی قادر به بروزرسانی داده های مشابه نخواهند بود)
  • می توان از انتقال اطلاعات مهم و حساس جلوگیری کرد. فیلتر های ردیف و فیلترهای ستون ها می توانند برای محدود کردن دسترسی مشترک به داده ها مورد استفاده قرار گیرند.

Replication چهار نوع فیلتر را ارائه می دهد که در ذیل به معرفی آنها می پردازیم :

  1. Static row filter ها یا فیلتر کردن ردیف ها به صورت استاتیک که برای تمامی انواع replication ازقبیل snapshot و transactional و merge کاربرد دارد . با استفاده از آن قادر خواهیم بود زیر مجموعه ای از ردیف هایی را که منتشر می شوند ،انتخاب کنیم و یا در واقع بر حسب نیازمان آنها را محدود کنیم .
  2. Column filter یا فیلتر کردن ستون که این نوع فیلتر نیز برای تمامی انواع replication به کار می رود و به کمک آن می توان زیرمجموعه ای از ستونهایی را که منتشر می شوند، انتخاب کرد.
  3. Parameterized row filtered یا فیلترهای پارامتری ردیف ها تنها برای merge replication به کار گرفته می شود . این نوع از فیلتر از نظر مفهوم همانند static filter است اما در اجرا تفاوت قابل توجهی با یکدیگر دارند .هدف parameterized filter ایجاد چندین پارتیشن از داده ها است که بدون ایجاد چندین نشریه یا publication بتوانند replicate داشته باشند. به عنوان مثال اگر ما از جدول پایه ی یکسانی استفاده کنیم و دو مشترک مختلف به نام های A و B نیز داشته باشیم که هر کدام به زیر مجموعه هایی متفاوتی از آن جدول نیاز داشته باشند ، هنگام استفاده از فیلترهای ردیفی استاندارد نیازمند ایجاد دو نشریه یکی برای مشترک A و دیگری برای مشترک B خواهیم بود .اما با استفاده از فیلتر های پارامتری می توانیم برای مشترکین A و B به صورت مجزامقادیر مورد نظر متفاوتی را در نظر بگیریم. اما در نهایت هر یک از این مقادیر و مجموعه داده ها به عنوان بخشی از یک نشریه محسوب می شوند.
  4. Join filter یا فیلتر الحاق که تنها برای merge replication کاربرد دارد و این نوع فیلتر به طور معمول همراه با parameterized filter ها برای بسط وگسترش فیلترینگ به دیگرجداول مربوطه به کار می رود. مثلا یک نمایندگی فروش معمولا داده های جداول دیگر از قبیل مشتریان و دیگر جداول را دارد .این دادها می توانند فیلتر شده باشند به طوری که نماینده فروش تنها داده های مشتریان خود و سفارشات آنها را دریافت کند. این نوع فیلتر همچنین می تواند همراه با static filter ها نیز به کار گرفته شود.

توپولوژی هایی که MS SQL سرور برای انجام Replication آنها را پشتیبانی می کند:

Central Publisher: این یکی از پر کاربردترین نوع توپولوژی ها است که در replication مورد استفاده قرار می گیرد .در این سناریو یک سرور به عنوان publisher و distributor منظور شده و سرور و یا سرور های دیگر به عنوان subscriber ها در نظر گرفته می شوند.

Central subscriber: این یک توپولوژی رایج درانبار داده ها است. سرورها یا پایگاه داده های متعددی داده های خود را با یک سرور مرکزی replicate می کنند.

Central publisher with remote distributor: در این توپولوژی Distribution database روی یک سرور مجزا از Distributor در نظر گرفته می شود از این ساختار زمانی استفاده می شود که سطح فعالیت های replication افزایش پیدا می کند و یا اینکه سرور و یا منابع شبکه محدود شده اند . این توپولوژی زمان load را برای publisherکاهش داده اما بطور کلی موجب افزایش ترافیک شبکه می شود.

Central distributor: در این توپولوژی publisher های متعدد تنها از یک distributor استفاده می کنند که روی سروری مجزا پیاده سازی شده است . این نوع توپولوژی عملا چندان مورد استفاده قرار نمی گیرد. چرا که تنها دارای یک point of failure می باشد (یعنی همان سروری که به عنوان distributor مرکزی پیکربندی شده است) و اگر سرور distributor دچار اختلال شده و یا از کار بیفتد ، کل عملیات replication ای که بر اساس این سناریو صورت می گیرد ، نابود خواهد شد.

Publishing Subscriber: این توپولوژی دارای نقشی دوگانه است . در این ساختار دو سرور داده های یکسان را منتشر می کنند. یکی از سرورهایی که عهده دار نقش publisher است داده ها را برای subscriber ارسال کرده و سپس subscriber داده ها را برای هر تعداد از مشترکین موجود منتشر می کند. این توپولوژی هنگاهی کاربرد دارد که یک publisher قصد انتقال داده ها را از طریق لینکهای ارتباطی کُند و یا گران قیمت به subscriber ها داشته باشد.

 

Veeam

اگر کمی با نرم افزارهای مجازی سازی مثل Hyper-V شرکت مایکروسافت یا VSPhere شرکت VMware کار کرده باشید حتما با نام Veeam تا حدودی آشنایی پیدا کرده اید. Veeam یکی از بهترین محصولات Backup گیری از محصولات مجازی سازی در دنیاست و چندین سال است که به عنوان بهترین محصول برای تهیه Backup از ساختارهای مجازی سازی استفاده می شود. با استفاده از نرم افزار Veeam Backup & Replication شما می توانید براحتی با سرعت و انعطاف پذیری و همچنین قابلیت اعتماد بالا داده ها یا نرم افزارهای موجود در محیط های مجازی سازی را بازگردانی یا Recovery کنید. این نرم افزار راهکارهای Backup و Recovery را بصورت یکپارچه به شما ارائه می کند و برای محیط های مجازی مانند hyper-v و VSPhere بسیار مناسب می باشد. این نرم افزار یکی از مدرن ترین ابزارهای Backup گیری در محیط Cloud نیز محسوب می شود و تقریبا حفاظت از اطلاعات موجود در VM های شما را تضمین می کند. با استفاده از این نرم افزار شما دیگر نیازی به به روز رسانی Agent های مختلف ندارید و براحتی و به سادگی می توانید Backup های گرفته شده در VM ها را بازگردانی کنید.

به طور خلاصه Veeam Backup & Replication یک راه حل حفاظت از اطلاعات Data Protection و بازیابی اطلاعات Disaster Recovery برای محیط های مجازیِ VMware vSphere و Hyper-V در هر اندازه و هر سطح پیچیدگی است.

محیط های قابل پشتیبانی توسط این نرم افزار

زیرساخت مجازی

در جدول زیر زیرساخت های مجازی پشتیبانی شده در سه بخش Platform ، Hypervisor و Management Server تقسیم بندی شده اند.

ax jadval

Virtual Hardware

  • ماشین های مجازی که از SCSI bus sharing استفاده می کنند ، پشتیبانی نمی گردند. دلیل آن این است که VMware نمی تواند از این نوع ماشین های مجازی Snapshot تهیه نماید.
  • دیسک های مجازی RDM که به صورت Physical Mode پیکربندی شده باشند ، دیسک های Independent و دیسک هایی که توسط in-guest iSCSI Initiator با ماشین مجازی در ارتباط باشند ، پشتیبانی نمی شوند. این نوع دیسک ها به صورت اتوماتیک از فرآیند پردازش های Veeam Backup & Replication حذف می شوند. Network Share ها نیز توسط Veeam پردازش نمی شوند. چرا که اطلاعات آن ها در VM Configuration File ثبت نمی شود.

OS

تمام سیستم عامل ها توسط Veeam Backup & Replication پشتیبانی می گردند.

vCloud Director

آخرین ویرایش Veeam Backup & Replication به صورت کامل با vCloud Director نسخه ۵ تا   ۸.۱۰ سازگار است.

Supported File Systems

لیست سیستم فایل های مورد پشتیبانی در جدول زیر مشخص گردیده است :

ax

همان طور که در تصویر بیان شده است پشتیبانی از بازگردانیِ فایل سیستم های ReFS تنها زمانی فعال می شود که Veeam Backup & Replication  بر روی Windows 2012 به بعد نصب شده باشد.

با وجود اینکه Veeam هر دو دیسک های Dynamic و Basic را پشتیبانی می نماید ، اما از Volume هایی که بر روی دیسک های داینامیک Split ، Spanned یا Striped شده باشند بک آپ تهیه نمی کند.

پیش نیازهای سخت افزاری و نرم افزاریِ Veeam Backup & Replication

استفاده از سرور مشترک با سرویس های حیاتی

شرکت Veeam توصیه اکید دارد که نرم افزار Veeam از سرور مشترک با سرویس های حیاتی شبکه ساز مان از جمله VMware vCenter Server ، Domain Controller و Microsoft Exchange Server استفاده نکند.

Microsoft Windows Server Core

Veeam Backup & Replication و Veeam Backup Enterprise Manager قابلیت نصب بر روی Microsoft Windows Server Core را ندارند. اما می توان Role  های زیر را به ماشین هایی که از Windows Server Core  استفاده می کنند محول نمود :

Backup Proxy

Backup Repository

WAN Accelerator

Veeam Cloud Connect Infrastructure Components

Tape Infrastructure Components

 

Domain Member

هیچ الزامی وجود ندارد ماشین میزبان Veeam Backup & Replication عضو دامین باشد. اما اگر قرار است ، آیتم های Microsoft Exchange توسط Veeam Backup Enterprise Manager UI بازیابی شوند ، Veeam Backup Enterprise Manager UI بایستی بر روی ماشینی که عضو دامین فارست مربوط به Mail Box است نصب گردد.

All-in-One Installations

برای نصب به صورت All-in-One هر Role به حداقل ۲ گیگابایت حافظه نیاز خواهد داشت.

Hardware Requirement

در تصویر زیر پیش نیازهای سخت افزاری Backup Server به صورت کلی نمایش داده شده است

ax

OS Requirement

Backup Server نسخه ۹.۵ بر روی همه نسخه های ویندوز کلاینت و سرور از Windows 7 سرویس پک ۱ به بعد قابل پیاده سازی است.

Software Requirement

در ویزارد نصب Veeam Backup & Replication وجود پیش نیاز های نرم افزاری لازم بررسی می گردد. در صورتی که پیش نیاز ها بر روی سیستم وجود نداشته باشند ، Wizard پیشنهاد نصب اتوماتیک آن ها را ارائه خواهد داد. لیست نرم افزار های مورد نیاز را در تصویر زیر مشاهده می نمایید.

ax

به جز نرم افزارهایی که در تصویر بالا مشاهده می نمایید ، قطعا نیاز به دیتابیس SQL نیز خواهید داشت. Veeam هر دو ویرایش Full و Express را پشتیبانی می نماید. همچنین با نسخه Microsoft SQL Server 2008 به بالا سازگار می باشد.

 

Backup Target

یکی از سوالات مهم درباره نرم افزارهای Backup این است که اطلاعات Backup را در چه ذخیره سازهایی می توانند نگه داری نمایند. در واقع باید بدانیم که از چه Storage  هایی می توان به عنوان مقصد Backup استفاده نمود. Backup Target های زیر در Veeam پشتیبانی می گردند.

Local Storage یا دیسک های محلی

 Direct Attached Storage یا DAS

Storage Area Network یا SAN  حتی اگر توسط Virtual HBA یا Software iSCSI initiator به SAN fabric متصل شده باشد 

Network Attached Storage یا NAS

Dell EMC DataDomain با DD OS نسخه ۴ به بعد با لایسنس DDBoost  هر دو ارتباط Ethernet و Fiber Channel پشتیبانی می گردد 

ExaGrid

HPE StoreOnce با Firmware نسخه ۱۳.۱ و بعد تر و لایسنس Catalyst

 

قرارداد نام گذاری

قرارداد نام گذاری یا Naming Conventions دستورالعمل عدم استفاده از نام های رزرو شده توسط مایکروسافت است. از این نام ها نباید به عنوان نامِ Backup Server ، Managed Servers ، Backup Repositories ، Jobs ، Tenants و سایر آبجکت ها استفاده شود. اسم های زیر مجموعه این قرارداد در این لینک قرار دارند.

آیا Veeam Backup & Replication می تواند بلایِ جان امنیت شبکه شود؟

زمانی که قصد ایجاد یک زیرساخت Backup در سازمان را دارید یکی از مواردی که نباید به هیچ عنوان از آن چشم پوشی شود ، امنیت زیرساخت Backup است. Backup Infrastructure پتانسیل زیادی برای استفاده شدن به عنوان یک BackDoor برای دسترسی به اطلاعات حساس سازمان را دارد

 

Backups and Replicas

برای تامین امنیت اطلاعات موجود بر روی Backup و Replica در سازمان موارد زیر را رعایت نمایید :

  • از امنیت فیزیکی سرور های مقصد اطمینان حاصل نمایید. تفاوتی ندارد که Backup شما بر روی Server ، SAN یا Tape و CD ذخیره شود. زمانی که مهاجم دسترسی فیزیکی به محل نگه داری تجهیزاتی که به عنوانِ مقصدِ پشتبان گیری استفاده می شوند داشته باشد ، تقریبا امنیت اطلاعات پشتیبان گرفته شده نزدیک به صفر است. در این حالت Risk تهیه Backup از عدم تهیه Backup هم بیشتر است. البته بستگی به این دارد که چه قدر اطلاعات محرمانه باشند.
  • دسترسی کاربران را به سرور های Backup و Replica محدود نمایید. مطمئن شوید که همه کاربران به طور مستقیم به فایل های ذخیره شده در تجهیزات پشتیبان گیری دسترسی نداشته باشند.
  • اطلاعات پشتیبان گرفته شده را رمزنگاری نمایید. این یکی از قابلیت هایی است که خوشبختانه در نرم افزار Veeam Backup and Replication نیز گنجانده شده است. در این صورت مهاجم حتی در صورت دسترسی به اطلاعات ، نخواهد توانست از آن ها استفاده کند. ( البته هنوز می توان اطلاعات را تخریب نمود)

 

Data Communication Channel

جهت تامین امنیت اطلاعات در شبکه بین مبدا و مقصد پشتیبان گیری راه کارهای زیر از توصیه های Veeam Backup and Replication است.

Isolate Backup Traffic  : استفاده از یک ارتباط شبکه ای ایزوله شده بین اجزای مختلف زیرساخت Backup که شمامل Backup Servers ، Backup Proxies و Repositories می شود.

Encrypt network traffic : به طور پیش فرض Veeam Backup and Replication در هنگام انتقال اطلاعات در بستر Public Network یا شبکه های عمومی از قابلیت Encryption اطلاعات استفاده می نماید. اما می توان این قابلیت را برای انتقال داده در شبکه خصوصی سازمان یا Private Network نیز فعال نمود. در اینم صورت حتی اگر مهاجم به شبکه داخلی سازمان نیز نفوذ کرده باشد ، موفق نخواهد شد اطلاعات را از بستر شبکه Capture کند

 

Credentials

همان طور که می دانید ، نرم افزارهای Backup جهت اجرای فرآیند پشتیبان گیری به دسترسی های سطح بالایی بر روی سرور مبداِ Backup نیاز دارند. همچنین Veeam Backup & Replication از جمله Backup Solution هایی است که قابلیت تهیه پشتیبان از زیرساخت مجازی را دارا می باشد. به همین دلیل ریسک زیادی از نظر امکان دزدیده شدن Credential از طریق سرور Veaam وجود دارد. اما چگونه می توان امکان دزدیده شدن Credential یا همان نام کاربری و رمز عبور معتبر را کاهش داد؟

یکی از مهم ترین توصیه ها استفاده از آخرین به روزرسانی های سیستم عامل ها به محض انتشار است. چرا که در بسیاری از به روزرسانی های امنیتی ممکن است جلو چندین روش سرقت Credential گرفته شده باشد. که این مورد لزوم استفاده از سیستم عامل های با لایسنس معتبر و قابل به روز رسانی را بیش از پیش برای مدیران سازمان ها و ادمین های شبکه نمایان می کند. علاوه بر عدم به روزرسانی سیستم عامل ، استفاده از Outdated authentication protocols هم به همان اندازه ریسک بالایی محسوب می شود.

بنابراین از دریافت به روزرسانی ها در سرورهای موجود در زیرساخت Backup به شکل مستمر اطمینان حاصل نمایید.

برای SSH از قوی ترین Encryption های موجود بهره ببرید. (Veeam از SSH برای ارتباط با سرور های لینوکسی استفاده می کند) مطمئن شوید که Private Key ها در امن ترین مکان ممکن نگه داری می شوند.

 

چطور یک VSphere Server به Veeam Backup & Replication اضافه نماییم؟

در Veeam backup & Replication می توان هاست های ESXi یا vCenter را اضافه نمود.  اگر ESXi شما توسط vCenter مدیریت می شود ، توصیه می شود که حتما vCenter را به جای هاست به Veeam معرفی نمایید. زیرا در این حالت زمانی که ماشین های مجازی بین هاست ها Migrate می شوند ، نیازی به تعریف مجدد Job های بک آپ نخواهد بود. در این صورت Veeam Backup and Replication به صورت خودکار Migrate ماشین های مجازی را تشخیص می دهد و با دانستن مکان فیزیکی جدی هر VM همچنان به پشتیبان گیری از آن ادامه می دهد.

 

برای اضافه کردن یک VMware vSphere Server از ویزارد New VMware Server استفاده می شود.

  • وارد کنسول مدیریتی Veeam Backup & Replication شوید.
  • بر روی Backup Infrastructure از منوی سمت چپ کلیک و سپس VMWare vSphere را انتخاب نمایید.

Adding-vSphere-Server-to-Veeam-1عکس

در پنجره New VMware Server و در فیلد DNS name or IP address نام یا آی پی ESXi یا vCenter مقصد را بنویسید.

عکس2

در مرحله Credentials حساب کاربری با دسترسی مدیریت vCenter یا ESXi را اضافه و بر روی Next کلیک کنید.

عکس3

پس از اینکه ارتباط با vCenter یا ESXi بررسی شد و Connection از طریق پروتکل SSH انجام شد ، صفحه Summary نمایش داد می شود. با کلیک بر روی Finish فرآیند اضافه نمودن vSphere Server به پایان می رسد.

عکس4

روالِ کار بیش تر نرم افزار های Backup به این صورت است که در ابتدا سیستم های مختلفی را که قصد پشتیبان گیری از آن ها را داریم معرفی می نماییم. در نرم افزار Veeam Backup & Replication می توانیم از پلت فرم های متفاوتی Backup تهیه کنیم. برای مثال این نرم افزار به جز پشتیبان گیری از زیر ساخت مجازی و ماشین های مجازی موجود در آن ، از هاست های فیزیکی با میزبانی انواع ویندوز و لینوکس نیز Backup تهیه می نماید. در این مقاله نحوه اضافه نمودن سرور های زیر ساخت مجازی بیان گردید. اما درباره سایر پلت فرم ها نیز تقریبا روال کار به این صورت خواهد بود.

پس از معرفی پلت فرم های متفاوت به Veeam Backup and Replication نیاز است که Job هایی جهت Backup تعریف گردد. (معمولا در سایر نرم افزار های Backup نیز روال کار به همین صورت است.) این Job ها تنظیمات متفاوتی را دارا هستند. ( زمان اجرا ، نحوه اجرا و … )

 

SureBackup در نرم افزار Veeam Backup & Replication چیست و چه کاربردی دارد؟

همان طور  که می دانید یکی از مهم ترین وظایف Backup Administrator ها اطمینان از کارکرد صحیح پشتیبان های تهیه شده است. فرض کنید در سازمانی مشغول به کار هستید و حدود سه سال به طور منظم از یک VM توسط بهترین نرم افزار موجود در بازار Backup تهیه نموده اید. بعد از سه سال در زمان وقوع  Disaster یا بحران متوجه می شوید که فایل های Backup به درستی عمل نمی کنند.

در این شرایط شما مطابق اصول و به طور منظم پشتیبان گیری نموده اید و ممکن است هزینه بسیاری را هم جهت تهیه فایل های پشتیبان متحمل شده باشید. اما در عمل این فایل ها اکنون برای شما بی استفاده هستند.

در گذشته برای جلوگیری از وقوع این مشکل Backup ها به صورت Random بررسی می شدند. یعنی یکبار آن ها را با صرف زمان و هزینه زیاد بازگردانی می کردند ، که از صحت عملکرد آن اطمینان داشته باشند. اما در نرم افزار Veeam Backup and Replication ساز و کاری وجود دارد که چنین کاری به صورت اتوماتیک صورت می پذیرد.

SureBackup یکی از تکنولوژی های کمپانی Veeam است که برای اطمینان از درستی کارکرد بک آپ هایی که از VM ها گرفته می شود ، ایجاد شده است. با این تکنولوژی شما می توانید مطمئن شوید که Backup های ایجاد شده قابل بازیابی هستند. در این روش فایل پشتیبان تهیه شده از VM در یک محیط ایزوله به صورت اتوماتیک Boot می شود. از این طریق صحت کارکرد درست آن بررسی می گردد.

قابلیت SureBackup در نسخه های Enterprise و Enterprise Plus نرم افزار Veeam Backup & Replication وجود دارد. اگر در سازمان از نسخه استاندارد استفاده می نمایید ، جهت تست کارکرد صحیح پشتیبان ها در زمان بحران باید از روش غیر اتوماتیک بهره ببرید. در واقع در این حالت مجبور هستید که از طریق Instant VM Recovery نسبت به کارکرد صحیح Backup اطمینان حاصل نمایید.

SureBackup چگونه کار می کند؟

  • در ابتدا Veeam Backup and Replication ماشین های مجازی را در Application Group به اصطلاح Publish و صحت کارکرد آن ها را در یک آزمایشگاه مجازی به عنوان یک محیط ایزوله بررسی می نماید.
  • این VM ها در محیط آزمایشگاه مجازی به صورت مستقیم از محل Backup Repository اجرا می گردند. برای این کار نیاز است که از تکنولوژی به نام Veeam vPower NFS Service استفاده شود.
  • Veeam Backup and Replication سه تست مهم را در محیط آزمایشگاهی بر روی فایل پشتیبان VM ها انجام می دهد. این تست ها شامل Heartbeat Test ، Ping Test و Application Test می شوند.
  • اگر SureBackup برای اعتبار سنجی فایل های پشتیبان پیکربندی شده باشد ، در این صورت Veeam Backup and Replication یک CRC Check نیز بر روی فایل ها اجرا می نماید. به این فرآیند در داکیومنت های وییم ، Backup File Validation گفته می شود. Backup File Validation همیشه آخرین مرحله تستِ صحت کارکرد Backup است. زمانی که فرآیند Recovery Verification Process یا تصدیق بازیابی به پایان رسید ، VM ها از آزمایشگاه مجازی به اصطلاح Unpublish می شوند و یک گزارش از تست ها و نتیجه آن ها ایجاد می گردد. بسته به تنظیمات صورت پذیرفته در زمان پیکربندی ، این گزارش می تواند به صورت اتوماتیک برای Backup Administrator ها ارسال گردد.

Veeam VPower NFS چیست و چه کاربردهایی دارد؟

جهت اجرای مستقیم ماشین های مجازی از محل Backup Repository  از فناوری vPower NFS Service استفاده می شود.

Veeam vPower NFS Service

برای بررسی Backup های تهیه شده از VM ها با استفاده از SureBackup ، نرم افزار Veeam Backup & Replication از تکنولوژی vPower بهره می برد. تکنولوژی vPower ویژگی های زیر را ارائه می دهد:

  • Recovery Verification یا تایید امکان بازیابی صحیح
  • Instant VM Recovery  یا امکان بازیابی سریع ماشین مجازی
  • Universal Application-Item Recovery  که به اختصار به آن U-AIR گفته می شود و این امکان را فراهم می نماید که Object ها را به صورت تکی را از برخی برنامه های اجرا شده در محیط مجازی بازیابی نمایید. برای مثال امکان بازیابی یک Email پاک شده ، یک Record پاک شده از دیتابیس و یک فایل و دایرکتوری خاص در Share Folder را فراهم می کند.
  • On-Demand Sandbox که ترجمه آن می شود گودال شن بازی! البته لازم به ذکر است که ترجمه چندان بی ربطی هم نیست. چرا که این ویژگی محیط مجازی را فراهم می کند که بتوانید ماشین های مجازی پشتیبان گرفته شده را در آن به صورت آزمایشی اجرا نمایید و در واقع در آن محیط هر بلایی که خواستید بر سر ماشین های مجازی می آورید. برای مثال Patch ها  و Upgrade ها را امتحان کنید یا نرم افزارهای جدید را بر روی ماشین مجازی تان امتحان نمایید.
  • Multi-OS file-level restore

کلید پیاده سازی تکنولوژی vPower سرویس vPower NFS Service است. vPower NFS Service سرویسی است که در ویندوز اجرا می شود تا باعث شود ویندوز ، مانند یک NFS Server عمل کند.

در سروری که این سرویس راه اندازی می شود ، نرم افزار Veeam Backup & Replication یک دایرکتوری مخصوص به عنوان vPower NFS Datastore ایجاد می نماید. زمانی که شما یک VM را از محل Backup راه اندازی کنید ، Veeam Backup and Replication فایل VMDK مربوط به آن را در همین دایرکتوری که vPower NFS Datastore است منتشر می کند. البته توجه داشته باشید که در این جا منتشر به این معنا است که یک فایل شبیه سازی شده از VMDK اجرا می شود و VMDK اصلی دست نخورده باقی خواهد ماند.

در این مرحله vPower NFS Datastore به هاست ESXi به اصطلاح Mount می شود. بنابراین ESXi می تواند ایمیجِ  ماشین های مجازی را از طریق vPower NFS DataStore مشاهده و با آن ها به عنوان فایل های معمولی VMDK رفتار کند.

در نهایت فایل های شبیه سازی شده VMDK به عنوان Pointer یا اشاره گر هایی به فایل های اصلیِ موجود در Backup Repository عمل می نمایند.

از آن جایی که vPower NFS DataStore از یک طرف با vPower NFS Server و از طرف دیگر با ESXi در ارتباط است ، دقت داشته باشید که برای راه اندازی آن نیاز است که VMKernel با vPower NFS DataStore ارتباط مستقیم داشته باشد.

 

 

 

 

طراحی شده توسط 3DQuest.ir