Capacity Tier (və ya biz bunu Vim daxilində adlandırdığımız kimi - captir) Veeam Backup və Replication 9.5 Update 4 günlərində Arxiv Tier adı altında ortaya çıxdı. Bunun arxasında duran fikir, əməliyyat bərpa pəncərəsi adlanan pəncərədən düşmüş ehtiyat nüsxələrini obyekt saxlanmasına köçürməyi mümkün etməkdir. Bu, az olan istifadəçilər üçün disk yerini boşaltmağa kömək etdi. Və bu seçim Move Mode adlanırdı.

Bu sadə (göründüyü kimi) hərəkəti yerinə yetirmək üçün iki şərti yerinə yetirmək kifayət idi: köçürülmüş ehtiyat nüsxəsinin bütün nöqtələri UI-də açıq şəkildə qurulmuş yuxarıda qeyd olunan əməliyyat bərpa pəncərəsinin hüdudlarından kənarda olmalıdır. İkincisi: zəncir "möhürlənmiş formada" (möhürlənmiş ehtiyat zəncir və ya qeyri-aktiv ehtiyat zəncirində) olmalıdır. Yəni zamanla bu zəncirdə heç bir dəyişiklik baş vermir.

Lakin VBR v10-da konsepsiya yeni funksiyalarla tamamlandı - Kopyalama rejimi, Möhürlənmiş rejim və tələffüz edilməsi çətin olan Dəyişməzlik adlı bir şey ortaya çıxdı.

Bunlar bu gün danışacağımız maraqlı şeylərdir. Əvvəlcə VBR9.5u4-də necə işlədiyi, sonra onuncu versiyadakı dəyişikliklər haqqında.

Təmiz dilin çempionları məni bağışlasın, amma tərcüməsi mümkün olmayan çoxlu terminlər var.
Beləliklə, burada bir ton ingilisizm olacaq.
Və çoxlu giflər.
Və şəkillər.

• Ən kiçik bir təəssüf hissi olmadan. Məqalənin müəllifi.

Olduğu kimi

Yaxşı, əməliyyat bərpa pəncərəsini və möhürlənmiş ehtiyat nüsxəsini təhlil etməklə başlayaq (və ya onlar Qeyri-aktiv ehtiyat zəncirinin sənədlərində deyildiyi kimi). Onların anlayışı olmadan əlavə izahat mümkün olmayacaq.

Şəkildə gördüyümüz kimi, məlumat blokları olan bir növ ehtiyat zəncirimiz var, o, Tutum səviyyəsinin qoşulduğu deponun Performans səviyyəsi SOBR-də yerləşir. Əməliyyat ehtiyat pəncərəmiz üç gündür.

Müvafiq olaraq, bazar ertəsi yaradılmış .vbk pəncərəsi üç günə təyin edilmiş əvvəlki zənciri möhürləyir. Və bu o deməkdir ki, siz bu üç gündən daha köhnə olan hər şeyi təhlükəsiz şəkildə atış poliqonuna daşımağa başlaya bilərsiniz.

Bəs möhürlənmiş zəncir tam olaraq nə demək idi və 4-cü yeniləmədə tutumlu atış poliqonuna nə göndərilə bilər?

Forward Incremental, zəncirin möhürlənməsinin əlaməti yeni tam ehtiyat nüsxəsinin yaradılmasıdır. Və bu tam ehtiyat nüsxəsinin necə əldə edildiyinin əhəmiyyəti yoxdur: həm sintetik tam, həm də aktiv tam ehtiyat nüsxələri nəzərə alınır.

Əks halda, bunlar əməliyyat pəncərəsinə düşməyən bütün fayllardır.

Geri çəkilmə ilə İrəli artım vəziyyətində, bunların hamısı geri çəkilmə və .vbk, əgər performans səviyyəsində başqa .vbk varsa.

İndi Backup Copy zəncirləri ilə işləmə variantını nəzərdən keçirək. Burada yalnız GFS saxlama altına düşən əşyalar daşınırdı. Çünki daha yeni ehtiyat nüsxə zəncirlərində saxlanılan hər şey bu və ya digər şəkildə dəyişdirilə bilər.

İndi başlıq altına baxaq. Orada susuzlaşdırma adlı bir proses baş verir - miqyasda boş ehtiyat faylları buraxaraq və blokları bu fayllardan tutumlu çəkiliş diapazonuna sürükləyirlər. Bu prosesi optimallaşdırmaq üçün, artıq tutumlu çəkiliş diapazonuna kopyalanmış blokların kopyalanmasının qarşısını almağa imkan verən susuzlaşdırma indeksi istifadə olunur.

Nümunə ilə bunun necə göründüyünü görək: Tutaq ki, bizdə əməliyyat pəncərəsindən çıxan və möhürlənmiş zəncirə aid olan .vbk var. Bu o deməkdir ki, bizim onu ​​tutumlu atıcılıq poliqonuna keçirməyə tam hüququmuz var. Köçürmə zamanı ötürülən faylın tutum tire və bloklarında metadata faylı yaradılır. Link səviyyəli metadata faylı faylımızın hansı bloklardan ibarət olduğunu təsvir edir. Şəkildəki halda, birinci faylımız a, b, c bloklarından ibarətdir və metadata bu bloklara keçidləri ehtiva edir. Hərəkət etməyə hazır olan və a, b və d bloklarından ibarət ikinci .vbk faylımız olduqda, dehidrasiya indeksini təhlil edərək, yalnız d blokunun köçürülməsi lazım olduğunu başa düşürük. Və onun metadata faylında iki əvvəlki bloka və bir yeni bloka keçidlər olacaq.

Müvafiq olaraq, bu boş yerlərin yenidən məlumatlarla doldurulması prosesi rehidratasiya adlanır. O, artıq yerli performans dərəcəsi üzrə ən köhnə .vbk faylına əsaslanan öz rehidrasiya indeksindən istifadə edir. Yəni istifadəçi tutumlu çəkiliş diapazonundan faylı qaytarmaq istəsə, biz ilk növbədə ən köhnə tam ehtiyat nüsxəsinin bloklarının indeksini yaradırıq və tutumlu çəkiliş qalereyasından yalnız çatışmayan blokları köçürürük. Şəkildə təqdim olunan halda, FullBackup1.vbk-ni rehidrasiya indeksinə uyğun olaraq rehidratlaşdırmaq üçün bizə yalnız tutumlu atış məsafəsindən aldığımız C bloku lazımdır. Saxlama bulud obyekti tutumlu atış poliqonu kimi xidmət edirsə, bu, böyük miqdarda pula qənaət etməyə imkan verir.

Burada belə görünə bilər ki, bu texnologiya WAN Sürətləndiricilərində istifadə olunan texnologiya ilə eynidir, ancaq belə görünür. Sürətləndiricilərdə təkmilləşdirmə qlobaldır; burada yerli təkmilləşdirmə hər bir fayl daxilində müəyyən bir ofsetdə istifadə olunur. Bu, həll olunan vəzifələrin fərqliliyinə görə baş verir: burada biz böyük tam ehtiyat faylları kopyalamalıyıq və araşdırmalarımıza görə, hətta onların arasında uzun müddət keçsə belə, bu təkmilləşdirmə alqoritmi ən yaxşı nəticəni verir.

Ancaq indekslər tanrısı üçün daha çox indeks! Məlumatların bərpası üçün bir indeks də var! Tutum tiresində yerləşən maşını bərpa etməyə başladıqda, biz yalnız performans tiresində olmayan unikal məlumat bloklarını oxuyacağıq.

Bu necə oldu?

Giriş hissəsi üçün hamısı budur. Bu kifayət qədər təfərrüatlıdır, lakin yuxarıda qeyd edildiyi kimi, bu detallar olmadan yeni funksiyaların necə işlədiyini izah etmək mümkün olmayacaq. Buna görə də uzatmadan birinciyə keçək.

Kopyalama rejimi

O, əsasən mövcud texnologiyalara əsaslanır, lakin tamamilə fərqli istifadə məntiqi daşıyır. 

Bu rejimin məqsədi yerli səviyyədə yerləşən bütün məlumatların tutum tiresində bir nüsxəsinin olmasını təmin etməkdir.

Köçürmə və Kopyalama rejimlərini birbaşa müqayisə etsəniz, bu belə görünəcək:

• Yalnız möhürlənmiş zəncir köçürülə bilər. Kopyalama rejimi vəziyyətində, ehtiyat işində nə baş verməsindən asılı olmayaraq, tamamilə hər şey köçürülür.
• Köçürmə, fayllar əməliyyat ehtiyat nüsxəsi pəncərəsinin hüdudlarından kənara çıxdıqda, kopyalama isə ehtiyat fayl görünən kimi işə salınır.
• Kopyalama üçün yeni məlumatların monitorinqi daim baş verir və köçürülməsi üçün hər 4 saatda bir dəfə işə salındı.

Yeni rejimi nəzərdən keçirərkən sadə nümunələrdən mürəkkəb nümunələrə keçməyi təklif edirəm.

Ən çox görülən halda, sadəcə olaraq artımlarla yeni fayllarımız var və biz onları sadəcə tutumlu çəkiliş diapazonuna köçürürük. Ehtiyat işində hansı rejimdən istifadə olunmasından asılı olmayaraq, zəncirin möhürlənmiş hissəsinə aid olub-olmamasından asılı olmayaraq, əməliyyat pəncərəmizin müddətinin bitib-keçməməsindən asılı olmayaraq. Sadəcə götürüb köçürdülər.

Bunun arxasındakı proses yuxarıda göstərildiyi kimi hələ də susuzlaşdırmadır. Kopyalama rejimində o, artıq yaddaşımızda olan blokları kopyalamamağımızı da təmin edir. Yeganə fərq ondadır ki, film rejimində real faylları dummy fayllarla əvəz etmişiksə, burada onlara heç bir şəkildə toxunmuruq və hər şeyi olduğu kimi buraxırıq. Əks təqdirdə, pulunuzu və vaxtınızı diqqətlə saxlamağa çalışan tamamilə eyni susuzlaşdırma indeksidir.

Sual yaranır - UI-yə baxsanız, eyni anda hər iki variantı seçmək imkanı var. Belə birləşdirilmiş rejim necə işləyəcək?

Anlayaq.

Başlanğıc standartdır: ehtiyat faylı yaradılır və dərhal kopyalanır. Ona artım yaradılır və həmçinin kopyalanır. Bu, faylların əməliyyat pəncərəmizi tərk etdiyini və möhürlənmiş bir zəncir meydana gəldiyini anlayana qədər baş verir. Bu nöqtədə biz susuzlaşdırma əməliyyatı həyata keçiririk və bu faylları dummy fayllarla əvəz edirik. Əlbəttə ki, tutumlu çəkiliş poliqonuna bir daha heç nə köçürmürük.

Bütün bu füsunkar məntiq interfeysdə yalnız bir qeyd qutusuna cavabdehdir: ehtiyat nüsxələri yaradılan kimi obyekt yaddaşına köçürün.

Bu Kopyalama rejimi bizə nə üçün lazımdır?

Sualı belə ifadə etmək daha yaxşıdır: onun köməyi ilə hansı risklərdən qorunuruq? Bu, bizə hansı problemi həll etməyə kömək edir?

Cavab aydındır: əlbəttə ki, bu məlumatların bərpasıdır. Obyekt saxlama yerində yerli məlumatların tam nüsxəsi varsa, məhsulumuza nə baş verməsindən asılı olmayaraq, biz həmişə şərti Amazonda yerləşən fayllardan məlumatları bərpa edə bilərik.

Beləliklə, ən sadədən daha mürəkkəbə qədər mümkün ssenariləri nəzərdən keçirək.

Başımıza düşə biləcək ən sadə bədbəxtlik ehtiyat zəncirindəki fayllardan birinin əlçatmazlığıdır.

Daha acınacaqlı bir hekayə, SOBR anbarımızın bir hissəsinin qırılmasıdır.

Bütün SOBR anbarı əlçatmaz olduqda daha da pisləşir, lakin tutumlu atış məsafəsi işləyir.
Və hər şey həqiqətən pisdir - bu, ehtiyat serverin öldüyü zamandır və ilk istəyiniz on dəqiqə ərzində Kanada sərhədinə qaçmağa çalışmaqdır.

İndi hər bir vəziyyətə ayrıca baxaq.

Bir (və hətta bir neçə) ehtiyat nüsxə faylını itirdiyimiz zaman, bizə lazım olan yeganə şey repozitoriyanın yenidən axtarışı prosesinə başlamaqdır və itirilmiş fayl dummy fayl ilə əvəz olunacaq. Və rehidrasiya prosesindən istifadə edərək (məqalənin əvvəlində müzakirə olundu), istifadəçi tutumlu çəkiliş diapazonundan məlumatları yerli yaddaşa endirə biləcək.

İndi vəziyyət daha mürəkkəbdir. Fərz edək ki, SOBR-imiz Performans rejimində işləyən iki ekstentdən ibarətdir, bu o deməkdir ki, bizim .vbk və .vib onların üzərində kifayət qədər qeyri-bərabər təbəqədə yayılmışdır. Və zamanın bir nöqtəsində, ekstensiyalardan biri əlçatmaz olur və istifadəçi təcili olaraq məlumatlarının bir hissəsi məhz bu dərəcədə yatan maşını bərpa etməlidir.

İstifadəçi bərpa sehrbazını işə salır, bərpa etmək istədiyi nöqtəni seçir və sehrbaz işləyərkən yerli olaraq bərpa etmək üçün lazım olan bütün məlumatlara malik olmadığını və buna görə də tutum çəkilişindən endirilməsi lazım olduğunu başa düşür. qalereya. Eyni zamanda, yerli yaddaşda qalan bloklar buluddan endirilməyəcək. Bərpa indeksinə şöhrət (bəli, məqalənin əvvəlində də qeyd olundu).

Bu işin alt növü bütün SOBR deposunun əlçatmaz olmasıdır. Bu halda, yerli yaddaşdan kopyalamaq üçün heç bir şeyimiz yoxdur və bütün bloklar buluddan endirilir.

Və ən maraqlı vəziyyət ehtiyat serverin ölməsidir. Burada iki seçim var: admin əladır və konfiqurasiya ehtiyat nüsxələrini düzəldir, admin isə pis Pinokkionun özüdür və konfiqurasiya ehtiyat nüsxələrini etməyib.

Birinci halda, onun üçün sadəcə olaraq VBR-nin təmiz quraşdırılmasını haradasa yerləşdirmək və standart vasitələrdən istifadə edərək verilənlər bazasını ehtiyat nüsxədən bərpa etmək kifayətdir. Bu prosesin sonunda hər şey normala dönəcək. Və ya yuxarıdakı ssenarilərdən birinə uyğun olaraq bərpa ediləcək.

Ancaq admin ya öz düşmənidirsə və ya konfiqurasiya ehtiyat nüsxəsi də epik bir uğursuzluqla üzləşibsə, burada da onu taleyin mərhəmətinə buraxmayacağıq. Bu halda biz Import Object Storage adlı yeni prosedur təqdim etdik. O, sizə SOBR repozitoriyasını əl ilə yenidən yaratmaq və sonrakı təkrar tarama ilə ona tutumlu çəkiliş diapazonunu əlavə etmək prosesini atlamağa və sadəcə olaraq Vim interfeysinə yaddaş obyekti əlavə etməyə və İdxal Yaddaş Anbarı prosedurunu icra etməyə imkan verir. Sizinlə ehtiyat nüsxələriniz arasında maneə yarada biləcək yeganə şey, əgər ehtiyat nüsxələriniz şifrələnibsə, parol daxil etmək istəyidir.

Bu, yəqin ki, Kopyalama Rejimi ilə bağlıdır və biz davam edirik

Möhürlənmiş rejim

Əsas ideya ondan ibarətdir ki, yeni ehtiyat nüsxələr anbarın seçilmiş SOBR həcmində görünə bilməz. v10-dan əvvəl bizdə yalnız Baxım Rejimi var idi, o zaman repozitoriya ilə hər hansı iş tamamilə qadağan idi. Yaddaşın bağlanması üçün bir növ sərt rejimdir, burada yalnız Evakuasiya düyməsi mövcuddur və bu, ehtiyat nüsxələri birdəfəlik başqa ölçüyə çatdırır.

Və Möhürlənmiş rejim bir növ "yumşaq" seçimdir: biz yeni ehtiyat nüsxələrinin yaradılmasını qadağan edirik və seçilmiş saxlanmaya uyğun olaraq köhnələrini tədricən silirik, lakin bu prosesdə saxlanılan nöqtələrdən bərpa etmək qabiliyyətini itirmirik. Çox faydalı bir şey, ya ömrünün sonuna yaxınlaşan bir aparat parçasımız olduqda və onu dəyişdirmək lazım olduqda, ya da sadəcə daha vacib bir şey üçün onu boşaltmaq lazımdır, lakin onu götürüb hər şeyi bir anda köçürmək üçün heç bir yer yoxdur. Yoxsa onu silmək olmaz.

Müvafiq olaraq, əməliyyat prinsipi olduqca sadədir: bütün yazma əməliyyatlarını (yeni məlumatların görünməsi), oxunuş (bərpa) və silmə (saxlama) tərk etməsini qadağan etmək lazımdır.

Hər iki rejim eyni vaxtda istifadə edilə bilər, lakin nəzərə alın ki, Baxım daha yüksək prioritetə ​​malikdir.

Nümunə olaraq, iki dərəcədən ibarət SOBR-i nəzərdən keçirək. Fərz edək ki, ilk dörd gün ərzində Forward Forever Incremental rejimində ehtiyat nüsxələri yaratdıq, sonra isə miqyasını möhürləyirik.Bu ona gətirib çıxarır ki, biz ikinci mövcud miqyasda yeni aktiv tamın yaradılmasına başlayırıq. Əgər tutmamız dörddürsə, möhürlənmiş genişlikdə yerləşən bütün zəncir öz hüdudlarından kənara çıxdıqda, təmiz bir vicdanla silinir.

Silinmənin daha əvvəl baş verdiyi vəziyyətlər var. Məsələn, bu, dövri tamlarla İrəli artımdır. Əgər ilk iki gün ərzində tam ehtiyat nüsxələri yaratmışıqsa və cümə axşamı deponu möhürləməyə qərar vermişiksə, cümə günü, yeni ehtiyat nüsxə yaradıldıqda, bazar ertəsi üçün fayl silinəcək, çünki bu baxımdan heç bir asılılıq yoxdur. Və məqamın özü heç kimdən asılı deyil. Sonra mövcud ölçüdə dörd nöqtə yaradılana qədər gözləyirik və bir-birindən müstəqil olaraq silinə bilməyən qalan üçünü silirik.

Reverse Incremental ilə işlər daha sadədir. Orada ən qədim nöqtələr heç bir şeydən asılı deyil və etibarlı şəkildə silinə bilər. Odur ki, yeni .vbk yeni ölçüdə yaradılan kimi köhnə .vrbs bir-bir silinəcək.

Yeri gəlmişkən, niyə biz hər dəfə yeni .vbk yaradırıq: əgər biz onu yaratmasaq, köhnə artım zəncirini davam etdirsəydik, o zaman köhnə .vbk istənilən rejimdə sonsuz müddətə donaraq onun silinməsinə mane olacaqdı. Buna görə də qərara alındı ​​ki, həddi möhürlənən kimi biz sərbəst şəkildə tam ehtiyat nüsxəsini yarataq.

Tutumlu atış məsafəsi ilə işlər daha mürəkkəbdir.

Əvvəlcə kopyalama rejiminə baxaq. Fərz edək ki, biz dörd gün ərzində fəal surətdə ehtiyat nüsxələri yaratdıq və sonra tutumlu atış məsafəsi möhürləndi. Biz heç nəyi silmirik, lakin saxlanmaya təvazökarlıqla dözürük, bundan sonra məlumatları tutumlu atış məsafəsindən silirik.

Təxminən eyni şey hərəkət rejimində baş verir - biz rötuşu gözləyirik, yerli yaddaşda köhnəni silirik və obyekt yaddaşında saxlananı silirik.

Forever irəli artımlı ilə maraqlı bir nümunə. Saxlamanı üç nöqtədə quraşdırırıq və bazar ertəsi müntəzəm olaraq buludlara kopyalanan ehtiyat nüsxələrini çıxarmağa başlayırıq. Yaddaşı möhürlədikdən sonra üç nöqtəni saxlayaraq ehtiyat nüsxələri yaratmağa davam edir, lakin tutum tiresində saxlanılan məlumatlar asılı olaraq qalır və silinə bilməz. Buna görə də, .vbk-nin saxlanmadan kənara çıxdığı cümə axşamına qədər gözləyirik və yalnız bundan sonra bütün saxlanmış zənciri sakitcə silirik.

Və kiçik bir imtina: buradakı bütün nümunələr bir maşınla göstərilir. Əgər ehtiyat nüsxənizdə onlardan bir neçəsi varsa, onda onların retuşu Active Full-un edilib-edilməməsindən asılı olaraq fərqlənəcək.

Əsasən bütün bunlar var. Beləliklə, ən sərt xüsusiyyətə keçək -

Dəyişməzlik

Əvvəlki nöqtələrdə olduğu kimi, ilk şey bu funksiyanın hansı problemi həll etdiyidir. Ehtiyat nüsxələrimizi saxlama üçün harasa yükləyən kimi onların təhlükəsizliyinə zəmanət vermək, yəni müəyyən saxlama zamanı onların silinməsini və hər hansı dəyişdirilməsini fiziki olaraq qadağan etmək istəyi yaranır. O cümlədən adminlər, o cümlədən onların kök hesabları altında. Bu, onları təsadüfi və ya qəsdən zədələnmədən qorumağa imkan verir. AWS ilə işləyən hər kəs Object Lock adlı oxşar xüsusiyyətlə rastlaşa bilər.

İndi gəlin ümumi mənada rejimə baxaq, sonra isə təfərrüatları araşdıraq. Nümunəmizdə Dəyişməzlik dörd gün saxlama qabiliyyəti ilə atış məsafəmiz üçün aktivləşdiriləcəkdir. Və ehtiyat nüsxədə Kopyalama rejimi aktivdir.

Dəyişməzlik heç bir şəkildə ümumi tutma ilə qarşılıqlı təsir göstərmir. Məsələn, əlavə xal və ya buna bənzər bir şey əlavə etmir. Sadəcə, bir şəxs dörd gün ərzində ehtiyat faylları silə bilməz. Bazar ertəsi ehtiyat nüsxəsini çıxarsanız, onun faylını yalnız cümə günü silə biləcəksiniz.

Susuzlaşdırma, indekslər və metadata ilə bağlı əvvəlcədən izah edilmiş bütün anlayışlar eyni şəkildə işləməyə davam edir. Ancaq bir şərtlə - blok yalnız məlumat üçün deyil, həm də metadata üçün təyin olunur. Bu, hiyləgər təcavüzkarın metadata verilənlər bazamızı silmək və məlumat bloklarının yararsız ikili mush-a çevrilməsinin qarşısını almaq qərarına gəldiyi halda edilir.

İndi blok yaratmaq texnologiyamızı izah etmək üçün əla vaxtdır. Və ya blok nəsil. Bunu etmək üçün onun görünüşünə səbəb olan vəziyyəti nəzərdən keçirin.

Gəlin altı günlük bir zaman şkalasını götürək və aşağıda biz dəyişməzliyin gözlənilən bitmə vaxtını qeyd edəcəyik. Birinci gün məlumat bloku a və onun metadatasından ibarət faylı götürüb yaradırıq. Dəyişməzlik üç günə təyin edilərsə, dördüncü gündə məlumatların kiliddən çıxarılacağını və silinəcəyini güman etmək məntiqlidir. İkinci gün biz eyni parametrlərlə b blokundan ibarət yeni fayl2 əlavə edəcəyik. Dördüncü gündə bloku çıxarmaq lazımdır. Ancaq üçüncü gün dəhşətli bir şey baş verir - yeni d blokundan və köhnə a blokuna keçiddən ibarət File3 faylı yaradılır. Bu o deməkdir ki, blok və onun dəyişməzliyi bayrağı altıncı günə köçürülən yeni tarixə sıfırlanmalıdır. Və burada bir problem yaranır - real ehtiyat nüsxələrində çox sayda belə blok var. Onların dəyişməzlik müddətini uzatmaq üçün hər dəfə çoxlu sayda sorğu göndərməlisiniz. Və əslində, bu, demək olar ki, sonsuz bir gündəlik proses olacaq, çünki yüksək ehtimalla hər bir nüsxə ilə birlikdə təkrarlanmış blokların böyük yığınlarını tapacağıq. Obyekt saxlama provayderlərindən çoxlu sayda sorğu nə deməkdir? Doğru! Ayın sonunda böyük hesab.

Sevdiyiniz müştəriləri külli miqdarda pulla ifşa etməmək üçün blok yaratma mexanizmi icad edilmişdir. Bu, müəyyən edilmiş dəyişməzlik dövrünə əlavə etdiyimiz əlavə dövrdür. Aşağıdakı nümunədə bu müddət iki gündür. Amma bu sadəcə bir nümunədir. Əslində, onlar aylıq kilidləmə zamanı təxminən on əlavə gün verən öz düsturlarından istifadə edirlər.

Eyni vəziyyəti nəzərdən keçirməyə davam edək, lakin blok nəsil ilə. Birinci gün biz a blokundan və metadatadan fayl1 yaradırıq. Nəsil müddətini və dəyişməzliyi əlavə edirik - bu, faylı silmək fürsətinin altıncı gündə olacağını bildirir. Əgər ikinci gün b blokundan və a blokuna keçiddən ibarət File2 yaradırıqsa, gözlənilən silinmə tarixinə heç nə baş vermir. O, altıncı gün olduğu kimi ayağa qalxdı. Beləliklə, biz sorğuların sayına qənaət etməyə çalışırıq. Son müddətin dəyişdirilə biləcəyi yeganə vəziyyət generasiya müddəti başa çatmasıdır. Yəni, üçüncü gün yeni Fayl3-də a bloklamaq üçün keçid varsa, Gen2-in müddəti artıq bitdiyi üçün 1-ci nəsil əlavə olunacaq. Və a blokunun silinməsi üçün gözlənilən tarix səkkizinci günə keçəcək. Bu, bizə təkrarlanan blokların ömrünü uzatmaq üçün müraciətlərin sayını kəskin şəkildə azaltmağa imkan verir ki, bu da müştərilərə bir ton pul qənaət edir.

Texnologiyanın özü S3 və S3 uyğun avadanlıq istifadəçiləri üçün əlçatandır, onların istehsalçıları onların tətbiqinin Amazon-dan fərqlənməməsinə zəmanət verir. Azure-un niyə dəstəklənmədiyinə dair qanuni sualın cavabı belədir - onların oxşar xüsusiyyəti var, lakin o, fərdi obyektlər deyil, konteynerlər səviyyəsində işləyir. Yeri gəlmişkən, Amazonun özündə iki rejimdə obyekt kilidi var: uyğunluq və idarəetmə. İkinci halda, obyektin kilidlənməsinə baxmayaraq, adminlərin üstündəki ən böyük admin və köklərin üstündəki kökün hələ də məlumatları silməsi ehtimalı qalır. Uyğunluq vəziyyətində, hər şey sıx bir şəkildə dırnaqlanır və heç kim ehtiyat nüsxələrini silə bilməz. Hətta Amazon adminləri (rəsmi açıqlamalarına görə). Bu, dəstəklədiyimiz rejimdir.

Həmişə olduğu kimi, bəzi faydalı bağlantılar:

• haqqında Blok Nəsil hər detalda.
• Haqqında bütün məlumatlar Veeam Backup & Replication 10 ən yaxşı halda
• О Tutum səviyyəsi ətraflı

Mənbə: www.habr.com