Kapazitéit Tier (oder wéi mir et bannen Vim nennen - captir) erschéngen zréck an den Deeg vum Veeam Backup a Replikatioun 9.5 Update 4 ënner dem Numm Archive Tier. D'Iddi hannendrun ass et méiglech ze maachen Backups, déi aus der sougenannter operationeller Restauratiounsfenster gefall sinn, op d'Objetlagerung ze verschécken. Dëst huet gehollef Disk Space fir déi Benotzer déi wéineg dovun haten. An dës Optioun gouf Move Mode genannt.
Fir dës einfach (wéi et schéngt) Handlung auszeféieren, war et genuch fir zwee Konditiounen ze erfëllen: all Punkte vum geplënnerte Backup mussen ausserhalb vun de Grenze vun der uewe genannter operationell Restauratiounsfenster sinn, déi explizit an der UI festgeluecht ass. An zweetens: d'Kette muss an der sougenannter "versiegelter Form" sinn (versiegelt Backup Kette oder Inactive Backup Chain). Dat ass, keng Ännerunge geschéien an dëser Kette iwwer Zäit.
Awer am VBR v10 gouf d'Konzept mat neie Funktiounen ergänzt - Copy Mode, Sealed Mode an eng Saach mat dem schwieregen-ze-pronounce Numm Immutability erschéngt.
Dëst sinn déi faszinante Saachen iwwer mir haut schwätzen. Als éischt, iwwer wéi et an VBR9.5u4 geschafft huet, an dann iwwer d'Ännerungen an der zéngter Versioun.
A dierf d'Championen vun der reiner Sprooch mir verzeien, awer et ginn ze vill Begrëffer déi net iwwersat kënne ginn.
Also et wäert eng Tonn vun Anglisismus hei sinn.
A vill Giffe.
A Biller.
- Ouni de geringsten bedaueren. Auteur vum Artikel.
Wéi et war
Gutt, loosst eis ufänken mat der Analyse vun der operationeller Restauratiounsfenster a versiegelte Backup (oder wéi se an der Inactive Backup Chain Dokumentatioun genannt ginn). Ouni hiert Verständnis ass weider Erklärung net méiglech.
Wéi mir am Bild gesinn, hu mir eng Zort Backupkette mat Datenblocken, déi op der Performance Tier SOBR vum Repository läit, mat deem de Capacity Tier verbonnen ass. Eis operationell Backupfenster ass dräi Deeg.
Deementspriechend ass de .vbk, deen um Méindeg erstallt gouf, d'virdrun Kette versiegelt, där hir Fënster op dräi Deeg gesat ass. An dat heescht, Dir kënnt sécher ufänken alles méi al wéi dës dräi Deeg op d'Schéiss ze transportéieren.
Awer wat war genee vun enger zouene Kette gemengt a wat konnt an d'Kapazitéit Schéisserei am Update 4 geschéckt ginn?
Fir Forward Incremental ass en Zeeche fir d'Kette ze versiegelen d'Schafung vun engem neie komplette Backup. An et ass egal wéi dëse komplette Backup kritt gëtt: souwuel synthetesch voll an aktiv voll Backupe ginn ugesinn.
Am Fall vun Reverse sinn dat all Dateien déi net an d'Operatiounsfenster falen.
Am Fall vun Forward increment mat rollbacks, dës sinn all rollbacks an .vbk, wann et aner .vbk op der Leeschtung Ausmooss
Loosst eis elo d'Optioun betruechte fir mat Backup Copy Ketten ze schaffen. Nëmmen Artikelen, déi ënner GFS Retention falen, goufen hei transportéiert. Well alles an méi rezent Backupsatellit Ketten gespäichert kann an déi eng oder aner Manéier geännert ginn.
Loosst eis elo ënner der Hood kucken. Do geschitt e Prozess genannt Dehydratioun - eidel Backupdateien op d'Ausmooss hannerloossen an d'Blöcke vun dëse Dateien op d'Kapazitéit Schéissbereich zéien. Fir dëse Prozess ze optimiséieren, gëtt de sougenannte Dehydratiounsindex benotzt, wat Iech erlaabt Iech ze vermeiden datt d'Blocke kopéiert ginn, déi schonn op d'Kapazitéit Schéissbereich kopéiert goufen.
Loosst d'gesinn wéi dat mat engem Beispill ausgesäit: Loosst d'soen, datt mir eng .vbk hunn, datt aus der Transaktioun Fënster koum a gehéiert zu engem versiegelt Kette. Dat heescht, datt mir all Recht hunn et op d'Kapazitéit shooting Beräich ze plënneren. Zu der Zäit vun der Beweegung gëtt eng Metadatendatei am Kapazitéitstreck a Blocken vun der transferéierter Datei erstallt. De Link-Niveau Metadatendatei beschreift aus wéi enge Blocken eis Datei besteet. Am Fall am Bild besteet eis éischt Datei aus Blocken a, b, c an d'Metadaten enthalen Linken op dës Blocks. Wann mir eng zweet .vbk Fichier hunn, prett ze plënneren a besteet aus spären a, b an d, mir, analyséieren der Dehydratioun Index, verstoen, datt nëmmen Spär d muss transferéiert ginn. A seng Metadatendatei enthält Linken op zwee fréier Blocks an een neien.
Deementspriechend gëtt de Prozess fir dës eidel Plazen zréck mat Daten ze fëllen Rehydratioun genannt. Et benotzt schonn seng eege rehydration Index, baséiert op den eelste .vbk Fichier op der lokal Leeschtung Ausmooss. Dat ass, wann de Benotzer wëllt e Fichier aus der Kapazitéit shooting Range zréck, mir schafen éischt en Index vun de spären vun der eelste voll Backupsatellit an Transfert nëmmen déi vermësst spären aus der Kapazitéit shooting Galerie. Am Fall, deen am Bild presentéiert gëtt, fir FullBackup1.vbk no dem Rehydratiounsindex ze rehydréieren, brauche mir nëmmen de Block C, dee mir aus der Kapazitéit schéissen. Wann e Stockage Wollek Objet déngt als Kapazitéit shooting Gamme, dëst erlaabt Iech enorm Zomm Suen ze retten.
Hei kann et schéngen datt dës Technologie identesch ass mat deem wat a WAN Acceleratoren benotzt gëtt, awer et schéngt nëmmen esou. A Beschleuniger ass Deduplikatioun global; hei gëtt lokal Deduplikatioun an all Datei op engem spezifesche Offset benotzt. Dëst geschitt wéinst dem Ënnerscheed an den Aufgaben, déi geléist ginn: hei musse mir grouss voll Backupdateien kopéieren, a laut eiser Fuerschung, och wann eng laang Zäit tëscht hinnen passéiert, gëtt dësen Deduplication Algorithmus dat bescht Resultat.
Awer méi Indexer fir de Gott vun den Indexen! Et gëtt och en Index fir Daten Erhuelung! Wa mir ufänken eng Maschinn ze restauréieren, déi am Kapazitéitstreck läit, liesen mir nëmmen eenzegaarteg Dateblocken, déi net am Performance Dash sinn.
Wéi ass et geschitt?
Dat ass alles fir den Aféierungs Deel. Et ass zimlech detailléiert, awer wéi uewen ernimmt, ouni dës Detailer wäert et net méiglech sinn ze erklären wéi déi nei Funktiounen funktionnéieren. Dofir, ouni weider Ado, loosst eis op déi éischt goen.
Kopie Modus
Et ass gréisstendeels op existéierend Technologien baséiert, awer huet eng komplett aner Benotzungslogik.
Den Zweck vun dësem Modus ass sécherzestellen datt all Donnéeën op der lokaler Ausmooss eng Kopie am Kapazitéitstreck hunn.
Wann Dir d'Move and Copy Modi head-on vergläicht, gesäit et esou aus:
- Nëmmen déi versiegelt Kette kann geréckelt ginn. Am Fall vun engem Kopie Modus gëtt absolut alles iwwerdroen, egal wat an der Backupsatellit Aarbecht geschitt.
- D'Bewegung gëtt ausgeléist wann d'Dateien iwwer d'Grenze vun der operationeller Backupfenster erausgoen, an d'Kopie gëtt ausgeléist soubal d'Backupdatei erscheint.
- D'Iwwerwaachung vun neien Daten fir d'Kopie geschitt dauernd, a fir d'Bewegung gouf se eemol all 4 Stonnen ausgeléist.
Wann Dir den neie Modus berücksichtegt, proposéiere ech vun einfache Beispiller op komplexe ze plënneren.
Am heefegste Fall hu mir einfach nei Dateien mat Inkremente, a mir kopéieren se einfach op d'Kapazitéit Schéissbereich. Egal wéi de Modus an der Backup-Job benotzt gëtt, egal ob et zum versiegelten Deel vun der Kette gehéiert oder net, egal ob eis Operatiounsfenster ofgelaf ass. Si hunn et just geholl a kopéiert.
De Prozess hannert dësem ass ëmmer nach Dehydratioun wéi uewen beschriwwen. Am Kopiemodus mécht et och sécher datt mir keng Blocks kopéieren déi schonn op eiser Späichere sinn. Deen eenzegen Ënnerscheed ass datt wa mir am Filmmodus richteg Dateie mat Dummy-Dateien ersat hunn, hei beréieren mir se op kee Fall a loossen alles sou wéi et ass. Soss ass et genau deeselwechten Dehydratiounsindex, dee virsiichteg probéiert Är Suen an Zäit ze spueren.
D'Fro stellt sech - wann Dir d'UI kuckt, gëtt et eng Méiglechkeet fir béid Optiounen zur selwechter Zäit ze wielen. Wéi wäert esou e kombinéierte Modus funktionnéieren?
Loosse mer et erausfannen.
Den Ufank ass Standard: eng Backupdatei gëtt erstallt an direkt kopéiert. En Inkrement gëtt dorun erstallt an och kopéiert. Dëst geschitt bis de Moment wou mir mierken datt d'Dateien eis Operatiounsfenster verlooss hunn an eng versiegelt Kette erschéngt. Zu dësem Zäitpunkt maache mir eng Dehydratiounsoperatioun an ersetzen dës Dateie mat Dummy-Dateien. Natierlech kopéieren mir näischt erëm op d'Kapazitéit Schéisserei.
All dës faszinéierend Logik ass verantwortlech fir nëmmen eng Checkbox an der Interface: Kopie Backups op Objektlagerung soubal se erstallt sinn.
Firwat brauche mir dëse Copy Modus?
Et ass nach besser d'Fro op dës Manéier ëmzeschreiwen: vu wéi enger Risike si mir geschützt mat senger Hëllef? Wéi ee Problem hëlleft et eis ze léisen?
D'Äntwert ass offensichtlech: natierlech ass dëst Daten Erhuelung. Wa mir eng komplett Kopie vun lokalen Donnéeën op der Objektspeicherung hunn, dann egal wat mat eisem Produkt geschitt, kënne mir ëmmer Daten aus Dateien restauréieren, déi an der bedingter Amazon läit.
Also loosst eis duerch déi méiglech Szenarie goen, vun den einfachsten bis déi méi komplex.
Deen einfachsten Ongléck, deen op eise Kapp fale kann, ass d'Onzougänglechkeet vun engem vun de Dateien an der Backupkette.
Eng méi traureg Geschicht ass datt ee vun den Ausmooss vun eisem SOBR Repository gebrach ass.
Et gëtt nach méi schlëmm wann de ganze SOBR Repository onzougänglech ginn ass, awer d'Kapazitéit Shooting Range funktionnéiert.
An alles ass wierklech schlecht - dëst ass wann de Backup Server stierft an Ären éischte Wonsch ass ze probéieren an zéng Minutten op d'kanadesch Grenz ze lafen.
Loosst eis elo all Situatioun separat kucken.
Wa mir eng (a souguer e puer) Backupdateien verluer hunn, da brauche mir just de Repository-Rescan-Prozess unzefänken, an déi verluere Datei gëtt duerch eng Dummy-Datei ersat. A benotzt de Rehydratiounsprozess (deen am Ufank vum Artikel diskutéiert gouf), wäert de Benotzer fäeg sinn Daten aus der Kapazitéit Schéissbereich op d'lokal Lagerung erofzelueden.
Elo ass d'Situatioun méi komplizéiert. Loosst eis unhuelen datt eise SOBR aus zwee Ausmooss besteet, déi am Performance-Modus lafen, dat heescht datt eis .vbk an .vib an enger éischter ongläicher Schicht iwwer si verbreet sinn. An iergendwann gëtt ee vun de Moossnamen net erreechbar, an de Benotzer muss dréngend d'Maschinn restauréieren, en Deel vun den Donnéeën, déi genee op dësem Ausmooss läit.
De Benotzer lancéiert d'Erhuelung Wizard, wielt de Punkt op deen hie wëll restauréieren, an de Wizard, während schafft, kënnt zu der Realisatioun datt hien net all d'Donnéeën néideg fir d'Erhuelung lokal ze hunn an dofir muss aus der Kapazitéit Shooting erofgeluede ginn Galerie. Zur selwechter Zäit ginn d'Blocker, déi op der lokaler Späichere bleiwen, net vun der Wollek erofgelueden. Herrlechkeet fir de Restauratiounsindex (jo, et gouf och am Ufank vum Artikel ernimmt).
En Ënnertyp vun dësem Fall ass datt de ganze SOBR Repository onzougänglech gouf. An dësem Fall hu mir näischt aus der lokaler Späichere ze kopéieren, an all Blocks ginn aus der Wollek erofgelueden.
An déi interessantst Situatioun ass datt de Backupserver gestuerwen ass. Et ginn zwou Méiglechkeeten hei: den Admin ass super an huet Konfiguratiounsbackups gemaach, an den Admin ass e béise Pinocchio selwer an huet keng Konfiguratiounsbackups gemaach.
Am éischte Fall ass et genuch fir hien einfach eng propper Installatioun vu VBR iergendwou z'installéieren an seng Datebank aus engem Backup mat Standardmëttelen ze restauréieren. Um Enn vun dësem Prozess gëtt alles zréck an normal. Oder et gëtt no engem vun den Szenarien hei uewen restauréiert.
Awer wann den Administrateur entweder säin eegene Feind ass, oder d'Konfiguratiounsbackup huet och en epesche Versoen erlieft, dann och hei wäerte mir him net un d'Barmhäerzegkeet vum Schicksal iwwerloossen. Fir dëse Fall hu mir eng nei Prozedur mam Numm Import Object Storage agefouert. Et erlaabt Iech de Prozess vun der manueller Erstellung vun engem SOBR Repository ze iwwersprangen an eng Kapazitéit Schéissbereich ze befestigen mat spéider Rescan, an einfach e Späicherobjekt op d'Vim Interface bäizefügen an d'Import Storage Repository Prozedur auszeféieren. Dat eenzegt wat am Wee tëscht Iech an Äre Backups stoe kann ass eng Ufro fir e Passwuert anzeginn wann Är Backups verschlësselt sinn.
Dëst ass méiglecherweis alles ëm de Copy Mode a mir fuere weider
Versiegelt Modus
D'Haaptidee ass datt nei Backups net op der gewielter SOBR Ausmooss vum Repository erscheinen kënnen. Virun v10 hu mir nëmmen den Maintenance Mode, wann all Aarbecht mam Repository komplett verbueden ass. Eng Zort Hardcore Modus fir d'Späichere auszeschalten, wou nëmmen den Evacuate Knäppchen verfügbar ass, deen Backups an engem anere Mooss eng Kéier transportéiert.
A Sealed Modus ass eng Zort "mëll" Optioun: mir verbidden d'Schafung vun neie Backups a lues a lues al ze läschen no der gewielter Retention, awer am Prozess verléiere mir d'Fäegkeet net aus gespäichert Punkten ze restauréieren. Eng ganz nëtzlech Saach wa mir entweder e Stéck Hardware no um Enn vu sengem Liewen hunn an et musse ersetzen, oder mir mussen et just befreien fir eppes méi Wichtegs, awer et gëtt néierens et ze huelen an alles op eemol ze réckelen. Oder et kann net geläscht ginn.
Deementspriechend ass de Prinzip vun der Operatioun ganz einfach: et ass néideg fir all Schreifoperatioune ze verbidden (d'Erscheinung vun neien Donnéeën), d'Liesen ze verloossen (Restauratioun) a Läschen (Retentioun).
Béid Modi kënne gläichzäiteg benotzt ginn, awer bedenkt datt d'Maintenance méi héich Prioritéit huet.
Als Beispill betruecht e SOBR aus zwee Ausmooss. Loosst eis dovun ausgoen datt mir fir déi éischt véier Deeg Backups am Forward Forever Incremental Modus erstallt hunn, an dann d'Ausmooss versiegelen. Dëst féiert zu der Tatsaach datt mir d'Schafung vun engem neien aktive Voll op der zweeter verfügbarer Ausmooss initiéieren. Wann eis Retentioun véier ass, da gëtt d'ganz Kette op der versiegelt Ausmooss iwwer seng Grenzen erausgeet, gëtt se mat engem klore Gewësse geläscht.
Et gi Situatiounen, wou d'Läschung fréier geschitt. Zum Beispill ass dëst Forward inkrementell mat periodesche Vollen. Wa mir voll Backups fir déi éischt zwee Deeg erstallt hunn, an en Donneschdeg decidéieren mir de Repository ze versiegelen, dann e Freideg, wann en neie Backup erstallt gëtt, gëtt d'Datei fir de Méindeg geläscht well et gi keng Ofhängegkeeten zu dësem Punkt. An de Punkt selwer hänkt net vu jidderengem of. Da waarden mir bis véier Punkten op der verfügbaren Ausmooss erstallt ginn an déi aner dräi läschen, déi net onofhängeg vuneneen geläscht kënne ginn.
D'Saachen si méi einfach mat Reverse Incremental. An et hänken déi eelst Punkte vun näischt of a kënne sécher geläscht ginn. Dofir, soubal en neien .vbk op engem neien Ausmooss erstallt gëtt, ginn déi al .vrbs een nom aneren geläscht.
Iwwregens, firwat kreéiere mir all Kéier eng nei .vbk: wa mir et net erstallt hunn, awer déi al Kette vun Inkremente weidergespillt hunn, da géif déi al .vbk fir eng onendlech laang Zäit an all Modus afréieren, a verhënnert seng Läschung. Dofir gouf decidéiert datt soubal d'Ausmooss versiegelt ass, mir e komplette Backup op der fräier Ausmooss erstellen.
D'Saachen si méi komplizéiert mat der Kapazitéit Schéissbereich.
Als éischt kucke mer de Kopiemodus. Loosst eis unhuelen datt mir aktiv Backups fir véier Deeg erstallt hunn, an dann ass d'Kapazitéit Schéissbereich versiegelt. Mir läschen näischt, awer bescheiden erhalen d'Retentioun, duerno läschen mir d'Donnéeën aus der Kapazitéit Schéissbereich.
Ongeféier déiselwecht Saach geschitt am Beweegmodus - mir waarden op d'Retouchen, läschen déi al an der lokaler Späichere, a läschen deen, deen an der Objektspeicher gespäichert ass.
En interessant Beispill mat Forever Forward inkrementell. Mir installéieren Retentioun op dräi Punkten a fänken um Méindeg Backups ze maachen, déi regelméisseg an d'Wollek kopéiert ginn. No der Versiegelung vun der Späichere ginn d'Backups weider erstallt, dräi Punkten behalen, awer d'Donnéeën, déi am Kapazitéitstrecken gespäichert sinn, bleiwen ofhängeg a kënnen net geläscht ginn. Dofir waarden mir bis en Donneschdeg, wann eis .vbk iwwer d'Retentioun geet, a nëmmen dann läsche mir roueg déi ganz gespäichert Kette.
An eng kleng Verzichterklärung: all Beispiller hei sinn mat enger Maschinn gewisen. Wann Dir e puer vun hinnen an Ärem Backup hutt, da wäert hir Retouch ënnerscheeden ofhängeg ob Active Full gemaach gouf oder net.
Dat ass am Fong alles wat et ass. Also loosst eis op déi meescht Hardcore Feature weidergoen -
Onverännerlechkeet
Wéi mat de fréiere Punkten, ass déi éischt Saach, wat de Problem dës Funktioun léist. Soubal mir eis Backups iergendwou eropluede fir ze späicheren, ass et e staarke Wonsch fir hir Sécherheet ze garantéieren, dat heescht, hir Läschung an all Ännerung während enger bestëmmter Retention kierperlech ze verbidden. Inklusiv Administrateuren, och ënner hire Rootkonten. Dëst erlaabt Iech hinnen aus zoufälleg oder virsiichteg Schued ze schützen. Jiddereen, dee mat AWS schafft, ass vläicht eng ähnlech Feature mam Numm Object Lock begéint.
Loosst eis elo de Modus am allgemengen kucken, an dann an d'Detailer verdéiwen. An eisem Beispill gëtt d'Immutabilitéit fir eis Kapazitéit Schéissbereich mat enger Retention vu véier Deeg aktivéiert. An de Copy Modus ass am Backup aktivéiert.
D'Immutabilitéit interagéiert op kee Fall mat allgemenger Retention. Zum Beispill gëtt et keng extra Punkten oder eppes wéi dat. Et ass just datt eng Persoun keng Backupdateien bannent véier Deeg kann läschen. Wann Dir e Méindeg e Backup mécht, kënnt Dir seng Datei eréischt e Freideg läschen.
All virdru erkläert Konzepter vun Dehydratioun, Indexen a Metadaten funktionnéieren weider genau d'selwecht. Awer mat enger Bedingung - de Block ass net nëmme fir Daten gesat, awer och fir Metadaten. Dëst gëtt gemaach am Fall wou e lëschtegen Ugräifer decidéiert eis Metadatendatebank ze läschen an ze verhënneren datt Dateblocken an nëtzlos binäre Mush ginn.
Elo ass eng super Zäit eis Block Generatioun Technologie z'erklären. Oder Block Generatioun. Fir dëst ze maachen, betruecht d'Situatioun, déi zu sengem Erscheinungsbild gefouert huet.
Loosst eis eng Zäitskala vu sechs Deeg huelen an drënner markéiere mir d'Zäit vum erwaarten Oflaf vun der Onverännerlechkeet. Um éischten Dag huelen a kreéieren mir e Fichier deen aus Datenblock a a seng Metadaten besteet. Wann d'Immutabilitéit op dräi Deeg gesat gëtt, ass et logesch ze iwwerhuelen datt um véierten Dag d'Donnéeën opgespaart a geläscht ginn. Um zweeten Dag addéiere mer en neien Datei2, besteet aus Block b mat de selwechten Astellungen. Block a muss nach um véierten Dag ewechgeholl ginn. Awer um drëtten Dag geschitt eppes schrecklech - eng File3 Datei gëtt erstallt, besteet aus engem neie Block d an engem Link zum alen Block a. Dat heescht, datt fir e Spär a seng immutability Fändel muss op en neien Datum zréckgesat ginn, déi op de sechsten Dag geplënnert ass. An hei entsteet e Problem - an echte Backups ginn et eng grouss Zuel vu sou Blocken. A fir hir Immutabilitéitsperiod ze verlängeren, musst Dir all Kéier eng riesech Unzuel vun Ufroen maachen. An tatsächlech wäert dëst e bal endlosen deegleche Prozess sinn, well mat engem héije Grad vu Wahrscheinlechkeet wäerte mir mat all Kopie hefteg Stack vun deduplizéierte Blocks fannen. Wat heescht eng grouss Zuel vun Ufroe vun Objet Stockage Ubidder? Riets! Enorme Rechnung um Enn vum Mount.
A fir net aus dem bloe Är Liiblingscliente fir substantiell Suen auszesetzen, gouf de Blockgeneratiounsmechanismus erfonnt. Dëst ass eng zousätzlech Period déi mir der festgeluegter Immutabilitéitsperiod addéieren. Am Beispill hei ënnen ass dës Period zwee Deeg. Mä dëst ass just e Beispill. A Wierklechkeet benotzen se hir eege Formel, déi ongeféier zéng zousätzlech Deeg während engem Mount Spär gëtt.
Loosst eis weider déi selwecht Situatioun betruechten, awer mat Blockgeneratioun. Um éischten Dag erstellen mir Datei1 vum Block a a Metadaten. Mir addéieren d'Generatiounsperiod an d'Immutabilitéit - dat heescht datt d'Méiglechkeet fir d'Datei ze läschen um sechsten Dag ass. Wa mir um zweeten Dag File2 erstellen, besteet aus Block b an engem Link fir a blockéieren, da geschitt näischt mam erwaarten Läschdatum. Si stoung wéi si um sechsten Dag. An domat versichen mir op d'Zuel vun den Ufroen Geld ze spueren. Déi eenzeg Situatioun wou d'Deadline verréckelt ka ginn ass wann d'Generatiounsperiod ofgelaf ass. Dat ass, wann um drëtten Dag déi nei File3 e Link enthält fir a ze blockéieren, da gëtt d'Generatioun 2 derbäigesat well Gen1 scho ofgelaf ass. An den erwaarten Datum fir de Block a ze läschen wäert op den aachten Dag verschwannen. Dëst erlaabt eis d'Zuel vun den Ufroen dramatesch ze reduzéieren fir d'Liewensdauer vun deduplizéierte Blocken ze verlängeren, wat de Clienten eng Tonne Suen spuert.
D'Technologie selwer ass verfügbar fir Benotzer vu S3 an S3-kompatibel Hardware, deenen hir Hiersteller garantéieren datt hir Implementatioun net vun Amazon ënnerscheet. Dofir ass d'Äntwert op déi legitim Fro firwat Azure net ënnerstëtzt gëtt - si hunn eng ähnlech Feature, awer et funktionnéiert um Niveau vun de Container, net individuell Objekter. Iwwregens, Amazon selwer huet Objektsperre an zwee Modi: Konformitéit a Gouvernance. Am zweete Fall bleift et d'Méiglechkeet datt de gréisste Administrateur iwwer Administrateuren a Root iwwer Wuerzelen, trotz der Objektsperre, d'Donnéeën ëmmer nach läscht. Am Fall vun der Konformitéit gëtt alles fest agepaakt a kee kann d'Backups läschen. Och Amazon Admins (no hiren offiziellen Aussoen). Dëst ass de Modus dee mir ënnerstëtzen.
An, wéi gewinnt, e puer nëtzlech Linken:
- op an all Detail.
- All Informatiounen iwwert op seng bescht
- О am Detail
Source: will.com