Reverse Incremental Backup در Veeam Backup and Replication
یکی از انواع متودهای بکاپ در نرم افزار Veeam Backup and Replication نوع Reverse Incremental Backup است. همان طور که می دانید کلمه Reverse به معنای معکوس یا بازگشتی می باشد.
Reverse Incremental Backup در Veeam Backup and Replication
در تعریف ساده ، یک زنجیره بکاپ در این متود شامل یک فایل با پسوند VBK است که آخرین Full Backup تهیه شده می باشد و همچنین تعدادی فایل های بازگشتی با پسوند VRB که متعلق به بکاپ های قبل از فایل VBK هستند. تعداد فایل های VRB را Retention Policy شما تعیین می نماید. اگرچه گاهی ممکن است به دلیل وجود برخی مشکلات در زیرساخت شبکه سازمان شما ، مانند دلایلی که در KB شماره ۱۹۹۰ شرکت Veeam ذکر شده است.
تعداد این فایل ها بیش تر از تعداد تعیین شده در Retention Policy باشد!
البته لازم به ذکر است چنین مشکلی در این متود از بکاپ نادر است و این ایراد بیش تر در Traditional Forward Incremental دیده می شود. برای اطلاعات بیشتر درباره سایر متود های بکاپ به این مقاله مراجعه نمایید.
اما باز گردیم به Reverse Incremental Backup و در ابتدا نگاهی داشته باشیم که در این نوع از بکاپ دقیقا چه اتفاقی می افتد و چرا Recovery در آن به آخرین Full Backup سریع است؟
۱ – در طول اولین جاب بکاپ ، نرم افزار یک Full Backup در Repository شما ایجاد می کند.
۲ – در Job های بعدی تنها دیتا بلاک هایی از ماشین مجازی که از لحظه ایجاد Full Backup تغییر کرده اند پشتیبان گرفته می شوند. سپس در این فایل به Full Backup موجود تزریق می شود تا Full Backup به روزترین فایل پشتیبان موجود باشد. اما در اینجا Data Block هایی که به جای آن ها تغییرات جدید جایگزین شده است ، دور ریخته نمی شوند !!! بلکه به صورت یک فایل دیگر قبل از فایل فول بکاپ ذخیره می شوند! بنابراین علاوه بر اینکه در هز زمان بازگشت به آخرین Full Backup ممکن خواهد بود ، امکان ایجاد دوباره یک Restore Point شامل دیتا بلاک هایی که از فایل اصلی حذف شده اند نیز وجود خواهد داشت!
۳ – در آخرین مرحله Retention Policy بررسی می گردد و در صورت نیاز قدیمی ترین فایل Reverse حذف می گردد.
در تصویر زیر این زنجیره نمایش داده شده است :
همچنین جهت استفاده از این متود بکاپ ، کافی ست که پنجره Advnaced در مرحله Storage ایجاد Backup Job مانند تصویر زیر باشد :
جهت مطالعه بیشتر درباره اصول کلی ایجاد Backup Job در Veeam Backup and Replication می توانید به این مقاله مراجعه نمایید.
بسمه تعالی
باسلام و احترام،
جناب مهندس، این روش بکاپ رو از بقیه شما بهتر میدونید؟سرعت بازیابی بالاتر، در به روز بودن فول بکاپ، مشکل حجم گرفتن یک فول بکاپ کامل مثل روش incrementa رو هم نداریم(تا بکاپ فول گرفته نشه قبلی پاک نمیشه و این خودش مشکل بزرگیه) عیب این روش پس چیست؟ من تازه بکاپ سرور جدید اوردم بالا و میخوام کلا همه رو رو همین مدل قرار بدم.
سلام.
عیب این روش در این هست که اگرچه سرعت بازیابی بالاتری داره ، اما سرعت بکاپ گیری پایین تر هست. به خصوص در سازمان هایی که با کمبود منابع مانند CPU ، RAM و یا کندی سرعت دستگاه های ذخیره سازی روبه رو هستیم ، چه در مورد وییم سرور و چه در مورد ماشین های مجازی که ازشون بکاپ می گیریم ، با کاهش Performance زیاد و طولانی تری در زمان پشتیبان گیری رو به رو خواهید شد.
سوال
من با نرم افزار Veeam Endpoint Backup از یکی از سرورهام بکاب گرفتم
الان بخوام این بکاب رو به یک ماشین مجازی برگردونم
چکار باید کنم مرسی
ببخشید من یه مثال میزنم ببینید من مکانیزم رو درست متوجه شدم؟ اول یک فول بک اپ میگیره که فرض میکنیم دیتای آن به شرح زیر است : ” سلام ” بعد دفعه دوم میاد ببینه آیا تغییری کرده یا نه این فول بک اپ مثلا فرض میکنیم دیتا به شکل زیر تغییر کرده : ” سلام خوبی ” میاد فقط دیتای ” خوبی ” رو بک آپ گرفته و به فول بک آپ اولیه اضافه میکنه و فول بک اپ ما به شکل زیر تغییر میکنه ” سلام خوبی ” بعد فایلی که نگه میداره رو به شکل ”… بیشتر»
خیر ، مکانیزم به این صورت نیست. در واقع مثال شما ، مثال خوبی نیست. چون در اینجا بحث تغییرات فایل ها هم مطرح است. در مثالی که شما فرمودید تنها یک کلمه به جمله اضافه شده است. اما در محیط واقعی در بیشتر مواقع علاوه بر افزوده شدن یک بخش جدید به دیتای قبلی ، برخی از اطلاعات قبلی نیز ویرایش می شوند. برای مثال فرض کنید شما دیتای AA را ایجاد کرده اید و یک فول بکاپ از آن تهیه می شود. در زمانی که Job بعدی قرار است اجرا شود ، دیتای AA ممکن است به ABC… بیشتر»
متوجه شدم پس فایل های VRB درواقع دیتا بلاک هایی هستند که تغییر کردند یا حذف شده اند. در این صورت اگر ما بخوایم به جای بازگشت به آخرین وضعیت به روز سرور که همن فول بک اپ هست به یکی از وضعیت های موجود در VRBها برگردیم ابتدا VRB های قبلی رو از نظر تغییرات به صورت بازگشتی جایگزین میکنه تا برسه به VRB ما…سپس اون رو به صورت بازگشتی جایگزین دیتا بلاکی که به جاش نشسته بود میکنه و در این صورت ما به وضعیتی که در VRB به لحاظ کل دیتا بلاک مورد نظر داشتیم برمیگردیم. یعنی… بیشتر»
بله. درسته
سلام در مقاله مربوط به Forever Forward در bitjoo با ترسیم عکس های خود سایت veeamگفته شد که اگر به فرض Retention Policy روی ۷ تنظیم شود veeam نهایتا ۶ عدد فایل vib یا همون incبه همراه یک فول که اول گرفته شده را نکه میداره و inc بعدی باعث میشه اولین inc در فول ادغام شود..یعنی در واقع Retention Policy اون یک عدد فول رو هم حساب میکنه. و با اون ۷ تا در نظر میگیره. ولی اینجا در اول مقاله نوشته شده که تعداد فایل های VRB را Retention Policy شما تعیین می نماید که اشتباه هست. در… بیشتر»
با سلام. گفته شده است تعداد فایل های VRB را Retention Policy تعریف می کند. اما گفته نشده است که فایل ها برابر با عدد Retention Policy هستند !!! بنابراین تمام جملات این مقاله کاملا درست است.
به علت مکانیزمی که در این نوع بکاپ وجود دارد Load بیشتری بر روی دستگاه های ذخیره ساز مربوط به بکاپ (Backup Repository)اعمال می شود(به علت read و write بیشتر ) که باید حتما در نظر گرفته شود.
ممنون از توجه شما. بله کاملا حق با شماست. بار IOPS این نوع بکاپ سه برابر حالت عادی است و باید به Performance دستگاه ذخیره سازی توجه شود.