Niveli i Kapacitetit (ose siç e quajmë brenda Vim - captir) u shfaq në ditët e Veeam Backup and Replication 9.5 Update 4 me emrin Archive Tier. Ideja pas saj është të mundësojë zhvendosjen e kopjeve rezervë që kanë rënë nga e ashtuquajtura dritare e rivendosjes operacionale në ruajtjen e objekteve. Kjo ndihmoi në pastrimin e hapësirës në disk për ata përdorues që kishin pak nga ajo. Dhe ky opsion u quajt Move Mode.

Për të kryer këtë veprim të thjeshtë (siç duket), mjaftonte të plotësoheshin dy kushte: të gjitha pikat nga rezervimi i zhvendosur duhet të jenë jashtë kufijve të dritares së mësipërme të rivendosjes operacionale, e cila është vendosur në mënyrë eksplicite në UI. Dhe së dyti: zinxhiri duhet të jetë në të ashtuquajturën "formë të vulosur" (zinxhiri rezervë i mbyllur ose Zinxhiri rezervë joaktiv). Kjo do të thotë, në këtë zinxhir nuk ndodh asnjë ndryshim me kalimin e kohës.

Por në VBR v10, koncepti u plotësua me funksione të reja - Modaliteti i Kopjimit, Modaliteti i Mbyllur dhe u shfaq një gjë me emrin e vështirë për t'u shqiptuar Immutability.

Këto janë gjërat magjepsëse për të cilat do të flasim sot. Së pari, për mënyrën se si funksionoi në VBR9.5u4, dhe më pas për ndryshimet në versionin e dhjetë.

Dhe mund të më falin kampionët e gjuhës së pastër, por ka shumë terma që nuk mund të përkthehen.
Pra, këtu do të ketë një ton anglicizmash.
Dhe shumë gif.
Dhe foto.

• Pa as më të voglin keqardhje. Autori i artikullit.

Siç ishte

Epo, le të fillojmë duke analizuar dritaren e rivendosjes operacionale dhe kopjen rezervë të vulosur (ose siç quhen në dokumentacionin e zinxhirit rezervë joaktive). Pa kuptimin e tyre, shpjegimi i mëtejshëm nuk do të jetë i mundur.

Siç e shohim në foto, kemi një lloj zinxhiri rezervë me blloqe të dhënash, i cili ndodhet në nivelin e performancës SOBR të depove me të cilin është lidhur Niveli i Kapacitetit. Dritarja jonë operative rezervë është tre ditë.

Prandaj, .vbk e krijuar të hënën vulos zinxhirin e mëparshëm, dritarja e të cilit është caktuar në tre ditë. Dhe kjo do të thotë që ju mund të filloni me siguri të transportoni gjithçka më të vjetër se këto tre ditë në poligonin e qitjes.

Por çfarë nënkuptohej saktësisht me një zinxhir të mbyllur dhe çfarë mund të dërgohej në poligonin e qitjes me kapacitet në përditësimin 4?

Forward Incremental, një shenjë e vulosjes së zinxhirit është krijimi i një rezervë të re të plotë. Dhe nuk ka rëndësi se si merret ky kopje rezervë e plotë: merren parasysh si rezervat e plota sintetike ashtu edhe ato aktive.

Në rastin e Reverse, këto janë të gjithë skedarë që nuk bien në dritaren e funksionimit.

Në rastin e rritjes përpara me rikthime, këto janë të gjitha rikthime dhe .vbk, nëse ka një tjetër .vbk në masën e performancës

Tani le të shqyrtojmë mundësinë e punës me zinxhirët e kopjeve rezervë. Vetëm artikujt që i përkasin mbajtjes së GFS u transportuan këtu. Sepse çdo gjë e ruajtur në zinxhirët më të fundit të kopjeve rezervë mund të ndryshohet në një mënyrë ose në një tjetër.

Tani le të shohim nën kapuç. Atje, ndodh një proces i quajtur dehidratim - lënia e skedarëve rezervë bosh në shtrirjen dhe zvarritja e blloqeve nga këta skedarë në poligonin e kapacitetit të qitjes. Për të optimizuar këtë proces, përdoret i ashtuquajturi indeksi i dehidrimit, i cili ju lejon të shmangni kopjimin e blloqeve që janë kopjuar tashmë në poligonin e qitjes me kapacitet.

Le të shohim se si duket kjo me një shembull: Le të themi se kemi një .vbk që doli nga dritarja e transaksionit dhe i përket një zinxhiri të mbyllur. Kjo do të thotë se ne kemi çdo të drejtë ta zhvendosim atë në poligonin e qitjes me kapacitet. Në momentin e zhvendosjes, krijohet një skedar metadata në vijën e kapacitetit dhe blloqet e skedarit të transferuar. Skedari i meta të dhënave në nivel lidhjeje përshkruan se nga cilat blloqe përbëhet skedari ynë. Në rastin në foto, skedari ynë i parë përbëhet nga blloqet a, b, c dhe metadata përmban lidhje me këto blloqe. Kur kemi një skedar të dytë .vbk, gati për lëvizje dhe i përbërë nga blloqet a, b dhe d, ne, duke analizuar indeksin e dehidrimit, kuptojmë se vetëm blloku d duhet të transferohet. Dhe skedari i tij i meta të dhënave do të përmbajë lidhje me dy blloqe të mëparshme dhe një të ri.

Prandaj, procesi i mbushjes së këtyre hapësirave boshe me të dhëna quhet rehidrim. Ai tashmë përdor indeksin e tij të rihidrimit, bazuar në skedarin më të vjetër .vbk në shkallën e performancës lokale. Kjo do të thotë, nëse përdoruesi dëshiron të kthejë një skedar nga zona e qitjes me kapacitet, ne fillimisht krijojmë një indeks të blloqeve të kopjes rezervë të plotë më të vjetër dhe transferojmë vetëm blloqet që mungojnë nga galeria e xhirimeve me kapacitet. Në rastin e paraqitur në foto, për të rihidratuar FullBackup1.vbk sipas indeksit të rehidrimit, na duhet vetëm blloku C, të cilin e marrim nga poligoni i qitjes me kapacitet. Nëse një objekt i ruajtjes së resë kompjuterike shërben si një fushë qitjeje me kapacitet, kjo ju lejon të kurseni shuma të mëdha parash.

Këtu mund të duket se kjo teknologji është identike me atë të përdorur në përshpejtuesit WAN, por vetëm kështu duket. Në përshpejtuesit, deduplikimi është global; këtu, deduplikimi lokal përdoret brenda çdo skedari në një kompensim specifik. Kjo ndodh për shkak të ndryshimit në detyrat që zgjidhen: këtu duhet të kopjojmë skedarë të mëdhenj rezervë të plotë, dhe sipas hulumtimit tonë, edhe nëse kalon një periudhë e gjatë kohore midis tyre, ky algoritëm i dedublikimit jep rezultatin më të mirë.

Por më shumë indekse për zotin e indekseve! Ekziston edhe një indeks për rikuperimin e të dhënave! Kur fillojmë të rivendosim një makinë të vendosur në vizën e kapacitetit, do të lexojmë vetëm blloqe unike të të dhënave që nuk janë në vizën e performancës.

Si ndodhi?

Kjo është e gjitha për pjesën hyrëse. Është mjaft i detajuar, por siç u përmend më lart, pa këto detaje nuk do të jetë e mundur të shpjegohet se si funksionojnë funksionet e reja. Prandaj, pa vonesë, le të kalojmë tek e para.

Modaliteti i kopjimit

Ai bazohet kryesisht në teknologjitë ekzistuese, por mbart një logjikë krejtësisht të ndryshme përdorimi. 

Qëllimi i këtij modaliteti është të sigurojë që të gjitha të dhënat e vendosura në shtrirjen lokale të kenë një kopje në vizën e kapacitetit.

Nëse krahasoni modalitetet Lëvizja dhe Kopjimi kokë më kokë, do të duket kështu:

• Vetëm zinxhiri i mbyllur mund të lëvizet. Në rastin e një modaliteti kopjimi, absolutisht gjithçka transferohet, pavarësisht se çfarë ndodh në punën rezervë.
• Lëvizja aktivizohet kur skedarët shkojnë përtej kufijve të dritares operative rezervë dhe kopjimi aktivizohet sapo të shfaqet skedari rezervë.
• Monitorimi i të dhënave të reja për kopjim ndodh vazhdimisht, dhe për lëvizjen e tyre aktivizohej një herë në 4 orë.

Duke marrë parasysh mënyrën e re, unë propozoj të kalojmë nga shembujt e thjeshtë në ato komplekse.

Në rastin më të zakonshëm, ne thjesht kemi skedarë të rinj me rritje, dhe thjesht i kopjojmë në poligonin e qitjes me kapacitet. Pavarësisht se çfarë mode përdoret në punën rezervë, pavarësisht nëse i përket pjesës së mbyllur të zinxhirit apo jo, pavarësisht nëse dritarja jonë e funksionimit ka skaduar. Thjesht e morën dhe e kopjuan.

Procesi pas kësaj është ende dehidrimi siç përshkruhet më sipër. Në modalitetin e kopjimit, sigurohet gjithashtu që të mos kopjojmë blloqe që janë tashmë në hapësirën tonë ruajtëse. Dallimi i vetëm është se nëse në modalitetin e filmit zëvendësuam skedarët e vërtetë me skedarë bedel, këtu nuk i prekim në asnjë mënyrë dhe lëmë gjithçka ashtu siç është. Përndryshe, është pikërisht i njëjti indeks i dehidrimit, i cili me kujdes përpiqet të kursejë paratë dhe kohën tuaj.

Shtrohet pyetja - nëse shikoni UI, ekziston një mundësi për të zgjedhur të dy opsionet në të njëjtën kohë. Si do të funksionojë një mënyrë e tillë e kombinuar?

Le ta kuptojmë.

Fillimi është standard: një skedar rezervë krijohet dhe kopjohet menjëherë. I krijohet një rritje dhe gjithashtu kopjohet. Kjo ndodh deri në momentin kur kuptojmë se skedarët janë larguar nga dritarja jonë e funksionimit dhe është shfaqur një zinxhir i mbyllur. Në këtë pikë kryejmë një operacion dehidrimi dhe i zëvendësojmë këto skedarë me skedarë bedel. Sigurisht, ne nuk kopjojmë asgjë përsëri në poligonin e qitjes me kapacitet.

E gjithë kjo logjikë magjepsëse është përgjegjëse për vetëm një kuti kontrolli në ndërfaqe: Kopjoni kopjet rezervë në ruajtjen e objekteve sapo të krijohen.

Pse na duhet ky modalitet kopjimi?

Është edhe më mirë ta riformulojmë pyetjen në këtë mënyrë: nga cilat rreziqe mbrohemi me ndihmën e tij? Çfarë problemi na ndihmon të zgjidhim?

Përgjigja është e qartë: sigurisht, ky është rikuperimi i të dhënave. Nëse kemi një kopje të plotë të të dhënave lokale në ruajtjen e objektit, atëherë pavarësisht se çfarë ndodh me produktin tonë, ne gjithmonë mund të rivendosim të dhënat nga skedarët e vendosur në Amazon të kushtëzuar.

Pra, le të kalojmë nëpër skenarët e mundshëm, nga më të thjeshtët tek më komplekset.

Fatkeqësia më e thjeshtë që mund të bjerë mbi kokën tonë është paarritshmëria e një prej skedarëve në zinxhirin rezervë.

Një histori më e trishtuar është se një nga shtrirjet e depove tona SOBR u prish.

Përkeqësohet edhe më shumë kur i gjithë depoja e SOBR është bërë e paarritshme, por poligoni i qitjes me kapacitet funksionon.
Dhe gjithçka është vërtet e keqe - kjo është kur serveri rezervë vdes dhe dëshira juaj e parë është të përpiqeni të vraponi në kufirin kanadez në dhjetë minuta.

Tani le të shohim secilën situatë veç e veç.

Kur kemi humbur një (dhe madje disa) skedarë rezervë, atëherë gjithçka që duhet të bëjmë është të fillojmë procesin e skanimit të depove dhe skedari i humbur do të zëvendësohet me një skedar të rremë. Dhe duke përdorur procesin e rihidrimit (i cili u diskutua në fillim të artikullit), përdoruesi do të jetë në gjendje të shkarkojë të dhëna nga zona e qitjes me kapacitet në ruajtjen lokale.

Tani situata është më e komplikuar. Le të supozojmë se SOBR-i ynë përbëhet nga dy nivele që funksionojnë në modalitetin e performancës, që do të thotë se .vbk dhe .vib tona janë shpërndarë mbi to në një shtresë mjaft të pabarabartë. Dhe në një moment në kohë, një nga shtrirjet bëhet e padisponueshme dhe përdoruesi duhet urgjentisht të rivendosë makinën, një pjesë e të dhënave të së cilës shtrihen pikërisht në këtë masë.

Përdoruesi lëshon magjistarin e rikuperimit, zgjedh pikën në të cilën dëshiron të rivendosë dhe magjistari, ndërsa punon, kupton se nuk i ka të gjitha të dhënat e nevojshme për rikuperim në nivel lokal dhe për këtë arsye duhet të shkarkohet nga kapaciteti i xhirimit galeri. Në të njëjtën kohë, blloqet që mbeten në ruajtjen lokale nuk do të shkarkohen nga cloud. Lavdi indeksit të rivendosjes (po, u përmend edhe në fillim të artikullit).

Një nënlloj i këtij rasti është se e gjithë depoja e SOBR u bë e paarritshme. Në këtë rast, ne nuk kemi asgjë për të kopjuar nga ruajtja lokale, dhe të gjitha blloqet shkarkohen nga cloud.

Dhe situata më interesante është se serveri rezervë vdiq. Këtu ka dy opsione: administratori është i shkëlqyeshëm dhe ka bërë kopje rezervë të konfigurimit, dhe administratori është një Pinoku i keq dhe nuk ka bërë kopje rezervë të konfigurimit.

Në rastin e parë, do të mjaftojë që ai thjesht të vendosë një instalim të pastër të VBR diku dhe të rivendosë bazën e të dhënave të tij nga një kopje rezervë duke përdorur mjete standarde. Në fund të këtij procesi, gjithçka do të kthehet në normalitet. Ose do të restaurohet sipas një prej skenarëve të mësipërm.

Por nëse administratori është ose armiku i tij, ose rezervimi i konfigurimit gjithashtu pësoi një dështim epik, atëherë edhe këtu nuk do ta lëmë atë në mëshirën e fatit. Për këtë rast, ne kemi prezantuar një procedurë të re të quajtur Magazinimi i objekteve të importit. Kjo ju lejon të kapërceni procesin e rikrijimit manual të një depoje SOBR dhe të bashkëngjitni një poligon qitjeje me kapacitet me skanimin e mëvonshëm, dhe thjesht të shtoni një objekt ruajtjeje në ndërfaqen Vim dhe të ekzekutoni procedurën e depove të ruajtjes së importit. E vetmja gjë që mund të pengojë mes jush dhe rezervave tuaja është një kërkesë për të futur një fjalëkalim nëse kopjet rezervë janë të koduara.

Kjo ndoshta ka të bëjë me modalitetin e kopjimit dhe ne vazhdojmë te

Modaliteti i mbyllur

Ideja kryesore është që kopjet rezervë të reja nuk mund të shfaqen në shtrirjen e zgjedhur SOBR të depove. Përpara v10, ne kishim vetëm modalitetin e mirëmbajtjes, kur çdo punë me depo ishte plotësisht e ndaluar. Një lloj modaliteti i fortë për mbylljen e ruajtjes, ku disponohet vetëm butoni Evacuate, i cili transporton kopje rezervë në një masë tjetër një herë.

Dhe modaliteti i mbyllur është një lloj opsioni "i butë": ne ndalojmë krijimin e kopjeve rezervë të reja dhe fshijmë gradualisht të vjetrat sipas mbajtjes së zgjedhur, por në këtë proces nuk e humbim aftësinë për të rivendosur nga pikat e ruajtura. Një gjë shumë e dobishme kur ose kemi një pjesë të harduerit që i afrohet fundit të jetës së tij dhe duhet ta zëvendësojmë, ose thjesht duhet ta çlirojmë për diçka më të rëndësishme, por nuk ka ku ta marrim dhe të lëvizim gjithçka menjëherë. Ose nuk mund të fshihet.

Prandaj, parimi i funksionimit është mjaft i thjeshtë: është e nevojshme të ndalohen të gjitha operacionet e shkrimit (shfaqja e të dhënave të reja), duke lënë leximin (restaurimet) dhe fshirjen (mbajtjen).

Të dy mënyrat mund të përdoren njëkohësisht, por mbani në mend se Mirëmbajtja ka përparësi më të lartë.

Si shembull, merrni parasysh një SOBR të përbërë nga dy shkallë. Le të supozojmë se për katër ditët e para kemi krijuar kopje rezervë në modalitetin Forward Forever Incremental dhe më pas vulosim shtrirjen. Kjo çon në faktin se ne fillojmë krijimin e një aktivi të ri të plotë në shtrirjen e dytë të disponueshme. Nëse mbajtja jonë është katër, atëherë kur i gjithë zinxhiri i vendosur në shtrirjen e mbyllur shkon përtej kufijve të tij, ai fshihet me një ndërgjegje të pastër.

Ka situata kur fshirja ndodh më herët. Për shembull, kjo është Forward incremental me plotësime periodike. Nëse kemi krijuar kopje rezervë të plotë për dy ditët e para, dhe të enjten vendosim të vulosim depon, atëherë të premten, kur krijohet një kopje rezervë e re, skedari për të hënën do të fshihet sepse nuk ka asnjë varësi në këtë pikë. Dhe vetë pika nuk varet nga askush. Pastaj presim derisa të krijohen katër pika në shtrirjen e disponueshme dhe fshijmë tre të tjerat, të cilat nuk mund të fshihen në mënyrë të pavarur nga njëra-tjetra.

Gjërat janë më të thjeshta me Reverse Incremental. Në të, pikat më të vjetra nuk varen nga asgjë dhe mund të fshihen me siguri. Prandaj, sapo të krijohet një .vbk i ri në një masë të re, .vrb-të e vjetra do të fshihen një nga një.

Meqë ra fjala, pse krijojmë çdo herë një .vbk të ri: nëse nuk e krijonim, por vazhdonim zinxhirin e vjetër të rritjeve, atëherë .vbk i vjetër do të ngrinte për një kohë pafundësisht të gjatë në çdo mënyrë, duke parandaluar fshirjen e tij. Prandaj, u vendos që sapo shtrirja të vuloset, të krijojmë një kopje rezervë të plotë në shtrirjen e lirë.

Gjërat janë më të komplikuara me poligonin e qitjes me kapacitet.

Së pari, le të shohim mënyrën e kopjimit. Le të supozojmë se ne po krijonim në mënyrë aktive kopje rezervë për katër ditë, dhe më pas poligoni i qitjes me kapacitet u vulos. Ne nuk fshijmë asgjë, por durojmë me përulësi mbajtjen, pas së cilës i fshijmë të dhënat nga poligoni i qitjes me kapacitet.

Përafërsisht e njëjta gjë ndodh në modalitetin e lëvizjes - ne presim për retushimin, fshijmë të vjetrën në ruajtjen lokale dhe fshijmë atë të ruajtur në ruajtjen e objekteve.

Një shembull interesant me Forever forward incremental. Ne instalojmë mbajtjen në tre pika dhe fillojmë të bëjmë kopje rezervë të hënën, të cilat kopjohen rregullisht në re. Pas mbylljes së hapësirës ruajtëse, vazhdojnë të krijohen kopje rezervë, duke ruajtur tre pika, por të dhënat e ruajtura në pikën e kapacitetit mbeten të varura dhe nuk mund të fshihen. Prandaj, presim deri të enjten, kur .vbk jonë shkon përtej mbajtjes dhe vetëm atëherë fshijmë me qetësi të gjithë zinxhirin e ruajtur.

Dhe një mohim i vogël: të gjithë shembujt këtu tregohen me një makinë. Nëse keni disa prej tyre në kopjen rezervë, atëherë retushimi i tyre do të ndryshojë në varësi të faktit nëse Active Full është bërë apo jo.

Kjo është në thelb gjithçka që ka për të. Pra, le të kalojmë te veçoria më e fortë -

Pandryshueshmëria

Ashtu si me pikat e mëparshme, gjëja e parë është se çfarë problemi zgjidh ky funksion. Sapo i ngarkojmë kopjet rezervë diku për ruajtje, ekziston një dëshirë e fortë për të garantuar sigurinë e tyre, domethënë për të ndaluar fizikisht fshirjen e tyre dhe çdo modifikim gjatë një ruajtjeje të caktuar. Përfshirë administratorët, duke përfshirë llogaritë e tyre rrënjësore. Kjo ju lejon t'i mbroni ato nga dëmtimi aksidental ose i qëllimshëm. Kushdo që punon me AWS mund të ketë hasur në një veçori të ngjashme të quajtur Object Lock.

Tani le të shohim modalitetin në terma të përgjithshëm dhe më pas të gërmojmë në detaje. Në shembullin tonë, Pandryshueshmëria do të aktivizohet për poligonin tonë të qitjes me kapacitet me një mbajtje prej katër ditësh. Dhe mënyra e kopjimit është aktivizuar në kopje rezervë.

Pandryshueshmëria nuk ndërvepron me mbajtjen e përgjithshme në asnjë mënyrë. Për shembull, nuk shton pikë shtesë apo diçka të tillë. Thjesht një person nuk mund të fshijë skedarët rezervë brenda katër ditëve. Nëse bëni një kopje rezervë të hënën, do të mund ta fshini skedarin e tij vetëm të premten.

Të gjitha konceptet e shpjeguara më parë të dehidrimit, indekseve dhe meta të dhënave vazhdojnë të funksionojnë saktësisht njësoj. Por me një kusht - blloku është vendosur jo vetëm për të dhënat, por edhe për metadatat. Kjo bëhet në rast se një sulmues dinak vendos të fshijë bazën e të dhënave tona të meta të dhënave dhe të parandalojë që blloqet e të dhënave të shndërrohen në një përzierje binare të padobishme.

Tani është një kohë e mirë për të shpjeguar teknologjinë tonë të gjenerimit të bllokut. Ose gjenerimi i bllokut. Për ta bërë këtë, merrni parasysh situatën që çoi në shfaqjen e saj.

Le të marrim një shkallë kohore prej gjashtë ditësh dhe më poshtë do të shënojmë kohën e skadimit të pritshëm të pandryshueshmërisë. Ditën e parë marrim dhe krijojmë një skedar të përbërë nga blloku i të dhënave a dhe meta të dhënat e tij. Nëse pandryshueshmëria është vendosur në tre ditë, është logjike të supozohet se në ditën e katërt të dhënat do të zhbllokohen dhe fshihen. Ditën e dytë do të shtojmë një skedar të ri2, të përbërë nga blloku b me të njëjtat cilësime. Blloku a duhet të hiqet në ditën e katërt. Por në ditën e tretë ndodh diçka e tmerrshme - krijohet një skedar File3, i përbërë nga një bllok i ri d dhe një lidhje me bllokun e vjetër a. Kjo do të thotë se për një bllok dhe flamuri i pandryshueshmërisë së tij duhet të rivendoset në një datë të re, e cila zhvendoset në ditën e gjashtë. Dhe këtu lind një problem - në kopjet rezervë reale ka një numër të madh blloqesh të tilla. Dhe për të zgjatur periudhën e pandryshueshmërisë së tyre, duhet të bëni një numër të madh kërkesash çdo herë. Dhe në fakt, ky do të jetë një proces i përditshëm pothuajse i pafund, pasi me një shkallë të lartë probabiliteti do të gjejmë pirgje të mëdha blloqesh të deblikuara me secilën kopje. Çfarë do të thotë një numër i madh kërkesash nga ofruesit e ruajtjes së objekteve? E drejtë! Faturë e madhe në fund të muajit.

Dhe në mënyrë që të mos ekspozoni klientët tuaj të preferuar për para të konsiderueshme, u shpik mekanizmi i gjenerimit të bllokut. Kjo është një periudhë shtesë që ne i shtojmë periudhës së caktuar të pandryshueshmërisë. Në shembullin e mëposhtëm, kjo periudhë është dy ditë. Por ky është vetëm një shembull. Në realitet, ata përdorin formulën e tyre, e cila jep afërsisht dhjetë ditë shtesë gjatë një bllokimi mujor.

Le të vazhdojmë të shqyrtojmë të njëjtën situatë, por me gjenerimin e bllokut. Ditën e parë krijojmë skedarin1 nga blloku a dhe metadatat. Ne shtojmë periudhën e gjenerimit dhe pandryshueshmërinë - kjo do të thotë që mundësia për të fshirë skedarin do të jetë në ditën e gjashtë. Nëse në ditën e dytë krijojmë File2, i përbërë nga blloku b dhe një lidhje për bllokun a, atëherë asgjë nuk ndodh me datën e pritur të fshirjes. Ajo qëndroi si në ditën e gjashtë. Dhe kështu ne po përpiqemi të kursejmë para në numrin e kërkesave. E vetmja situatë kur afati mund të zhvendoset është nëse periudha e gjenerimit ka skaduar. Kjo do të thotë, nëse në ditën e tretë File3 i ri përmban një lidhje për të bllokuar a, atëherë gjenerata 2 do të shtohet pasi Gen1 tashmë ka skaduar. Dhe data e pritshme për fshirjen e bllokut a do të zhvendoset në ditën e tetë. Kjo na lejon të zvogëlojmë në mënyrë dramatike numrin e kërkesave për të zgjatur jetëgjatësinë e blloqeve të çdublikuara, gjë që u kursen klientëve një ton para.

Vetë teknologjia është e disponueshme për përdoruesit e pajisjeve të pajtueshme me S3 dhe S3, prodhuesit e të cilëve garantojnë që zbatimi i tyre nuk ndryshon nga ai i Amazon. Prandaj përgjigja për pyetjen legjitime pse Azure nuk mbështetet - ata kanë një veçori të ngjashme, por funksionon në nivelin e kontejnerëve, jo të objekteve individuale. Nga rruga, vetë Amazon ka bllokimin e objekteve në dy mënyra: pajtueshmëri dhe qeverisje. Në rastin e dytë, ekziston mundësia që administratori më i madh mbi administratorët dhe root mbi rrënjët, pavarësisht bllokimit të objektit, të fshijë ende të dhënat. Në rastin e pajtueshmërisë, gjithçka është gozhduar fort dhe askush nuk mund të fshijë kopjet rezervë. Edhe administratorët e Amazon (sipas deklaratave të tyre zyrtare). Kjo është mënyra që ne mbështesim.

Dhe, si zakonisht, disa lidhje të dobishme:

• në Gjenerimi i bllokut në çdo detaj.
• Të gjitha informacionet rreth Rezervimi dhe përsëritja e Veeam 10 në të mirën e saj
• О Niveli i Kapacitetit ne detaje

Burimi: www.habr.com