Ang Capacity Tier (o kung tawagin natin ito sa loob ng Vim - captir) ay lumitaw noong mga araw ng Veeam Backup at Replication 9.5 Update 4 sa ilalim ng pangalang Archive Tier. Ang ideya sa likod nito ay gawing posible na ilipat ang mga backup na nahulog mula sa tinatawag na operational restore window sa object storage. Nakatulong ito na linisin ang espasyo sa disk para sa mga user na kakaunti nito. At ang opsyong ito ay tinawag na Move Mode.

Upang maisagawa ang simpleng pagkilos na ito (parang tila), sapat na upang matugunan ang dalawang kundisyon: ang lahat ng punto mula sa inilipat na backup ay dapat nasa labas ng mga hangganan ng nabanggit na operational restore window, na tahasang nakatakda sa UI. At pangalawa: ang chain ay dapat nasa tinatawag na "sealed form" (sealed backup chain o Inactive Backup Chain). Ibig sabihin, walang pagbabagong nagaganap sa chain na ito sa paglipas ng panahon.

Ngunit sa VBR v10, ang konsepto ay dinagdagan ng mga bagong function - Copy Mode, Sealed Mode at isang bagay na may mahirap na bigkasin na pangalan na Immutability ay lumitaw.

Ito ang mga kamangha-manghang bagay na pag-uusapan natin ngayon. Una, tungkol sa kung paano ito gumana sa VBR9.5u4, at pagkatapos ay tungkol sa mga pagbabago sa ikasampung bersyon.

At nawa'y patawarin ako ng mga kampeon ng dalisay na wika, ngunit napakaraming termino na hindi maisasalin.
Kaya magkakaroon ng isang toneladang Anglicisms dito.
At maraming gif.
At mga larawan.

• Nang walang kaunting pagsisisi. May-akda ng artikulo.

Gaya noon

Well, magsimula tayo sa pamamagitan ng pagsusuri sa operational restore window at selyadong backup (o kung tawagin sila sa Inactive Backup Chain na dokumentasyon). Kung wala ang kanilang pag-unawa, ang karagdagang paliwanag ay hindi posible.

Tulad ng nakikita natin sa larawan, mayroon kaming isang uri ng backup na chain na may mga bloke ng data, na matatagpuan sa Performance tier SOBR ng repository kung saan nakakonekta ang Capacity Tier. Ang aming operational backup window ay tatlong araw.

Alinsunod dito, ang .vbk na ginawa noong Lunes ay nagse-seal sa nakaraang chain, na ang window ay nakatakda sa tatlong araw. At nangangahulugan iyon na maaari mong ligtas na simulan ang transportasyon ng lahat ng mas luma kaysa sa tatlong araw na ito sa hanay ng pagbaril.

Ngunit ano nga ba ang ibig sabihin ng isang selyadong chain at ano ang maaaring ipadala sa capacity shooting range sa update 4?

Para sa Forward Incremental, isang tanda ng pag-seal ng chain ay ang paglikha ng isang bagong buong backup. At hindi mahalaga kung paano nakuha ang buong backup na ito: parehong synthetic full at aktibong full backup ay isinasaalang-alang.

Sa kaso ng Reverse, ito ang lahat ng mga file na hindi nahuhulog sa operating window.

Sa kaso ng Forward increment na may mga rollback, lahat ito ay mga rollback at .vbk, kung may isa pang .vbk sa lawak ng pagganap

Ngayon isaalang-alang natin ang opsyon ng pagtatrabaho sa Backup Copy chain. Ang mga bagay lamang na nasa ilalim ng pagpapanatili ng GFS ang dinala rito. Dahil lahat ng nakaimbak sa mas kamakailang backup na mga chain ng kopya ay maaaring baguhin sa isang paraan o iba pa.

Ngayon tingnan natin sa ilalim ng hood. Doon, nangyayari ang isang prosesong tinatawag na dehydration - nag-iiwan ng mga walang laman na backup na file sa lawak at nag-drag ng mga bloke mula sa mga file na ito patungo sa capacity shooting range. Upang ma-optimize ang prosesong ito, ginagamit ang tinatawag na dehydration index, na nagbibigay-daan sa iyo upang maiwasan ang pagkopya ng mga bloke na nakopya na sa hanay ng pagbaril ng kapasidad.

Tingnan natin kung ano ang hitsura nito sa isang halimbawa: Sabihin nating mayroon tayong .vbk na lumabas sa window ng transaksyon at kabilang sa isang selyadong chain. Nangangahulugan ito na mayroon tayong lahat ng karapatan na ilipat ito sa capacity shooting range. Sa oras ng paglipat, ang isang metadata file ay nilikha sa dash ng kapasidad at mga bloke ng inilipat na file. Ang link-level metadata file ay naglalarawan kung ano ang humaharang sa aming file. Sa kaso sa larawan, ang aming unang file ay binubuo ng mga bloke a, b, c at ang metadata ay naglalaman ng mga link sa mga bloke na ito. Kapag mayroon kaming pangalawang .vbk file, handa nang ilipat at binubuo ng mga bloke a, b at d, sinusuri namin ang index ng dehydration, nauunawaan na ang block d lang ang kailangang ilipat. At ang metadata file nito ay maglalaman ng mga link sa dalawang nakaraang bloke at isang bago.

Alinsunod dito, ang proseso ng pagpuno sa mga bakanteng espasyo na ito pabalik ng data ay tinatawag na rehydration. Gumagamit na ito ng sarili nitong index ng rehydration, batay sa pinakalumang .vbk file sa lokal na lawak ng pagganap. Iyon ay, kung gusto ng user na magbalik ng file mula sa capacity shooting range, gumawa muna kami ng index ng mga block ng pinakalumang full backup at ilipat lang ang mga nawawalang block mula sa capacity shooting gallery. Sa kaso na ipinakita sa larawan, upang ma-rehydrate ang FullBackup1.vbk ayon sa index ng rehydration, kailangan lang namin ng block C, na kinukuha namin mula sa capacity shooting range. Kung ang isang storage cloud object ay nagsisilbing capacity shooting range, nagbibigay-daan ito sa iyong makatipid ng napakalaking halaga.

Dito ay maaaring mukhang ang teknolohiyang ito ay kapareho ng ginamit sa WAN Accelerators, ngunit tila ganoon lang. Sa mga accelerator, ang deduplication ay pandaigdigan; dito, ang lokal na deduplication ay ginagamit sa loob ng bawat file sa isang partikular na offset. Nangyayari ito dahil sa pagkakaiba sa mga gawaing niresolba: dito kailangan nating kopyahin ang malalaking buong backup na mga file, at ayon sa aming pananaliksik, kahit na lumipas ang mahabang panahon sa pagitan ng mga ito, ang deduplication algorithm na ito ay nagbibigay ng pinakamahusay na resulta.

Ngunit higit pang mga index para sa diyos ng mga index! Mayroon ding index para sa pagbawi ng data! Kapag nagsimula kaming mag-restore ng machine na nasa capacity dash, magbabasa lang kami ng mga natatanging data block na wala sa performance dash.

Paano ito nangyari?

Iyon lang para sa panimulang bahagi. Ito ay medyo detalyado, ngunit tulad ng nabanggit sa itaas, kung wala ang mga detalyeng ito ay hindi posible na ipaliwanag kung paano gumagana ang mga bagong pag-andar. Samakatuwid, nang walang karagdagang ado, lumipat tayo sa una.

Copy mode

Ito ay higit sa lahat batay sa mga umiiral na teknolohiya, ngunit nagdadala ng isang ganap na naiibang lohika ng paggamit. 

Ang layunin ng mode na ito ay upang matiyak na ang lahat ng data na matatagpuan sa lokal na lawak ay may kopya sa dash ng kapasidad.

Kung ihahambing mo ang Move and Copy modes head-on, magiging ganito ang hitsura:

• Tanging ang selyadong kadena lamang ang maaaring ilipat. Sa kaso ng isang mode ng kopya, ganap na lahat ay inililipat, anuman ang mangyayari sa backup na trabaho.
• Nati-trigger ang paglipat kapag lumampas ang mga file sa mga hangganan ng operational backup na window, at ma-trigger ang pagkopya sa sandaling lumitaw ang backup na file.
• Patuloy na nagaganap ang pagsubaybay sa bagong data para sa pagkopya, at para sa paglipat ay na-trigger ito isang beses bawat 4 na oras.

Sa pagsasaalang-alang sa bagong mode, ipinapanukala kong lumipat mula sa mga simpleng halimbawa patungo sa mga kumplikado.

Sa pinakakaraniwang kaso, mayroon lang kaming mga bagong file na may mga pagtaas, at kinokopya lang namin ang mga ito sa hanay ng pagbaril ng kapasidad. Anuman ang mode na ginagamit sa backup na trabaho, hindi alintana kung ito ay kabilang sa selyadong bahagi ng chain o hindi, hindi alintana kung ang aming operating window ay nag-expire na. Kinuha lang nila at kinopya.

Ang proseso sa likod nito ay dehydration pa rin gaya ng inilarawan sa itaas. Sa copy mode, tinitiyak din nito na hindi namin kinokopya ang mga bloke na nasa aming storage na. Ang pagkakaiba lamang ay kung sa mode ng pelikula ay pinalitan namin ang mga tunay na file ng mga dummy file, narito hindi namin hinawakan ang mga ito sa anumang paraan at iiwan ang lahat ng bagay. Kung hindi, ito ay eksaktong parehong index ng pag-aalis ng tubig, na maingat na sinusubukang i-save ang iyong pera at oras.

Ang tanong ay lumitaw - kung titingnan mo ang UI, mayroong isang pagkakataon upang piliin ang parehong mga pagpipilian sa parehong oras. Paano gagana ang ganitong pinagsamang mode?

Tingnan natin ito.

Ang simula ay karaniwan: ang isang backup na file ay nilikha at kinopya kaagad. Ang isang pagtaas ay nilikha dito at kinopya din. Nangyayari ito hanggang sa sandaling napagtanto namin na ang mga file ay umalis sa aming operating window at lumitaw ang isang selyadong chain. Sa puntong ito nagsasagawa kami ng operasyon sa pag-dehydration at pinapalitan ang mga file na ito ng mga dummy file. Siyempre, hindi na kami muling kumopya ng anuman sa capacity shooting range.

Ang lahat ng kamangha-manghang logic na ito ay responsable para sa isang checkbox lamang sa interface: Kopyahin ang mga backup sa object storage sa sandaling malikha ang mga ito.

Bakit kailangan natin itong Copy mode?

Mas mainam na palitan ang tanong sa ganitong paraan: anong mga panganib ang pinoprotektahan natin sa tulong nito? Anong problema ang nakakatulong sa atin na malutas?

Ang sagot ay halata: siyempre, ito ay pagbawi ng data. Kung mayroon kaming kumpletong kopya ng lokal na data sa imbakan ng bagay, anuman ang mangyari sa aming produkto, maaari naming palaging ibalik ang data mula sa mga file na matatagpuan sa kondisyong Amazon.

Kaya't dumaan tayo sa mga posibleng senaryo, mula sa pinakasimple hanggang sa mas kumplikado.

Ang pinakasimpleng kasawian na maaaring mahulog sa aming mga ulo ay ang hindi naa-access ng isa sa mga file sa backup chain.

Ang isang mas malungkot na kuwento ay ang isa sa mga lawak ng aming SOBR repository ay nasira.

Mas lumalala pa kapag ang buong SOBR repository ay naging hindi naa-access, ngunit gumagana ang capacity shooting range.
At lahat ay talagang masama - ito ay kapag ang backup na server ay namatay at ang iyong unang pagnanais ay subukang tumakbo sa hangganan ng Canada sa loob ng sampung minuto.

Ngayon tingnan natin ang bawat sitwasyon nang hiwalay.

Kapag nawala ang isa (at kahit ilang) backup na file, ang kailangan lang nating gawin ay simulan ang proseso ng pag-rescan ng repository, at ang nawalang file ay papalitan ng dummy file. At gamit ang proseso ng rehydration (na tinalakay sa simula ng artikulo), ang user ay makakapag-download ng data mula sa capacity shooting range hanggang sa lokal na storage.

Ngayon ang sitwasyon ay mas kumplikado. Ipagpalagay natin na ang ating SOBR ay binubuo ng dalawang lawak na tumatakbo sa Performance mode, na nangangahulugang ang ating .vbk at .vib ay nakakalat sa mga ito sa medyo hindi pantay na layer. At sa ilang mga punto sa oras, ang isa sa mga lawak ay nagiging hindi magagamit, at ang gumagamit ay mapilit na kailangang ibalik ang makina, bahagi ng data na kung saan ay namamalagi nang tumpak sa lawak na ito.

Inilunsad ng user ang recovery wizard, pinipili ang punto kung saan niya gustong ibalik, at ang wizard, habang nagtatrabaho, ay napagtanto na wala siya ng lahat ng data na kinakailangan para sa pagbawi nang lokal at samakatuwid ay kailangang ma-download mula sa pagbaril ng kapasidad gallery. Kasabay nito, ang mga bloke na nananatili sa lokal na imbakan ay hindi mada-download mula sa cloud. Luwalhati sa index ng pagpapanumbalik (oo, nabanggit din ito sa simula ng artikulo).

Ang isang subtype ng kasong ito ay ang buong SOBR repository ay naging hindi naa-access. Sa kasong ito, wala kaming dapat kopyahin mula sa lokal na imbakan, at lahat ng mga bloke ay dina-download mula sa cloud.

At ang pinaka-kagiliw-giliw na sitwasyon ay ang backup na server ay namatay. Mayroong dalawang mga pagpipilian dito: ang admin ay mahusay at gumawa ng mga backup ng configuration, at ang admin ay isang masamang Pinocchio mismo at hindi gumawa ng mga backup ng configuration.

Sa unang kaso, sapat na para sa kanya na mag-deploy lamang ng malinis na pag-install ng VBR sa isang lugar at ibalik ang database nito mula sa isang backup gamit ang karaniwang paraan. Sa pagtatapos ng prosesong ito, babalik sa normal ang lahat. O ito ay ibabalik ayon sa isa sa mga senaryo sa itaas.

Ngunit kung ang admin ay alinman sa kanyang sariling kaaway, o ang backup ng pagsasaayos ay nagdusa din ng isang epikong pagkabigo, kung gayon kahit dito ay hindi namin siya iiwan sa awa ng kapalaran. Para sa kasong ito, ipinakilala namin ang isang bagong pamamaraan na tinatawag na Import Object Storage. Binibigyang-daan ka nitong laktawan ang proseso ng manu-manong muling paggawa ng SOBR repository at pag-attach ng capacity shooting range dito na may kasunod na rescan, at magdagdag lang ng storage object sa Vim interface at patakbuhin ang Import Storage Repository procedure. Ang tanging bagay na maaaring maging hadlang sa pagitan mo at ng iyong mga backup ay isang kahilingan na maglagay ng password kung ang iyong mga backup ay naka-encrypt.

Malamang na ito ay tungkol sa Copy Mode at magpatuloy tayo sa

Selyadong Mode

Ang pangunahing ideya ay hindi maaaring lumitaw ang mga bagong backup sa napiling lawak ng SOBR ng repositoryo. Bago ang v10, mayroon lang kaming Maintenance Mode, kapag ang anumang gawain sa repository ay ganap na ipinagbabawal. Isang uri ng hardcore mode para sa pag-shut down ng storage, kung saan ang Evacuate button lang ang available, na nagdadala ng mga backup sa ibang lawak nang isang beses.

At ang Sealed mode ay isang uri ng "malambot" na opsyon: ipinagbabawal namin ang paglikha ng mga bagong backup at unti-unting tinanggal ang mga luma ayon sa napiling pagpapanatili, ngunit sa proseso ay hindi kami nawawalan ng kakayahang ibalik mula sa mga naka-imbak na punto. Isang napaka-kapaki-pakinabang na bagay kapag mayroon tayong isang piraso ng hardware na malapit nang matapos ang buhay nito at kailangan nating palitan ito, o kailangan lang natin itong palayain para sa isang bagay na mas mahalaga, ngunit wala nang madadala ito at ilipat ang lahat nang sabay-sabay. O hindi ito matatanggal.

Alinsunod dito, ang prinsipyo ng pagpapatakbo ay medyo simple: kinakailangan na ipagbawal ang lahat ng mga operasyon sa pagsulat (ang hitsura ng bagong data), pag-iiwan ng read (restorations) at tanggalin (pagpapanatili).

Ang parehong mga mode ay maaaring gamitin nang sabay-sabay, ngunit tandaan na ang Pagpapanatili ay may mas mataas na priyoridad.

Bilang halimbawa, isaalang-alang ang isang SOBR na binubuo ng dalawang lawak. Ipagpalagay natin na sa unang apat na araw ay gumawa kami ng mga backup sa Forward Forever Incremental mode, at pagkatapos ay ise-seal namin ang lawak. Ito ay humahantong sa katotohanan na sinimulan namin ang paglikha ng isang bagong aktibong puno sa pangalawang magagamit na lawak. Kung ang aming pagpapanatili ay apat, kung gayon kapag ang buong kadena na matatagpuan sa selyadong lawak ay lumampas sa mga limitasyon nito, ito ay tatanggalin nang may malinis na budhi.

May mga sitwasyon kung kailan nangyayari ang pagtanggal nang mas maaga. Halimbawa, ito ay Forward incremental na may periodic fulls. Kung gumawa kami ng mga buong backup para sa unang dalawang araw, at sa Huwebes ay nagpasya kaming i-seal ang repository, pagkatapos ay sa Biyernes, kapag ang isang bagong backup ay ginawa, ang file para sa Lunes ay tatanggalin dahil walang mga dependencies sa puntong ito. At ang punto mismo ay hindi nakasalalay sa sinuman. Pagkatapos ay maghintay kami hanggang apat na puntos ang malikha sa magagamit na lawak at tanggalin ang natitirang tatlo, na hindi maaaring tanggalin nang nakapag-iisa sa isa't isa.

Ang mga bagay ay mas simple sa Reverse Incremental. Sa loob nito, ang mga pinakalumang punto ay hindi nakasalalay sa anumang bagay at maaaring ligtas na matanggal. Samakatuwid, sa sandaling malikha ang isang bagong .vbk sa isang bagong lawak, ang mga lumang .vrb ay tatanggalin nang paisa-isa.

Oo nga pala, bakit tayo gumagawa ng bagong .vbk sa bawat oras: kung hindi natin ito nilikha, ngunit ipinagpatuloy ang lumang hanay ng mga pagtaas, kung gayon ang lumang .vbk ay magye-freeze nang walang katapusang mahabang panahon sa anumang mode, na pumipigil sa pagtanggal nito. Samakatuwid, napagpasyahan na sa sandaling ma-seal ang lawak, gumawa kami ng buong backup sa libreng lawak.

Ang mga bagay ay mas kumplikado sa hanay ng pagbaril ng kapasidad.

Una, tingnan natin ang copy mode. Ipagpalagay natin na aktibong gumagawa tayo ng mga backup sa loob ng apat na araw, at pagkatapos ay na-sealed ang capacity shooting range. Hindi kami nagtatanggal ng anuman, ngunit buong kababaang-loob na tinitiis ang pagpapanatili, pagkatapos nito ay tinatanggal namin ang data mula sa hanay ng pagbaril ng kapasidad.

Humigit-kumulang pareho ang nangyayari sa mode ng paglipat - naghihintay kami para sa retouch, tanggalin ang luma sa lokal na imbakan, at tanggalin ang nakaimbak sa imbakan ng bagay.

Isang kawili-wiling halimbawa sa Forever forward incremental. Nag-i-install kami ng retention sa tatlong punto at nagsisimula kaming gumawa ng mga backup sa Lunes, na regular na kinokopya sa cloud. Pagkatapos i-seal ang storage, patuloy na ginagawa ang mga backup, na pinapanatili ang tatlong puntos, ngunit ang data na nakaimbak sa capacity dash ay nananatiling nakadepende at hindi matatanggal. Samakatuwid, naghihintay kami hanggang Huwebes, kapag ang aming .vbk ay lumampas sa pagpapanatili, at pagkatapos ay mahinahon naming tinanggal ang buong naka-save na chain.

At isang maliit na disclaimer: lahat ng mga halimbawa dito ay ipinapakita gamit ang isang makina. Kung marami ka sa mga ito sa iyong backup, mag-iiba ang kanilang retoke depende sa kung ginawa ang Active Full o hindi.

Iyon lang talaga. Kaya't lumipat tayo sa pinaka-hardcore na tampok -

Kawalan ng kakayahan

Tulad ng mga nakaraang punto, ang unang bagay ay kung anong problema ang nalulutas ng function na ito. Sa sandaling i-upload namin ang aming mga backup sa isang lugar para sa imbakan, may matinding pagnanais na magarantiya ang kanilang kaligtasan, iyon ay, pisikal na ipagbawal ang kanilang pagtanggal at anumang pagbabago sa panahon ng isang ibinigay na pagpapanatili. Kabilang ang mga admin, kabilang ang sa ilalim ng kanilang mga root account. Pinapayagan ka nitong protektahan ang mga ito mula sa hindi sinasadya o sinasadyang pinsala. Ang sinumang nagtatrabaho sa AWS ay maaaring nakatagpo ng katulad na feature na tinatawag na Object Lock.

Ngayon tingnan natin ang mode sa mga pangkalahatang tuntunin, at pagkatapos ay bungkalin ang mga detalye. Sa aming halimbawa, ie-enable ang Immutability para sa aming capacity shooting range na may retention na apat na araw. At ang Copy mode ay pinagana sa backup.

Ang kawalan ng pagbabago ay hindi nakikipag-ugnayan sa pangkalahatang pagpapanatili sa anumang paraan. Halimbawa, hindi ito nagdaragdag ng mga karagdagang puntos o anumang bagay na katulad niyan. Kaya lang, hindi maaaring tanggalin ng isang tao ang mga backup na file sa loob ng apat na araw. Kung gagawa ka ng backup sa Lunes, mabubura mo lang ang file nito sa Biyernes.

Ang lahat ng naunang ipinaliwanag na mga konsepto ng dehydration, index at metadata ay patuloy na gumagana nang eksakto pareho. Ngunit may isang kundisyon - ang bloke ay nakatakda hindi lamang para sa data, kundi pati na rin para sa metadata. Ginagawa ito kung sakaling magpasya ang isang tusong umaatake na burahin ang aming database ng metadata at upang maiwasan ang mga bloke ng data na maging walang silbi na binary mush.

Ngayon ay isang magandang panahon upang ipaliwanag ang aming block generation na teknolohiya. O block generation. Upang gawin ito, isaalang-alang ang sitwasyon na humantong sa hitsura nito.

Maglaan tayo ng sukat ng oras na anim na araw at sa ibaba ay markahan natin ang oras ng inaasahang pag-expire ng immutability. Sa unang araw na kumukuha at gumagawa kami ng file na binubuo ng data block a at ng metadata nito. Kung ang immutability ay itinakda sa tatlong araw, makatuwirang ipagpalagay na sa ikaapat na araw ay ia-unlock at tatanggalin ang data. Sa ikalawang araw ay magdaragdag kami ng bagong file2, na binubuo ng block b na may parehong mga setting. Kailangan pa ring alisin ang block a sa ikaapat na araw. Ngunit sa ikatlong araw may nangyaring kakila-kilabot - isang File3 file ang nilikha, na binubuo ng isang bagong block d at isang link sa lumang block a. Nangangahulugan ito na para sa isang bloke at ang immutability flag nito ay dapat na i-reset sa isang bagong petsa, na inilipat sa ikaanim na araw. At narito ang isang problema ay lumitaw - sa mga totoong backup mayroong isang malaking bilang ng mga naturang bloke. At upang mapalawak ang kanilang immutability period, kailangan mong gumawa ng isang malaking bilang ng mga kahilingan sa bawat oras. At sa katunayan, ito ay magiging isang halos walang katapusang pang-araw-araw na proseso, dahil may mataas na antas ng posibilidad na makakahanap tayo ng mabigat na stack ng mga deduplicated na bloke sa bawat kopya. Ano ang ibig sabihin ng malaking bilang ng mga kahilingan mula sa mga provider ng object storage? Tama! Malaking bayarin sa katapusan ng buwan.

At upang hindi out of the blue ilantad ang iyong mga paboritong kliyente para sa malaking pera, ang mekanismo ng block generation ay naimbento. Ito ay isang karagdagang panahon na idinaragdag namin sa itinakdang panahon ng immutability. Sa halimbawa sa ibaba, ang panahong ito ay dalawang araw. Ngunit ito ay isang halimbawa lamang. Sa totoo lang, gumagamit sila ng sarili nilang formula, na nagbibigay ng humigit-kumulang sampung karagdagang araw sa buwanang lock.

Patuloy nating isaalang-alang ang parehong sitwasyon, ngunit may block generation. Sa unang araw gumawa kami ng file1 mula sa block a at metadata. Idinaragdag namin ang panahon ng henerasyon at immutability - nangangahulugan ito na ang pagkakataon na tanggalin ang file ay sa ikaanim na araw. Kung sa ikalawang araw ay lumikha kami ng File2, na binubuo ng block b at isang link upang harangan ang a, pagkatapos ay walang mangyayari sa inaasahang petsa ng pagtanggal. Tumayo siya gaya ng ginawa niya noong ikaanim na araw. At sa gayon ay sinusubukan naming makatipid ng pera sa bilang ng mga kahilingan. Ang tanging sitwasyon kung kailan maaaring ilipat ang deadline ay kung ang panahon ng henerasyon ay nag-expire na. Iyon ay, kung sa ikatlong araw ang bagong File3 ay naglalaman ng isang link upang harangan ang isang, pagkatapos ay ang henerasyon 2 ay idadagdag dahil ang Gen1 ay nag-expire na. At ang inaasahang petsa para sa pagtanggal ng block a ay lilipat sa ikawalong araw. Nagbibigay-daan ito sa amin na kapansin-pansing bawasan ang bilang ng mga kahilingan na pahabain ang buhay ng mga na-deduplicate na bloke, na nakakatipid sa mga kliyente ng isang toneladang pera.

Ang teknolohiya mismo ay magagamit sa mga gumagamit ng S3 at S3-compatible na hardware, na ginagarantiyahan ng mga tagagawa na ang kanilang pagpapatupad ay hindi naiiba sa Amazon. Kaya't ang sagot sa lehitimong tanong kung bakit hindi sinusuportahan ang Azure - mayroon silang katulad na tampok, ngunit gumagana ito sa antas ng mga lalagyan, hindi mga indibidwal na bagay. Sa pamamagitan ng paraan, ang Amazon mismo ay may object lock sa dalawang mode: pagsunod at pamamahala. Sa pangalawang kaso, nananatili ang posibilidad na ang pinakadakilang admin sa itaas ng mga admin at ugat sa itaas ng mga ugat, sa kabila ng object lock, ay nagtatanggal pa rin ng data. Sa kaso ng pagsunod, ang lahat ay mahigpit na ipinako at walang sinuman ang makakapagtanggal ng mga backup. Maging ang mga admin ng Amazon (ayon sa kanilang mga opisyal na pahayag). Ito ang mode na sinusuportahan namin.

At, gaya ng dati, ilang kapaki-pakinabang na link:

• Tungkol sa Block Generation sa bawat detalye.
• Lahat ng impormasyon tungkol sa Veeam Backup at Replication 10 sa kanyang pinakamahusay
• О Tier ng Kapasidad nang detalyado

Pinagmulan: www.habr.com