Reverse Incremental Backup در Veeam Backup and Replication

8

یکی از انواع متودهای بکاپ در نرم افزار 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 می توانید به این مقاله مراجعه نمایید.

مطالب مرتبط
8 نظرات
  1. Alireza می گوید

    به علت مکانیزمی که در این نوع بکاپ وجود دارد Load بیشتری بر روی دستگاه های ذخیره ساز مربوط به بکاپ (Backup Repository)اعمال می شود(به علت read و write بیشتر ) که باید حتما در نظر گرفته شود.

    1. نوید داریا می گوید

      ممنون از توجه شما. بله کاملا حق با شماست. بار IOPS این نوع بکاپ سه برابر حالت عادی است و باید به Performance دستگاه ذخیره سازی توجه شود.

  2. علی می گوید

    سلام در مقاله مربوط به Forever Forward در bitjoo با ترسیم عکس های خود سایت veeam‌گفته شد که اگر به فرض Retention Policy روی ۷ تنظیم شود veeam نهایتا ۶ عدد فایل vib یا همون inc‌به همراه یک فول که اول گرفته شده را نکه میداره و inc بعدی باعث میشه اولین inc‌ در فول ادغام شود..یعنی در واقع Retention Policy اون یک عدد فول رو هم حساب میکنه. و با اون ۷ تا در نظر میگیره.
    ولی اینجا در اول مقاله نوشته شده که تعداد فایل های VRB را Retention Policy شما تعیین می نماید که اشتباه هست. در این متد هم مثل متد Forever فول رو هم جزء Retention Policy حساب میکنه .

    1. نوید داریا می گوید

      با سلام. گفته شده است تعداد فایل های VRB را Retention Policy تعریف می کند. اما گفته نشده است که فایل ها برابر با عدد Retention Policy هستند !!! بنابراین تمام جملات این مقاله کاملا درست است.

  3. محبوبی می گوید

    ببخشید من یه مثال میزنم ببینید من مکانیزم رو درست متوجه شدم؟

    اول یک فول بک اپ میگیره که فرض میکنیم دیتای آن به شرح زیر است : ” سلام ”
    بعد دفعه دوم میاد ببینه آیا تغییری کرده یا نه این فول بک اپ مثلا فرض میکنیم دیتا به شکل زیر تغییر کرده : ” سلام خوبی ” میاد فقط دیتای ” خوبی ” رو بک آپ گرفته و به فول بک آپ اولیه اضافه میکنه و فول بک اپ ما به شکل زیر تغییر میکنه ” سلام خوبی ” بعد فایلی که نگه میداره رو به شکل ” سلام ” ذخیره میکنه قبل فایل فول بک آپ.
    آیا درست فهمیدم؟
    اینجوری به نظر میرسه حجم فایل های بک آپ در این روش بالاتر از روش forever و forward inc هست. درسته؟

    1. نوید داریا می گوید

      خیر ، مکانیزم به این صورت نیست. در واقع مثال شما ، مثال خوبی نیست. چون در اینجا بحث تغییرات فایل ها هم مطرح است. در مثالی که شما فرمودید تنها یک کلمه به جمله اضافه شده است. اما در محیط واقعی در بیشتر مواقع علاوه بر افزوده شدن یک بخش جدید به دیتای قبلی ، برخی از اطلاعات قبلی نیز ویرایش می شوند.
      برای مثال فرض کنید شما دیتای AA را ایجاد کرده اید و یک فول بکاپ از آن تهیه می شود. در زمانی که Job بعدی قرار است اجرا شود ، دیتای AA ممکن است به ABC تغییر کرده باشد. در اینجا نخستین حرف A از سمت چپ با بکاپ قبلی مطابقت دارد. بنابراین Job در حال اجرا آن را نادیده می گیرد. تغییرات ایجاد شده نسبت به زمان اجرای Job اول حروف BC هستند. جاب در حال اجرا آن ها را در فایل فول بکاپ تزریق می کند و سپس دومین حرف A را که اکنون از دیتای AA به ABC تغییر کرده است به عنوان فایل VRB ذخیره می کند. به همین دلیل هم است که حجم این فایل بسیار کم است. چون تنها حرف A در آن ذخیره شده است. ( در این مثال )
      جهت مشاهده انیمیشنی از این نوع بکاپ به این لینک مراجعه کنید.

      1. محبوبی می گوید

        متوجه شدم پس فایل های VRB درواقع دیتا بلاک هایی هستند که تغییر کردند یا حذف شده اند. در این صورت اگر ما بخوایم به جای بازگشت به آخرین وضعیت به روز سرور که همن فول بک اپ هست به یکی از وضعیت های موجود در VRB‌ها برگردیم ابتدا VRB های قبلی رو از نظر تغییرات به صورت بازگشتی جایگزین میکنه تا برسه به VRB ما…سپس اون رو به صورت بازگشتی جایگزین دیتا بلاکی که به جاش نشسته بود میکنه و در این صورت ما به وضعیتی که در VRB به لحاظ کل دیتا بلاک مورد نظر داشتیم برمیگردیم.
        یعنی در مثال شما اگر موقع RESTORE کردن بگیم به وضعیت VRB – > A برگرد میاد A رو جایگزین ‌BC میکنه و به ما AA‌اولیه رو تحویل میده.

        1. نوید داریا می گوید

          بله. درسته

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.