Capacity Tier (ose siç e quajmë ne brenda Veeam — kaptir) u shfaq që në kohët e Veeam Backup and Replication 9.5 Update 4 me emrin Archive Tier. Ideja e vendosur në të është të ofrojë mundësinë për të lëvizur kopjet rezervë, që kanë kaluar nga finesa e njohur si operacioni i rikuperimit, në depo objektive. Kjo ndihmonte në pastrimin e hapësirës së diskut për ata përdorues që kishin pak hapësirë. Kjo opsion quhej Move Mode.

Për të realizuar këtë veprim të thjeshtë (siç duket), ishte e nevojshme të përmbusheshin dy kushte: të gjitha pikat nga kopja rezervë e lëvizshme duhet të ishin jashtë kufijve të emëruar më parë të operacionit të rikuperimit, i cili përcaktohet qartë në UI. Dhe e dyta: zinxhiri duhet të jetë në atë që quhet «zinxhir i vulosur» (sealed backup chain ose Inactive Backup Chain). Kjo do të thotë që me kalimin e kohës në këtë zinxhir nuk ndodhin ndryshime.

Por në VBR v10 koncepti u pasurua me funksione të reja — u shfaq Copy Mode, Sealed Mode dhe një gjë me emrin e vështirë Immutability.

Më këto gjëra emocionuese do të flasim sot. Fillimisht për atë se si funksiononte në VBR9.5u4, pastaj për ndryshimet në versionin e dhjetë.

Dhe më falni mbrojtës të gjuhës së pastër, por ka shumë terma që nuk është e mundur t'i përkthesh.
Kështu që këtu do të ketë shumë anglicizma.
Dhe shumë gif-e.
Dhe imazhe.

Pa asnjë keqardhje. Autori i artikullit.

Siç ishte

Pra, le të fillojmë duke analizuar dritaren e rikthimit operacional dhe kopjen e vulosur (ose si quhen në dokumentacionin e Inactive Backup Chain). Pa kuptimin e tyre, nuk do të mund ta shpjegojmë më tej.

Siç e shohim në imazh, kemi një zinxhir backup me blloqe të dhënash, i cili është vendosur në nivelin Performance të repositorit SOBR, të cilit i është lidhur Capacity Tier. Dritarja jonë operacionale e backup-it është e barabartë me tre ditë.

Përkatësisht, δημιουργηθέν në të hënë .vbk vulos zinxhirin e mëparshëm, dritarja e të cilit është vendosur në tre ditë. Dhe, pra, mund të fillojmë qetësisht të dërgojmë në kapacitet tier gjithçka që është më e vjetër se këto tri ditë.

Por çfarë nënkuptohej me zinxhirin e vulosur dhe çfarë mund të dërgohej në kapacitet tier në përditësimin 4?

Për Forward Incremental, shenja e vulosjes së zinxhirit është krijimi i një backup-i të ri të plotë. Nuk ka rëndësi se si arrin të krijohet ky backup i plotë: përfshihen edhe backup-et sintetike të plotë, ashtu si dhe backup-et aktive të plota.

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

Në rastin e Forward increment me rollbeke, këto janë të gjitha rollbeket dhe .vbk, nëse në perfoemansin e extentit ka edhe një tjetër .vbk.

Tani le të shqyrtojmë variantin e punës me zinxhirët e Kopjimit të Backup-it. Këtu merret parasysh vetëm ajo që përputhet me ruajtjen GFS. Sepse gjithçka që ndodhet në zinxhirët më të rinj të kopjimit të backup-it mund të jetë në një mënyrë ose në një tjetër e modifikuar.

Tani le të hedhim një vështrim nën kapak. Aty ndodhet një proces i quajtur dehidrim – lënia e skedarëve të zbrazët backup në extent dhe zhvendosja e blloqeve nga këta skedarë në kapacitetin tir. Për optimizimin e këtij procesi përdoret një indeks i quajtur dehidrim, i cili lejon të mos kopjohen blloqet që tashmë janë kopjuar në kapacitetin tir.

Le të shohim se si duket në një rast konkret: le të supozojmë se kemi një .vbk, e cila ka dalë nga dritarja operative dhe i përket një zinxhiri të mbyllur. Kjo do të thotë që ne kemi të drejtë të transferojmë atë në kapacitetin e rezonancës. Në momentin e transferimit krijohet një skedar metadata në kapacitetin e rezonancës dhe blloqet e skedarit që po transferohet. Në skedarin e metadata në nivel referencash përshkruhet se nga cilat blloqe përbëhet skedari ynë. Në rastin e ilustruar, skedari ynë i parë përbëhet nga blloqet a, b, c dhe në metadata janë vendosur lidhjet për këto blloqe. Kur kemi një skedar të dytë .vbk, të gatshëm për transferim dhe që përbëhet nga blloqet a, b, dhe d, ne, duke analizuar indeksin e dehidratimit, kuptojmë se duhet të transferojmë vetëm bllokun d. Skedari i tij i metadata do të përmbajë lidhje për dy blloqet e mëparshme dhe një të re.

Në përputhje, procesi i mbushjes së këtyre vendeve të zbrazëta me të dhëna quhet rigjidhje. Këtu përdoret indeksi i tij i rigjidhjes, i bazuar në skedarin më të vjetër .vbk në performancën lokale. Pra, nëse përdoruesi dëshiron të rikthejë një skedar nga kapaciteti i tij, ne së pari krijojmë indeksin e bllokëve të backup-it më të vjetër të plotë dhe transferojmë nga kapaciteti i tij vetëm bllokët e munguar. Në rastin e paraqitur në imazh, për të rigjidhur FullBackup1.vbk në përputhje me indeksin e rigjidhjes, na mungon vetëm blloku C, të cilin e marrim nga kapaciteti i tij. Nëse kapaciteti i tij është një objekt ruajtjeje në re, kjo lejon kursimin e shpenzimeve kolosale.

Këtu mund të duket se kjo teknologji është identike me atë që përdoret në WAN Accelerators, por kjo është vetëm një iluzion. Në akseleratorë, deduplikimi është global, ndërsa këtu përdoret lokal brenda çdo skedari në një offset të caktuar. Kjo ndodh për shkak të ndryshimeve në detyrat që zgjidhen: këtu na nevojitet të kopjojmë skedarë të mëdhenj të backup-eve të plota, dhe sipas hulumtimeve tona, edhe nëse kalon një periudhë e madhe kohe midis tyre, një algoritëm i tillë deduplikimi jep rezultat më të mirë.

Por më shumë indekse për Zotit të indekseve! Ka edhe një indeks për rikuperimin e të dhënave! Kur nisim rikuperimin e një makine, e cila ndodhet në kapacitetin e zgjerimit, ne do të lexojmë vetëm blloqet unike të të dhënave, të cilat nuk gjenden në performancën e zgjerimit.

Siç u bë

Kjo ishte e gjitha për pjesën hyrëse. Ajo është mjaft përshkruese, por, siç u tha më lart, pa këto detaje nuk është e mundur të shpjegohet si funksionojnë funksionet e reja. Prandaj, pa më shumë hyrje, kalojmë në të parën.

Režimi i kopjimit

Shumë prej saj është e bazuar në teknologjitë ekzistuese, megjithatë sjell logjikë krejtësisht tjetër përdorimi.

Qëllimi i këtij modeli është të sigurojë që të gjitha të dhënat që ndodhen në ekstentin lokal të kenë një kopje në kapacitetin e tij.

Nëse e krahasojmë drejtpërdrejt modet Move dhe Copy, do të dalë kështu:

Mund të lëvizni vetëm një zinxhir të vulosur. Në rastin e modit kopje, merrni gjithçka, pavarësisht se çfarë ndodh në punën e kopjimit.
Lëvizja aktivizohet kur skedarët dalin jashtë kufijve të dritares së operacionit të kopjimit, ndërsa kopjimi aktivizohet menjëherë, sapo të krijohet një skedar kopje.
Për të ndjekur të dhënat e reja për kopjim, operacioni ndodh vazhdimisht, ndërsa për lëvizje ndodhte çdo 4 orë.

Në shqyrtimin e modit të ri, sugjeroj të fillojmë me shembuj të thjeshtë dhe të kalojmë në ata më të ndërlikuar.

Në rastin më të thjeshtë kemi thjesht skedarë të rinj me inkrementime që na shfaqen, dhe ne thjesht i kopjojmë ato në kapacitetin e tij. Pavarësisht nga moda që përdoret në punën e kopjimit, pavarësisht se i përket pjesës së vulosur të zinxhirit apo jo, pavarësisht se ka kaluar apo jo dritarja jonë operative. Thjesht e morëm dhe e kopjuam.

Procesi që qëndron pas kësaj është ende dehidratimi në formën siç është përshkruar më lart. Në mënyrën e kopjimit, ai gjithashtu siguron që të mos kopjojmë blloqe që tashmë janë në depot tona. Dallimi i vetëm është se në mënyrën e lëvizjes ne zëvendësojmë skedarët realë me skedarë të zbrazët, ndërsa këtu ne nuk i prekim aspak dhe i lëmë gjithçka ashtu si është. Në të tjerat, kjo është një indeks i tillë i dehidratimit, i cili përpiqet me kujdes të kursejë paratë dhe kohën tuaj.

Lindi një pyetje — nëse e shikojmë UI-në, ka mundësi të zgjidhni të dy opsionet njëkohësisht. Si do të funksionojë një mod i tillë i kombinuar?

Le të hedhim një vështrim.

Fillimi është standard: krijohet një skedar backup dhe menjëherë kopjohet. I krijohet një increment dhe gjithashtu kopjohet. Kështu ndodh deri në momentin kur kuptojmë se skedarët kanë dalë nga dritarja jonë operative dhe është shfaqur një zinxhir i vulosur. Në këtë moment kryejmë operacionin e dehidratimit dhe zëvendësojmë këta skedarë me skedarë të zbrazët. Natyrisht, nuk kopjojmë asgjë përsëri në kapacitetin e tij.

E gjithë kjo logjikë interesante është përgjegjësi e një vetëm checkbox-i në ndërfaqe: Copy backups to object storage as soon as they are created.

Pse na duhet ky mod Copy?

Është më mirë ta formuloni pyetjen kështu — nga cilat rreziqe na mbron ai? Cilin problem na ndihmon ta zgjidhim?

Përgjigjja është e qartë: sigurisht, është rikuperimi i të dhënave. Nëse ne kemi një kopje të plotë të të dhënave lokale në objektin e ruajtjes, atëherë nuk ka rëndësi çfarë ndodh me prodhimin tonë, gjithmonë mund të rikuperojmë të dhënat nga skedarët e vendosur në një Amazon të kushtueshëm.

Prandaj, le të kalojmë nëpër skenarët e mundshëm, nga më i thjeshti deri tek më kompleks.

Dëmi më i thjeshtë që mund të na ndodhi është mungesa e njërit prej skedarëve në zinxhirin e kopjeve rezervë.

Një histori më e trishtuar është kur na ka dështuar një nga ekstensat e reservoirit tonë SOBR.

Gjendja është edhe më keq kur i gjithë reservoiri SOBR bëhet i paakseshem, por kapaciteti funksionon.
Dhe gjithçka është shumë keq — është kur serveri i kopjeve rezervë vdes dhe dëshira jote e parë është të provosh të arrish deri në kufirin kanadez brenda dhjetë minutave.

Tani le të analizojmë çdo situatë veç e veç.

Kur humbëm një (po, le të ndodhin disa) skedarë rezervë, do të mjaftonte të fillonim procesin e ridiskovrimit të repositorit, dhe skedari i humbur do të zëvendësohej me një skedar bosh. Me procesin e rigjeneratës (për të cilin u fol në fillim të artikullit), përdoruesi mund të shkarkojë të dhënat nga kapaciteti në ruajtjen lokale.

Tani situata është pak më e komplikuar. Supozoni se SOBR ynë përbëhet nga dy ekstensione që punojnë në modin Performance, do të thotë se .vbk dhe .vib tona janë shpërndarë mbi to me një shtresë mjaft të pabarabartë. Dhe në një moment, një nga ekstensat bëhet i paaccessible, dhe përdoruesi duhet të rikuperojë menjëherë makinën, pjesa e të dhënave të së cilës ndodhet pikërisht në këtë ekstent.

Përdoruesi fillon wizard-in e rikuperimit, zgjedh pikën në të cilën dëshiron të rikuperojë, dhe wizard-i gjatë punës arrin në përfundimin se të gjitha të dhënat e nevojshme për rikuperim nuk janë lokal dhe prandaj duhet t'i shkarkojë nga kapaciteti. Ndërkohë, blloqet që kanë mbetur në ruajtjen lokale nuk do të shkarkohen nga reja. Falë indeksit të rikuperimit (po, edhe për të është folur në fillim të artikullit).

Një nënkategori e këtij rasti është se të gjithë depozitat e SOBR janë bërë të paarritshme. Në këtë rast nuk kemi asgjë për të kopjuar nga magazinat lokale, dhe të gjitha blloqet shkarkohen nga reja.

Dhe situata më interesante është se serveri i backup-it ka vdekur. Ka dy mundësi: admini është shumë i mirë dhe ka bërë backup konfiguracioni, ose admini është një Burotino i paditur dhe nuk ka bërë backup-in e konfiguracionit.

Në rastin e parë, është mjaft të vendosë një instalim të pastër të VBR diku dhe të rivendosë bazën e tij nga backup-i me mjetet e zakonshme. Në përfundim të këtij procesi, gjithçka do të kthehet në gjendjen e saj të zakonshme. Ose do të rikthehet sipas një prej skenarëve të sipërpërmendur.

Por më te qartë, nëse administratori është armiku i vet, ose nëse rezervimi i konfiguracionit ka pësuar një dështim legjendar, ne nuk do ta lëmë atë në fatin e tij. Për këtë rast, kemi futur një procedurë të re, të quajtur Import Object Storage. Kjo lejon që të kaloni procesin manual të rikrijimit të depot SOBR dhe ngjitjes së kapacitetit të tij me skanimin e mëpasshëm, dhe thjesht të shtoni objektin e ruajtjes në ndërfaqen e sistemit dhe të filloni procedurën e Import Storage Repository. Gjëja e vetme që mund të jetë në mes jush dhe rezervimeve tuaja është një kërkesë për të futur fjalëkalimin, nëse rezervimet tuaja janë koduar.

Këtu për Copy Mode, me siguri, është e gjitha dhe ne kalojmë në

Sealed Mode

Ideja kryesore është që në ekstensin e zgjedhur të depozitës SOBR nuk mund të shfaqen rezervime të reja. Deri në v10, ne kishim vetëm Maintenance Mode, kur ishin të ndaluara çdo aktivitet me depozitën. Një mënyrë e ashpër për të nxjerrë ruajtjen nga puna, ku ka vetëm butonin Evacuate, i cili të transportonte rezervimet një herë në një ekstens tjetër.

Një modalitet i vulosur është një version "më të butë": ne ndalojmë krijimin e kopjeve rezervë të reja dhe gradualisht fshijmë ato të vjetra sipas retention që është zgjedhur, por në proces nuk e humbasim mundësinë për tu rikuperuar nga pikat e ruajtura. Një gjë shumë e dobishme kur na skadon afati i jetës së pajisjes dhe duhet ta zëvendësojmë, ose thjesht duhet ta lirojmë për diçka më të rëndësishme, kur s'kemi ku t'i kalojmë të gjitha njëherësh. Ose s'ka mundësi të fshijmë.

Përkatësisht, parimi i funksionimit është mjaft i thjeshtë: duhet të ndaloni të gjitha operacionet write (shfaqjen e të dhënave të reja), duke lënë read (restorët) dhe delete (retention).

Të dy modalitetet mund të përdoren njëkohësisht, por duhet të kemi parasysh se Maintenance ka përparësi më të lartë.

Si një shembull, le të shqyrtojmë SOBR, që përbëhet nga dy ekstenta. Le të supozojmë se katër ditët e para krijoheshin kopje rezervë në modalitetin Forward Forever Incremental, dhe më pas ne vulosim ekstentin. Kjo çon në iniciativën për të krijuar një Active Full në ekstentin e dytë të disponueshëm. Nëse retention ynë është katër, atëherë kur e gjithë zinxhiri, që ndodhet në ekstentin e vulosur, kalon përtej kësaj, ai fshihet pa ndonjë pendesë.

Ka janë situata kur fshirja ndodh më herët. Për shembull, kjo është Forward incremental me fula periodike. Nëse dy ditët e para krijuam backup-e të plota, dhe në të enjten vendosim të vulosim depozitat, atëherë të premten, kur krijohet një backup i ri, dosja e të hënës do të fshihet sepse deri në këtë pikë nuk ka varësi. Dhe vetë pika nuk varet nga askush. Pas kësaj presim që të krijohen katër pika në qëllimin e aksesueshëm dhe fshijmë tri të mbetura, të cilat nuk mund të fshihen në mënyrë të pavarur nga njëra-tjetra.

Gjëra janë më të thjeshta me Reverse Incremental. Në të, pikat më të vjetra nuk varen nga asgjë dhe mund të fshihen në paqe. Prandaj, sa herë që krijohet një .vbk e re në një qëllim të ri, të vjetrat .vrb do të fshihen një nga një.

Për më tepër, pse çdo herë krijojmë një .vbk të re: nëse nuk e krijojmë dhe vazhdojmë me zinxhirin e vjetër të inkrementimeve, e vjetra .vbk do të ngecë për një kohë të gjatë në çdo mod, duke penguar fshirjen e saj. Prandaj u mor vendimi që sa herë që vuloset një qëllim, krijojmë një backup të plotë në një qëllim të lirë.

Gjëra janë më të komplikuara me kapacitetin e tirit.

Së pari le të shqyrtojmë modalitetin copy. Supozoni se kemi krijuar backup për katër ditë dhe pastaj kapaciteti i tir-it u mbyll. Ne nuk fshijmë asgjë, por me durim presim për mbajtjen, pas së cilës fshijmë të dhënat nga kapaciteti i tir-it.

Përgjithësisht, e njëjta gjë ndodh edhe në modalitetin move — presim për mbajtjen, fshijmë të vjetrin në ruajtjen lokale, fshijmë atë që është ruajtur në objektin e ruajtjes.

Një shembull interesant me Forever forward incremental. Vendosim mbajtjen në tre pika dhe fillojmë të bëjmë backup që nga e hëna, të cilat kopjohen me korrektësi në cloud. Pas mbylljes së ruajtjes, backup vazhdon të krijohet, duke respektuar tre pikët, por të dhënat e ruajtura në kapacitetin e tir-it mbeten të varura dhe nuk mund të fshihen. Prandaj presim deri të enjten, kur .vbk ynë kalon jashtë mbajtjes, dhe vetëm atëherë e fshijmë qetësisht të gjithë zinxhirin e ruajtur.

Dhe një sqarim i vogël: të gjitha shembujt këtu janë treguar me një makinë. Nëse keni disa në backup, atëherë mbajtja e tyre do të jetë ndryshe në varësi të kësaj nëse është bërë një Active Full apo jo.

Kështu që, në parim, kjo është e gjitha. Tani kalojmë në tipar më të fortë —

Immutability

Si me dhe pikat e mëparshme, e para është të sqarojmë se çfarë problemi zgjidh kjo funksion. Sa herë që eksportojmë kopjet rezervë për ruajtje, lind dëshira për të garantuar ruajtjen e tyre, domethënë për të ndaluar fizikisht fshirjen e tyre dhe çdo modifikim për gjatë periudhës së caktuar të ruajtjes. Kjo përfshin edhe administratorët, duke përfshirë llogaritë e tyre me privilegje të plota. Kjo mundëson mbrojtjen e tyre nga dëmtimi aksidental ose të qëllimshëm. Ata që punojnë me AWS mund të hasin një funksion të tillë nën emrin Object Lock.

Tani le të shqyrtojmë funksionin në terma të përgjithshëm, dhe pastaj të zhytim thellë në detaje. Në shembullin tonë, Immutability do të aktivizohet për kapacitetin tonë me një periudhë ruajtjeje prej katër ditësh. Ndërsa kopja rezervë do të përmbajë modin Copy.

Immutability nuk ndërvepron aspak me periudhën e përgjithshme të ruajtjes. Për shembull, ai nuk shton pikë të tjera ose gjëra të tilla. Thjesht, për gjatë katër ditëve, një person nuk mund të fshijë skedarët e kopjeve rezervë. Nëse bëhet një kopje rezervë të hënën, skedari i saj mund të fshihet vetëm të premten.

Të gjitha konceptet e shpjeguara më parë në lidhje me dehidrimin, indeksat dhe metadata vazhdojnë të funksionojnë në mënyrë të njëjtë. Megjithatë, me një kusht — blloku vendoset jo vetëm për të dhënat, por edhe për metadatat. Kjo është bërë për t'i ardhur në ndihmë rastit kur ndonjë sulmues i keq do të përpiqej të fshinte bazën tonë të metadatat dhe për të siguruar që blloqet e të dhënave të mos kthehen në një përzierje binarësh të padobishëm.

Dhe tani ka ardhur momenti fantastic për të shpjeguar teknologjinë tonë të gjenerimit të blloqeve. Ose gjenerimi i blloqeve. Për këtë, le të pranojmë një situatë që e ka sjellë në jetë atë.

Të marrim një periudhë kohore prej gjashtë ditësh dhe nga poshtë do të shënojmë kohën që pritet të skadojë immutability. Merrni dhe krijoni ditën e parë një skedar, i cili përbëhet nga një bllok të dhënash a, dhe metadatët e tij. Nëse immutability është vendosur në tri ditë, është logjike të supozojmë se në ditën e katërt të dhënat do të shihen dhe fshihen. Në ditën e dytë do të shtojmë një skedar të ri file2, i cili përbëhet nga blloku b me të njëjtat cilësime. Blloku a ende duhet të fshihet në ditën e katërt. Por në ditën e tretë ndodh një ngjarje e frikshme - krijohet skedari File3, i cili përbëhet nga një bllok të ri d dhe një lidhje me bllokun e vjetër a. Kjo do të thotë se për bllokun a flamuri immutability duhet të ri-vendoset për një afat të ri, i cili shtyhet në ditën e gjashtë. Dhe këtu lind problemi - në backupet reale të këtyre bllokëve krijohet një numër i madh. Dhe për të zgjatur periudhën immutability, duhet në çdo rast të bëni një numër të madh kërkesash. Dhe në fakt, ky do të jetë një proces pothuajse të pafund çdo ditë, pasi me një probabilitet të madh gjatë çdo kopjimi do të gjejmë ambalazhe të mëdha të bllokëve të de-duplikuar. Dhe çfarë do të thotë një numër i madh kërkesash për ofruesit e object storage? Saktë! Një faturë enorme në fund të muajit.

Dhe për të mos i detyruar klientët tanë të dashur të paguajnë shumë në mënyrë të panevojshme, është zbuluar mekanizmi i gjenerimit të bllokut. Ky është një periudhë shtesë që ne e Shtojmë në periudhën e caktuar të papërshkueshmërisë. Në shembullin më poshtë, kjo periudhë është dy ditë. Por kjo është vetëm një shembull. Në realitet, përdoret një formulë e veçantë që ofron rreth dhjetë ditë shtesë për çdo bllokim mujor.

Të njëjtën situatë do ta shohim tani, por me gjenerimin e blloqeve. Në ditën e parë krijojmë file1 nga blloku a dhe metadatave. Mblidhni periudhën e gjenerimeve dhe immutability — kjo do të thotë se 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 cili përbëhet nga blloku b dhe një link për bllokun a, atëherë data e parashikuar për fshirje nuk ndryshon. Ajo vazhdon të mbetet në ditën e gjashtë. Kështu ne mundohemi të kursim para në numrin e kërkesave. Situata e vetme kur afati mund të ndryshohet është nëse periudha e gjenerimit ka skaduar. Pra, nëse në ditën e tretë File3 i ri do të përmbajë një link për bllokun a, atëherë do të shtohet gjenerimi 2 pasi Gen1 ka skaduar. Dhe data e pritur e fshirjes së bllokut a do të zgjatet në ditën e tetë. Kjo na lejon të zvogëlojmë dramatikisht numrin e kërkesave për të zgjatur jetën e blloqeve të deduplikuara, gjë që kursen shumë para për klientët.

Сама технология доступна пользователям S3 и S3-совместимого железа, производители которого гарантируют, что их реализация не отличается от амазоновской. Отсюда ответ на законный вопрос, почему не поддерживается Azure — у них есть схожая фича, но она работает на уровне контейнеров, а не отдельных объектов. Кстати, в самом амазоне обжект лок есть в двух режимах: compliance и governance. Во втором случае остаётся возможность, чтобы самый великий админ над админами и рут над рутами, несмотря на обжект лок, всё же удалил данные. В случае compliance всё прибито гвоздями намертво и бекапы не удалить никому. Даже у админов амазона (по их официальным заявлениям). Мы поддерживаем именно этот режим.