بکاپ کامل، افزایشی و تفاضلی چه تفاوتی دارند؟
برای انتخاب روش بکاپ، فقط کوچکبودن فایل خروجی مهم نیست. باید بدانید نسخه هر روز چه چیزی را ذخیره میکند و برای برگشت به همان روز، کدام نسخههای قبلی هم لازماند. یک مثال چهارروزه این تفاوت را روشن میکند.
آخرین بازبینی متن:
در این صفحه
کامل یعنی همه اطلاعات سرور؟
کاملبودن نسبت به محدودهای است که برای بکاپ انتخاب کردهاید. Full یک پوشه، کل سیستمعامل و پایگاه داده شرکت را پوشش نمیدهد. پیش از مقایسه روشها باید معلوم باشد قرار است یک فایل، یک برنامه یا کل سرویس برگردد؛ اطلاعات بیرون از محدوده، صرفاً با انتخاب گزینه Full وارد بکاپ نمیشوند.
مقایسه این مقاله درباره ساختار پایه زنجیره است. ابزارها ممکن است تغییرات را در سطح فایل یا بلوکهای داده تشخیص دهند و شیوه نگهداری متفاوتی داشته باشند. بنابراین «فقط یک فایل را ویرایش کردیم» بهتنهایی حجم بکاپ بعدی را معلوم نمیکند.
هر روش چه چیزی نگه میدارد و برای بازیابی چه میخواهد؟
| روش | داده هر اجرا | اجزای لازم برای نقطه انتخابشده |
|---|---|---|
| Full؛ کامل | همه دادههای انتخابشده در همان اجرا. | بکاپ کامل مربوط به همان نقطه؛ از نظر زنجیره به Full قبلی وابسته نیست. |
| Incremental؛ افزایشی رو به جلو | تغییرات نسبت به بکاپ قبلی همان زنجیره. | Full مبنا و همه بخشهای افزایشی پس از آن تا نقطه انتخابشده. |
| Differential؛ تفاضلی | تغییرات نسبت به آخرین Full مبنا. | Full مبنا و بکاپ تفاضلیِ نقطه انتخابشده؛ تفاضلیهای میانی لازم نیستند. |
برای دیدن همه ستونها، جدول را به چپ یا راست بکشید؛ با کیبورد از کلیدهای جهت استفاده کنید.
این جدول تعداد فایل فیزیکی یا رسانه را تعیین نمیکند؛ یک نسخه ممکن است در چند بخش ذخیره شود. نرمافزار باید اجزای لازم را بشناسد و بخواند. دسترسی به ابزار، فهرست نسخهها و کلید رمزگذاریِ موردنیاز هم جدا از این وابستگی دادهای مطرح است.
مثال چهارروزه: شنبه تا سهشنبه
فرض کنید شنبه ۱۰۰ GB داده داریم. یکشنبه فقط ۱۰ GB فایل تازه، دوشنبه ۵ GB و سهشنبه ۸ GB فایل تازه اضافه میشود؛ فایلهای قبلی در این مثال تغییر یا حذف نمیشوند. هر شب یک بکاپ موفق داریم. فشردهسازی، حذف داده تکراری و سربار را برای سادگی حساب نمیکنیم و هر چهار نقطه را نگه میداریم.
| روز | Full هر شب | Full شنبه + افزایشی | Full شنبه + تفاضلی |
|---|---|---|---|
| شنبه | ۱۰۰ | ۱۰۰؛ مبنا | ۱۰۰؛ مبنا |
| یکشنبه | ۱۱۰ | ۱۰ | ۱۰ |
| دوشنبه | ۱۱۵ | ۵ | ۱۵ |
| سهشنبه | ۱۲۳ | ۸ | ۲۳ |
| جمع چهار اجرا | ۴۴۸ | ۱۲۳ | ۱۴۸ |
برای دیدن همه ستونها، جدول را به چپ یا راست بکشید؛ با کیبورد از کلیدهای جهت استفاده کنید.
برای برگشت به پایان سهشنبه، در روش اول Full سهشنبه با ۱۲۳ GB داده لازم است. در روش افزایشی، Full شنبه و بخشهای یکشنبه، دوشنبه و سهشنبه با هم لازماند: ۱۰۰ + ۱۰ + ۵ + ۸. در روش تفاضلی، Full شنبه و تفاضلی سهشنبه لازماند: ۱۰۰ + ۲۳؛ تفاضلی دوشنبه جزو این مسیر نیست.
۱۴۸ GB حجم مجموع نسخههای نگهداریشده تفاضلی در این مثال است، نه اندازه اطلاعات فعال شرکت که سهشنبه ۱۲۳ GB شده است. این اعداد برآورد فضای واقعی یک شرکت نیستند؛ با ویرایش مکرر همان فایلها، فشردهسازی، رشد متفاوت و سیاست نگهداری، نتیجه تغییر میکند.
اگر بکاپ دوشنبه خراب یا حذف شود چه میشود؟
در زنجیره افزایشی همین مثال، بخش سهشنبه فقط داده تازه همان روز را دارد. بدون بخش دوشنبه، مسیر کامل بازیابی سهشنبه ناقص است؛ داشتن آخرین بخش بهتنهایی کافی نیست. نسخههای پیش از قسمت خراب ممکن است همچنان قابل بازیابی باشند، پس خرابی یک بخش را هم نباید بدون بررسی به از دسترفتن همه نسخهها تعمیم داد.
در روش تفاضلی همین مثال، تفاضلی سهشنبه همه تغییرات از شنبه را دارد؛ از بینرفتن تفاضلی دوشنبه، این مسیر را قطع نمیکند. اما Full شنبه همچنان ضروری است. استقلال از نسخه میانی با استقلال از نسخه مبنا فرق دارد.
برای خالیکردن فضا، فایل بکاپ را صرفاً چون تاریخ قدیمی دارد از پوشه پاک نکنید. سیاست نگهداری ابزار باید وابستگی زنجیره را حفظ کند. در راهنمای زمانبندی و نگهداری بکاپ تفاوت تعداد نقاط بازیابی با تعداد روزهای تحت پوشش توضیح داده شده است.
کدام روش سریعتر و کمحجمتر است؟
وقتی تغییرات بین دو اجرا کماند، افزایشی معمولاً داده کمتری برای انتقال دارد. تفاضلی با انباشتهشدن تغییرات از مبنای کامل میتواند بزرگتر شود. Full در هر اجرا کل محدوده را دوباره پوشش میدهد؛ برای داده کمحجم ممکن است قابل قبول باشد، اما برای مجموعه بزرگ فشار انتقال و ذخیره بیشتری ایجاد میکند.
بازیابی افزایشی به خواندن اجزای بیشتری وابسته است، ولی از این نکته نمیتوان زمان قطعی یا نسبت سرعت ساخت. طراحی ابزار، محل نسخهها، سرعت ذخیرهساز و حجم داده مؤثرند. زمان گرفتن بکاپ با زمان برگرداندن و قابل استفادهشدن برنامه یکی نیست؛ هر دو باید متناسب با کار شرکت سنجیده شوند.
همچنین Full گرفتن به معنی محافظت بیشتر در برابر حذف مخرب نیست. اگر همه نسخهها با همان حساب قابل پاککردن باشند، روش زنجیره این مشکل را حل نمیکند. حفاظت از بکاپ در برابر حذف و باجافزار تصمیم جداگانهای است.
Synthetic Full و افزایشی دائمی کجای این مقایسهاند؟
Full لزوماً با خواندن دوباره همه داده از سرور اصلی ساخته نمیشود. برای نمونه، Veeam میتواند از Full موجود و بخشهای افزایشی در مخزن، یک Full تازه بسازد؛ این روش Synthetic Full نام دارد. در نتیجه فشار خواندن دوباره از منبع کمتر میشود، اما ساخت آن به داده سالم موجود و منابع مخزن وابسته است.
در روشهایی مانند Forever Forward Incremental نیز ابزار میتواند برای اجرای سیاست نگهداری، داده بخشی از زنجیره را در مبنا ادغام کند. پس مثال ثابت شنبه تا سهشنبه را نباید به ساختار همیشگی همه محصولات تعمیم داد. تشخیص نقاط قابل بازیابی و حذف نسخههای قدیمی باید از منطق همان ابزار پیروی کند.
برای شرکت کدام ترکیب را انتخاب کنیم؟
برای داده کمحجم و فرصتی که انتقال کامل را تحمل میکند، Full دورهای میتواند مدیریت سادهتری داشته باشد. برای حجم بیشتر و تغییرات محدود، افزایشی گزینه قابل بررسی است؛ باید سالمماندن زنجیره و زمان بازیابی کنترل شود. اگر ابزار از روش تفاضلی پشتیبانی کند، این روش وابستگی به نسخههای میانی را کمتر میکند، به بهای تکرار انتقال تغییرات از Full مبنا.
فاصله اجرا را نیاز به تازگی داده تعیین میکند، نه نام روش. هیچیک از این سه، تغییرات پس از آخرین نقطه موفق را خودکار برنمیگردانند. برای برنامه مالی نیز سازگاری روش با پایگاه داده و وابستگیهای برنامه مهم است؛ کپیکردن فایل باز بهتنهایی کافی نیست.
پیش از اتکا به برنامه، یک نقطه جدید و نسخه قدیمی موردنیاز را در آزمون بازیابی بکاپ بررسی کنید. محل نسخهها در راهنمای انتخاب مقصد بکاپ توضیح داده شده است. برای طراحی یا اصلاح همین برنامه، خدمات بکاپ نتمسترز قابل سفارش است.