ردیف ظرفیت (یا همانطور که ما آن را در داخل Vim - captir می نامیم) در روزهای پشتیبان گیری Veeam و Replication 9.5 به روز رسانی 4 با نام Archive Tier ظاهر شد. ایده پشت آن این است که امکان انتقال پشتیبان‌هایی که از پنجره به اصطلاح بازیابی عملیاتی خارج شده‌اند را به ذخیره‌سازی اشیا می‌دهد. این به پاکسازی فضای دیسک برای آن دسته از کاربرانی که فضای کمی داشتند کمک کرد. و این گزینه Move Mode نام داشت.

برای انجام این عمل ساده (همانطور که به نظر می رسد) کافی بود دو شرط را رعایت کنید: تمام نقاط از نسخه پشتیبان منتقل شده باید خارج از مرزهای پنجره بازیابی عملیاتی فوق الذکر باشد که به صراحت در UI تنظیم شده است. و دوم: زنجیره باید به اصطلاح "Sealed Form" (Saled Backup Chain یا Inactive Backup Chain) باشد. یعنی در طول زمان هیچ تغییری در این زنجیره رخ نمی دهد.

اما در VBR v10، این مفهوم با توابع جدید تکمیل شد - حالت کپی، حالت مهر و موم شده و چیزی با نام دشوار تلفظ Immutability ظاهر شد.

اینها چیزهای جذابی هستند که امروز درباره آنها صحبت خواهیم کرد. ابتدا در مورد نحوه عملکرد آن در VBR9.5u4 و سپس در مورد تغییرات نسخه دهم.

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

• بدون کوچکترین پشیمانی. نویسنده مقاله.

آن گونه که بود

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

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

بر این اساس، .vbk ایجاد شده در روز دوشنبه زنجیره قبلی را که پنجره آن روی سه روز تنظیم شده است، مهر و موم می کند. و این بدان معناست که می توانید با خیال راحت شروع به حمل هر چیزی که از این سه روز گذشته است به میدان تیراندازی کنید.

اما منظور از زنجیر مهر و موم شده دقیقاً چه بود و در آپدیت 4 چه چیزی می توانست به محدوده تیراندازی ظرفیت ارسال شود؟

Forward Incremental، نشانه ای از آب بندی زنجیره، ایجاد یک نسخه پشتیبان کامل جدید است. و مهم نیست که چگونه این پشتیبان کامل به دست می آید: هر دو نسخه پشتیبان کامل مصنوعی و فعال کامل در نظر گرفته می شوند.

در مورد Reverse، اینها همه فایل هایی هستند که در پنجره عملیاتی قرار نمی گیرند.

در مورد افزایش رو به جلو با عقب‌نشینی، اگر vbk دیگری در میزان عملکرد وجود داشته باشد، همه این‌ها برگشت‌ها و vbk. هستند.

حالا بیایید گزینه کار با زنجیره های Backup Copy را در نظر بگیریم. فقط مواردی که تحت نگهداری GFS قرار دارند به اینجا منتقل شدند. زیرا هر چیزی که در زنجیره های نسخه پشتیبان اخیر ذخیره شده است را می توان به یک روش تغییر داد.

حالا بیایید زیر کاپوت را نگاه کنیم. در آنجا، فرآیندی به نام کم آبی رخ می دهد - فایل های پشتیبان خالی باقی می مانند و بلوک ها از این فایل ها به محدوده تیراندازی با ظرفیت کشیده می شوند. برای بهینه سازی این فرآیند از شاخص کم آبی استفاده می شود که به شما امکان می دهد از کپی کردن بلوک هایی که قبلاً در محدوده تیراندازی ظرفیت کپی شده اند خودداری کنید.

بیایید ببینیم که با یک مثال چگونه به نظر می رسد: فرض کنید یک .vbk داریم که از پنجره تراکنش بیرون آمده و به یک زنجیره مهر و موم شده تعلق دارد. این به این معنی است که ما حق داریم آن را به محدوده تیراندازی با ظرفیت انتقال دهیم. در زمان جابجایی، یک فایل فراداده در خط تیره ظرفیت و بلوک های فایل منتقل شده ایجاد می شود. فایل فوق داده در سطح پیوند توضیح می دهد که فایل ما از چه بلوک هایی تشکیل شده است. در مورد تصویر، اولین فایل ما از بلوک های a، b، c تشکیل شده است و ابرداده حاوی پیوندهایی به این بلوک ها است. هنگامی که ما یک فایل .vbk دوم آماده انتقال و متشکل از بلوک های a، b و d داریم، با تجزیه و تحلیل شاخص کم آبی متوجه می شویم که فقط بلوک d باید منتقل شود. و فایل ابرداده آن حاوی پیوندهایی به دو بلوک قبلی و یک بلوک جدید خواهد بود.

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

در اینجا ممکن است به نظر برسد که این فناوری با فناوری مورد استفاده در شتاب دهنده های WAN یکسان است، اما فقط به نظر می رسد. در شتابدهنده ها، deduplication سراسری است؛ در اینجا، deduplication محلی در هر فایل با یک افست خاص استفاده می شود. این به دلیل تفاوت در وظایف در حال حل اتفاق می افتد: در اینجا ما باید فایل های پشتیبان کامل بزرگ را کپی کنیم و طبق تحقیقات ما، حتی اگر مدت زمان طولانی بین آنها بگذرد، این الگوریتم deduplication بهترین نتیجه را می دهد.

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

چگونه شد

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

حالت کپی

این تا حد زیادی بر اساس فن آوری های موجود است، اما منطق استفاده کاملا متفاوتی دارد. 

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

اگر حالت‌های Move و Copy را بطور مستقیم با هم مقایسه کنید، به این صورت خواهد بود:

• فقط زنجیر مهر و موم شده را می توان جابجا کرد. در حالت کپی، مطلقاً همه چیز منتقل می شود، صرف نظر از اینکه در کار پشتیبان گیری چه اتفاقی می افتد.
• وقتی فایل‌ها از مرزهای پنجره پشتیبان عملیاتی فراتر می‌روند، جابجایی فعال می‌شود و به محض ظاهر شدن فایل پشتیبان، کپی کردن فعال می‌شود.
• نظارت بر داده های جدید برای کپی به طور مداوم انجام می شود و برای جابجایی آن هر 4 ساعت یک بار فعال می شود.

در بررسی حالت جدید، من پیشنهاد می کنم از مثال های ساده به نمونه های پیچیده حرکت کنیم.

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

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

این سوال پیش می آید - اگر به UI نگاه کنید، فرصتی برای انتخاب هر دو گزینه به طور همزمان وجود دارد. چنین حالت ترکیبی چگونه کار خواهد کرد؟

بیایید آن را کشف کنیم

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

تمام این منطق جذاب تنها مسئول یک چک باکس در رابط است: پشتیبان‌گیری‌ها را به محض ایجاد در ذخیره‌سازی اشیا کپی کنید.

چرا به این حالت کپی نیاز داریم؟

حتی بهتر است این سوال را اینگونه بازنویسی کنیم: با کمک آن از چه خطراتی در امان هستیم؟ چه مشکلی به ما کمک می کند حل کنیم؟

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

بنابراین بیایید سناریوهای ممکن را از ساده ترین تا پیچیده تر بررسی کنیم.

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

داستان غم انگیزتر این است که یکی از گستره های مخزن SOBR ما شکست.

زمانی که کل مخزن SOBR غیرقابل دسترسی است، اما محدوده تیراندازی ظرفیت کار می کند، حتی بدتر می شود.
و همه چیز واقعاً بد است - این زمانی است که سرور پشتیبان از بین می رود و اولین آرزوی شما این است که سعی کنید ظرف ده دقیقه به مرز کانادا بروید.

حالا بیایید هر موقعیت را جداگانه بررسی کنیم.

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

اکنون شرایط پیچیده تر شده است. بیایید فرض کنیم که SOBR ما از دو وسعت در حال اجرا در حالت Performance تشکیل شده است، به این معنی که vbk. و .vib ما در یک لایه نسبتاً ناهموار روی آنها پخش شده اند. و در مقطعی از زمان، یکی از گستره ها از دسترس خارج می شود و کاربر نیاز فوری به بازیابی دستگاه دارد که بخشی از داده های آن دقیقاً در این محدوده قرار دارد.

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

یک نوع فرعی از این مورد این است که کل مخزن SOBR غیرقابل دسترسی شد. در این حالت، چیزی برای کپی کردن از حافظه محلی نداریم و همه بلوک ها از فضای ابری دانلود می شوند.

و جالب ترین وضعیت این است که سرور پشتیبان از بین رفت. در اینجا دو گزینه وجود دارد: ادمین عالی است و از تنظیمات نسخه پشتیبان تهیه می کند، و ادمین خود یک پینوکیو شیطانی است و از پیکربندی نسخه پشتیبان تهیه نمی کند.

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

اما اگر ادمین یا دشمن خودش باشد یا پشتیبان پیکربندی نیز با شکست حماسی روبرو شود، حتی در اینجا ما او را به رحمت سرنوشت رها نمی کنیم. برای این مورد، رویه جدیدی به نام Import Object Storage را معرفی کرده ایم. به شما این امکان را می دهد که از فرآیند بازسازی دستی یک مخزن SOBR و اتصال یک محدوده تیراندازی ظرفیت به آن با اسکن مجدد بعدی صرف نظر کنید و به سادگی یک شی ذخیره سازی را به رابط Vim اضافه کنید و رویه Import Storage Repository را اجرا کنید. تنها چیزی که می تواند مانع بین شما و پشتیبان های شما شود، درخواست برای وارد کردن رمز عبور در صورتی است که نسخه های پشتیبان شما رمزگذاری شده بودند.

احتمالاً همه چیز مربوط به حالت کپی است و ما به آن می رویم

حالت مهر و موم شده

ایده اصلی این است که نسخه‌های پشتیبان جدید نمی‌توانند در گستره SOBR انتخاب شده مخزن ظاهر شوند. قبل از نسخه 10، ما فقط حالت Maintenance Mode را داشتیم، زمانی که هرگونه کار با مخزن کاملاً ممنوع بود. نوعی حالت هاردکور برای خاموش کردن فضای ذخیره‌سازی، که در آن فقط دکمه Evacuate در دسترس است، که یک بار نسخه‌های پشتیبان را به میزان دیگری منتقل می‌کند.

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

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

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

به عنوان مثال، یک SOBR متشکل از دو وسعت را در نظر بگیرید. فرض کنید برای چهار روز اول در حالت Forward Forever Incremental پشتیبان‌گیری ایجاد کرده‌ایم و سپس وسعت را مهر و موم می‌کنیم. اگر احتباس ما چهار باشد، وقتی کل زنجیره واقع در وسعت مهر و موم شده از حد خود فراتر رود، با وجدان راحت حذف می شود.

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

همه چیز با Reverse Incremental ساده تر است. در آن، قدیمی ترین نقاط به هیچ چیز بستگی ندارد و می توان با خیال راحت حذف کرد. بنابراین، به محض ایجاد یک vbk. جدید در محدوده جدید، vrbs های قدیمی یکی یکی حذف می شوند.

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

همه چیز با محدوده تیراندازی با ظرفیت پیچیده تر است.

ابتدا بیایید حالت کپی را بررسی کنیم. بیایید فرض کنیم که ما به مدت چهار روز به طور فعال پشتیبان تهیه می کردیم و سپس محدوده تیراندازی ظرفیت بسته شد. ما چیزی را حذف نمی کنیم، اما با فروتنی حفظ را تحمل می کنیم، پس از آن داده ها را از محدوده تیراندازی ظرفیت حذف می کنیم.

تقریباً همین اتفاق در حالت حرکت می‌افتد - ما منتظر روتوش هستیم، نسخه قدیمی را در حافظه محلی حذف می‌کنیم و موردی را که در ذخیره‌سازی اشیاء ذخیره شده است حذف می‌کنیم.

یک مثال جالب با Forever Forever incremental. ما Retain را در سه نقطه نصب می کنیم و از دوشنبه شروع به تهیه نسخه پشتیبان می کنیم که به طور مرتب در فضای ابری کپی می شود. پس از مهر و موم شدن فضای ذخیره سازی، پشتیبان گیری با حفظ سه نقطه ادامه می یابد، اما داده های ذخیره شده در خط تیره ظرفیت وابسته باقی می مانند و نمی توان آنها را حذف کرد. بنابراین، ما تا پنجشنبه صبر می کنیم، زمانی که vbk. ما از حفظ فراتر می رود و تنها پس از آن ما با آرامش کل زنجیره ذخیره شده را حذف می کنیم.

و یک سلب مسئولیت کوچک: همه نمونه ها در اینجا با یک ماشین نشان داده شده اند. اگر چندین مورد از آنها را در نسخه پشتیبان خود داشته باشید، بسته به اینکه Active Full ساخته شده باشد یا نه، روتوش آنها متفاوت خواهد بود.

این اساساً تمام چیزی است که در آن وجود دارد. پس بیایید به سخت‌ترین ویژگی برویم -

تغییرناپذیری

همانند نکات قبلی، اولین نکته این است که این تابع چه مشکلی را حل می کند. به محض اینکه نسخه‌های پشتیبان خود را در جایی برای ذخیره‌سازی آپلود می‌کنیم، میل شدیدی برای تضمین ایمنی آن‌ها وجود دارد، یعنی حذف فیزیکی آنها و هرگونه تغییر در طول یک نگهداری معین ممنوع شود. از جمله ادمین ها، از جمله زیر حساب های ریشه آنها. این به شما امکان می دهد از آنها در برابر آسیب های تصادفی یا عمدی محافظت کنید. هر کسی که با AWS کار می کند ممکن است با ویژگی مشابهی به نام Object Lock مواجه شده باشد.

حالا بیایید حالت را به طور کلی بررسی کنیم و سپس به جزئیات بپردازیم. در مثال ما، Immutability برای محدوده تیراندازی ظرفیت ما با حفظ چهار روز فعال می شود. و حالت کپی در پشتیبان گیری فعال است.

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

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

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

بیایید یک مقیاس زمانی شش روزه در نظر بگیریم و در زیر زمان انقضای مورد انتظار تغییرناپذیری را مشخص کنیم. در روز اول فایلی متشکل از بلوک داده a و ابرداده آن را می گیریم و ایجاد می کنیم. اگر تغییر ناپذیری روی سه روز تنظیم شود، منطقی است که فرض کنیم در روز چهارم داده ها باز و حذف می شوند. در روز دوم یک file2 جدید، متشکل از بلوک b با همان تنظیمات اضافه می کنیم. بلاک a هنوز باید در روز چهارم حذف شود. اما در روز سوم اتفاق وحشتناکی رخ می دهد - یک فایل File3 ایجاد می شود که شامل یک بلوک جدید d و یک پیوند به بلوک قدیمی a است. این بدان معنی است که برای یک بلوک و پرچم تغییرناپذیری آن باید به تاریخ جدیدی بازنشانی شود که به روز ششم منتقل می شود. و در اینجا یک مشکل ایجاد می شود - در پشتیبان گیری واقعی تعداد زیادی از این بلوک ها وجود دارد. و برای تمدید دوره تغییر ناپذیری آنها، باید هر بار تعداد زیادی درخواست انجام دهید. و در واقع، این یک فرآیند تقریباً بی پایان روزانه خواهد بود، زیرا با درجه احتمال بالا، ما با هر کپی پشته های سنگینی از بلوک های کپی شده پیدا خواهیم کرد. تعداد زیادی درخواست از ارائه دهندگان ذخیره سازی اشیا به چه معناست؟ درست! صورت حساب هنگفت در پایان ماه.

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

بیایید همچنان همین وضعیت را در نظر بگیریم، اما با تولید بلوک. در روز اول فایل 1 را از بلوک a و ابرداده ایجاد می کنیم. ما دوره تولید و تغییر ناپذیری را اضافه می کنیم - این بدان معنی است که فرصت حذف فایل در روز ششم خواهد بود. اگر در روز دوم File2 را ایجاد کنیم که شامل بلوک b و پیوندی برای بلوک a است، در تاریخ حذف مورد انتظار هیچ اتفاقی نمی‌افتد. مثل روز ششم ایستاد. و بنابراین ما سعی می کنیم در تعداد درخواست ها صرفه جویی کنیم. تنها حالتی که می توان مهلت را تغییر داد، این است که دوره تولید منقضی شده باشد. یعنی اگر در روز سوم File3 جدید حاوی پیوندی برای مسدود کردن a باشد، نسل 2 اضافه خواهد شد زیرا Gen1 قبلاً منقضی شده است. و تاریخ مورد انتظار برای حذف بلوک a به روز هشتم منتقل می شود. این به ما امکان می‌دهد تا تعداد درخواست‌ها را به‌طور چشمگیری کاهش دهیم تا طول عمر بلوک‌های حذف‌شده را افزایش دهیم، که باعث صرفه‌جویی در هزینه‌های مشتریان می‌شود.

این فناوری به خودی خود در دسترس کاربران سخت افزارهای سازگار با S3 و S3 است که سازندگان آن تضمین می کنند که اجرای آنها با آمازون تفاوتی ندارد. از این رو پاسخ به این سؤال قانونی است که چرا Azure پشتیبانی نمی شود - آنها ویژگی مشابهی دارند، اما در سطح کانتینرها کار می کند، نه اشیاء منفرد. به هر حال، آمازون خود دارای قفل شی در دو حالت است: انطباق و حاکمیت. در حالت دوم، این احتمال وجود دارد که بزرگترین ادمین بالای ادمین ها و روت بالای ریشه ها، با وجود قفل شی، همچنان داده ها را حذف کند. در مورد انطباق، همه چیز محکم میخکوب شده است و هیچ کس نمی تواند پشتیبان ها را حذف کند. حتی مدیران آمازون (طبق اظهارات رسمی آنها). این حالتی است که ما پشتیبانی می کنیم.

و طبق معمول چند لینک مفید:

• بر بلوک نسل در تمام جزئیات
• تمام اطلاعات در مورد Veeam Backup & Replication 10 در بهترین حالت
• О ردیف ظرفیت به تفصیل

منبع: www.habr.com