A Capacity Tier (vagy ahogy a Vim belsejében hívjuk – captir) a Veeam Backup and Replication 9.5 Update 4 idejében jelent meg Archívum Tier néven. A mögöttes ötlet az, hogy lehetővé tegyék az úgynevezett működési visszaállítási ablakból kiesett biztonsági másolatok objektumtárba helyezését. Ez segített felszabadítani a lemezterületet azoknak a felhasználóknak, akiknek kevés volt. És ezt az opciót Move Mode-nak hívták.

Ennek az egyszerű (ahogyan látszik) műveletnek a végrehajtásához elég volt két feltétel teljesítése: az áthelyezett biztonsági mentés minden pontjának kívül kell lennie a fent említett működési visszaállítási ablak határain, amely kifejezetten az UI-ban van beállítva. Másodszor: a láncnak úgynevezett „lezárt formában” kell lennie (lezárt biztonsági lánc vagy inaktív biztonsági lánc). Vagyis ebben a láncban nem történik változás az idő múlásával.

A VBR v10-ben azonban a koncepció új funkciókkal egészült ki - másolási mód, lezárt mód és egy nehezen kiejthető Immutability nevű dolog jelent meg.

Ezek azok a lenyűgöző dolgok, amelyekről ma fogunk beszélni. Először arról, hogyan működött a VBR9.5u4-ben, majd a tizedik verzió változásairól.

És a tiszta nyelv bajnokai bocsássanak meg nekem, de túl sok olyan kifejezés van, amelyet nem lehet lefordítani.
Szóval rengeteg anglicizmus lesz itt.
És sok gif.
És képek.

• A legkisebb megbánás nélkül. A cikk szerzője.

Mint volt

Nos, kezdjük a működési visszaállítási ablak és a lezárt biztonsági másolat elemzésével (vagy ahogy az Inactive Backup Chain dokumentációjában nevezik). Megértésük nélkül további magyarázat nem lehetséges.

Ahogy a képen is látjuk, van egyfajta biztonsági mentési láncunk adatblokkokkal, amely annak a tárolónak a SOBR teljesítményszintjén található, amelyhez a Capacity Tier kapcsolódik. A biztonsági mentés időtartama három nap.

Ennek megfelelően a hétfőn létrehozott .vbk lezárja az előző láncot, amelynek ablaka három napra van beállítva. Ez pedig azt jelenti, hogy nyugodtan elkezdheti a lőtérre szállítani mindent, ami ennél a három napnál régebbi.

De mit is jelentett pontosan a lezárt lánc, és mit lehetett küldeni a kapacitás lőterére a 4-es frissítésben?

A Forward Incremental esetében a lánc lezárásának jele egy új teljes tartalék létrehozása. És nem mindegy, hogyan készül ez a teljes biztonsági mentés: a szintetikus teljes és az aktív teljes biztonsági mentéseket egyaránt figyelembe veszik.

A Reverse esetében ezek mind olyan fájlok, amelyek nem esnek a működési ablakba.

A visszagörgetésekkel járó Forward növekmény esetén ezek mind visszagörgetések és .vbk, ha van másik .vbk a teljesítmény mértékén.

Most nézzük meg a Backup Copy láncokkal való együttműködés lehetőségét. Ide csak a GFS megőrzés alá tartozó tárgyakat szállították. Mert minden, ami az újabb biztonsági másolati láncokban tárolt, így vagy úgy megváltoztatható.

Most pedig nézzünk a motorháztető alá. Ott egy kiszáradásnak nevezett folyamat megy végbe – üres biztonsági mentési fájlok maradnak a kiterjedésben, és ezekből a fájlokból blokkokat húznak a kapacitás lőtérre. Ennek a folyamatnak az optimalizálására az úgynevezett dehidratációs indexet használják, amely lehetővé teszi, hogy elkerülje a már átmásolt blokkok átmásolását a kapacitási lőtérre.

Nézzük meg, hogyan néz ki ez egy példán: Tegyük fel, hogy van egy .vbk-nk, amely a tranzakciós ablakból jött ki, és egy lezárt lánchoz tartozik. Ez azt jelenti, hogy minden jogunk megvan ahhoz, hogy a kapacitás lőtérre helyezzük. Az áthelyezéskor egy metaadatfájl jön létre az átvitt fájl kapacitásvonalában és blokkjaiban. A linkszintű metaadatfájl leírja, hogy fájlunk milyen blokkokból áll. A képen látható esetben az első fájlunk a, b, c blokkokból áll, és a metaadatok ezekre a blokkokra mutató hivatkozásokat tartalmaznak. Amikor van egy második .vbk fájlunk, amely készen áll az a, b és d blokkokból áll, a dehidratációs indexet elemezve megértjük, hogy csak a d blokkot kell átvinni. A metaadatfájlja pedig két korábbi és egy új blokkra mutató hivatkozásokat fog tartalmazni.

Ennek megfelelően az üres terek adatokkal való kitöltésének folyamatát rehidratációnak nevezzük. Már saját rehidratációs indexet használ, amely a legrégebbi .vbk fájlon alapul a helyi teljesítmény mértékére vonatkozóan. Azaz, ha a felhasználó a kapacitás lőtérről szeretne visszaküldeni egy fájlt, akkor először létrehozunk egy indexet a legrégebbi teljes mentés blokkjaiból, és csak a hiányzó blokkokat helyezzük át a kapacitási lőtárból. A képen bemutatott esetben a FullBackup1.vbk rehidratációs index szerinti rehidratálásához csak a C blokkra van szükségünk, amit a kapacitás lőtérről veszünk. Ha egy tárolófelhő-objektum kapacitási lőtérként szolgál, ezzel hatalmas összegeket takaríthat meg.

Itt úgy tűnhet, hogy ez a technológia megegyezik a WAN-gyorsítóknál használt technológiával, de csak úgy tűnik. A gyorsítókban a deduplikáció globális; itt a helyi deduplikációt minden fájlon belül egy meghatározott eltolásban használják. Ez a megoldandó feladatok különbözőségéből adódik: itt nagy, teljes biztonsági mentési fájlokat kell másolnunk, és kutatásunk szerint még akkor is, ha hosszú idő telik el közöttük, ez a deduplikációs algoritmus adja a legjobb eredményt.

De még több indexet az indexek istenének! Adat-helyreállításhoz is van index! Amikor elkezdjük a kapacitás-kötőjelben található gép visszaállítását, csak azokat az egyedi adatblokkokat olvassuk be, amelyek nincsenek a teljesítmény-kötőjelben.

Hogyan lett belőle

A bevezető részhez ennyi. Elég részletes, de mint fentebb említettük, ezen részletek nélkül nem lehet elmagyarázni, hogyan működnek az új funkciók. Ezért minden további nélkül térjünk át az elsőre.

Másolási mód

Nagyrészt a meglévő technológiákra épül, de teljesen más logikát hordoz magában. 

Ennek az üzemmódnak az a célja, hogy minden helyi kiterjedésű adatnak legyen másolata a kapacitásvonalban.

Ha összevetjük az áthelyezési és másolási módokat, az így fog kinézni:

• Csak a lezárt lánc mozgatható. Másolási mód esetén abszolút minden átkerül, függetlenül attól, hogy mi történik a mentési munkában.
• Az áthelyezés akkor indul el, ha a fájlok túllépnek a műveleti biztonsági mentési ablak határain, a másolás pedig azonnal elindul, amint a biztonsági mentési fájl megjelenik.
• Az új adatok másolásra való figyelése folyamatosan történik, az áthelyezéshez pedig 4 óránként indult el.

Az új mód megfontolása során azt javaslom, hogy az egyszerű példákról térjünk át az összetett példákra.

A legáltalánosabb esetben egyszerűen csak vannak új fájljaink növekményekkel, és egyszerűen átmásoljuk őket a kapacitás lőtérre. Függetlenül attól, hogy milyen üzemmódot használunk a mentési munkában, függetlenül attól, hogy az a lánc lezárt részéhez tartozik-e vagy sem, függetlenül attól, hogy a működési ablakunk lejárt-e. Csak elvitték és lemásolták.

A folyamat mögött továbbra is a fent leírt dehidratáció áll. Másolás módban arra is ügyel, hogy ne másoljunk le olyan blokkokat, amelyek már a tárhelyünkön vannak. Az egyetlen különbség az, hogy ha film módban valódi fájlokat cseréltünk le fiktív fájlokra, akkor itt semmilyen módon nem nyúlunk hozzájuk, és mindent úgy hagyunk, ahogy van. Ellenkező esetben ez pontosan ugyanaz a kiszáradási index, amely óvatosan igyekszik pénzt és időt megtakarítani.

Felmerül a kérdés - ha megnézi a felhasználói felületet, akkor lehetőség van mindkét lehetőség egyidejű kiválasztására. Hogyan fog működni egy ilyen kombinált mód?

Nézzük meg.

A kezdet szabványos: egy biztonsági mentési fájl azonnal létrejön és másolódik. Létrejön hozzá egy növekmény, és másolja is. Ez egészen addig a pillanatig megtörténik, amikor rájövünk, hogy a fájlok elhagyták a működési ablakot, és megjelent egy lezárt lánc. Ezen a ponton dehidratálási műveletet hajtunk végre, és ezeket a fájlokat álreszelőkkel helyettesítjük. Természetesen nem másolunk át semmit a kapacitás lőtérre.

Mindez a lenyűgöző logika egyetlen jelölőnégyzetért felelős a felületen: Másolja a biztonsági másolatokat az objektumtárolóba, amint létrejöttek.

Miért van szükségünk erre a másolási módra?

Még jobb így átfogalmazni a kérdést: milyen kockázatoktól védünk meg a segítségével? Milyen probléma megoldásában segít?

A válasz nyilvánvaló: természetesen ez adat-helyreállítás. Ha van egy teljes másolatunk a helyi adatokról az objektumtárolón, akkor bármi történjen is a termékünkkel, mindig vissza tudjuk állítani az adatokat a feltételes Amazonban található fájlokból.

Tehát menjünk végig a lehetséges forgatókönyveken, a legegyszerűbbtől a bonyolultabbig.

A legegyszerűbb szerencsétlenség, ami a fejünkre eshet, az a biztonsági mentési lánc egyik fájljának elérhetetlensége.

Szomorúbb történet, hogy a SOBR tárolónk egyik kiterjedése elromlott.

Még rosszabb a helyzet, amikor a teljes SOBR tárhely elérhetetlenné vált, de a kapacitású lőtér működik.
És minden nagyon rossz - ilyenkor a tartalék szerver meghal, és az első vágyunk az, hogy tíz perc alatt megpróbáljunk elfutni a kanadai határig.

Most nézzük meg az egyes helyzeteket külön-külön.

Ha elvesztettünk egy (és akár több) biztonsági mentési fájlt, akkor már csak el kell indítanunk a repository rescan folyamatot, és az elveszett fájl helyére egy dummy fájl kerül. A rehidratációs folyamat segítségével pedig (amelyről a cikk elején volt szó) a felhasználó letöltheti a kapacitási lőtér adatait a helyi tárolóba.

Most a helyzet bonyolultabb. Tételezzük fel, hogy a SOBR-ünk két Performance módban futó kiterjedésből áll, ami azt jelenti, hogy a .vbk és .vib egy meglehetősen egyenetlen rétegben oszlik el rajtuk. És egy adott időpontban az egyik kiterjedés elérhetetlenné válik, és a felhasználónak sürgősen helyre kell állítania a gépet, amelynek adatainak egy része pontosan ezen a terjedelemen található.

A felhasználó elindítja a helyreállítási varázslót, kiválasztja azt a pontot, ahová vissza akarja állítani, és a varázsló munka közben arra a felismerésre jut, hogy nem rendelkezik a helyi helyreállításhoz szükséges összes adattal, ezért le kell tölteni a kapacitásfelvételből. Képtár. Ugyanakkor a helyi tárhelyen maradt blokkok nem lesznek letöltve a felhőből. Dicsőség a visszaállítási indexnek (igen, ez is szóba került a cikk elején).

Ennek az esetnek egy altípusa, hogy a teljes SOBR-tár elérhetetlenné vált. Ebben az esetben nincs mit másolnunk a helyi tárhelyről, és az összes blokkot a felhőből töltjük le.

És a legérdekesebb helyzet az, hogy a tartalék szerver meghalt. Itt két lehetőség van: az admin nagyszerű, és konfigurációs biztonsági mentéseket készített, az admin pedig maga egy gonosz Pinocchio, és nem készített konfigurációs biztonsági mentéseket.

Az első esetben elegendő lesz, ha egyszerűen telepíti a VBR tiszta telepítését valahol, és szabványos eszközökkel visszaállítja az adatbázist egy biztonsági másolatból. A folyamat végén minden visszatér a normális kerékvágásba. Vagy a fenti forgatókönyvek valamelyikének megfelelően helyreállítják.

De ha az admin vagy a saját ellensége, vagy a konfigurációs biztonsági mentés is epikus kudarcot szenvedett, akkor még itt sem hagyjuk a sors kegyére. Erre az esetre egy új eljárást vezettünk be, az Import Object Storage néven. Lehetővé teszi, hogy kihagyja a SOBR-tárház manuális újralétrehozásának folyamatát, és egy kapacitási lőteret csatoljon hozzá egy későbbi újraellenőrzéssel, és egyszerűen hozzáadjon egy tárolóobjektumot a Vim felülethez, és futtassa az Import Storage Repository eljárást. Az egyetlen dolog, ami útban állhat Ön és a biztonsági másolatok között, az egy jelszó megadása, ha a biztonsági másolatok titkosítva voltak.

Ez valószínűleg a Másolás módról szól, és továbblépünk

Lezárt mód

A fő ötlet az, hogy az új biztonsági másolatok nem jelenhetnek meg a lerakat kiválasztott SOBR kiterjedésében. A v10 előtt csak Karbantartási módunk volt, amikor a tárhellyel végzett minden munka teljesen tilos volt. Egyfajta hardcore mód a tárhely leállítására, ahol csak az Evacuate gomb érhető el, amely egyszeri alkalommal másodlagos biztonsági mentéseket szállít.

A Sealed mód pedig egyfajta „puha” opció: megtiltjuk az új mentések készítését, a régieket pedig fokozatosan töröljük a kiválasztott megőrzésnek megfelelően, de közben nem veszítjük el a tárolt pontokból történő visszaállítás lehetőségét. Nagyon hasznos dolog, amikor vagy egy hardverünk az élettartama végéhez közeledik, és ki kell cserélni, vagy csak fel kell szabadítanunk valami fontosabbra, de nincs hova vinni és mindent egyszerre áthelyezni. Vagy nem lehet törölni.

Ennek megfelelően a működési elv meglehetősen egyszerű: meg kell tiltani minden írási műveletet (új adatok megjelenése), az olvasás elhagyását (helyreállítások) és a törlést (megtartás).

Mindkét mód egyidejűleg is használható, de ne feledje, hogy a karbantartás magasabb prioritású.

Példaként vegyünk egy SOBR-t, amely két kiterjedésből áll. Tegyük fel, hogy az első négy napban Forward Forever Incremental módban készítettünk mentést, majd lezárjuk a kiterjedést, ami oda vezet, hogy a második elérhető kiterjedésnél egy új aktív full létrehozását kezdeményezzük. Ha a visszatartásunk négy, akkor amikor a lezárt kiterjedésű teljes lánc túllép a határain, akkor azt tiszta lelkiismerettel töröljük.

Vannak olyan helyzetek, amikor a törlés korábban történik. Ez például a növekményes előreküldés periodikus töltésekkel. Ha az első két napra teljes biztonsági másolatot készítettünk, és csütörtökön úgy döntünk, hogy lezárjuk a tárolót, akkor pénteken, amikor új mentés készül, a hétfői fájl törlődik, mert ezen a ponton nincsenek függőségek. És maga a lényeg nem függ senkitől. Ezután megvárjuk, amíg négy pont létrejön a rendelkezésre álló terjedelemben, és töröljük a maradék hármat, amelyek egymástól függetlenül nem törölhetők.

A Reverse Incremental funkcióval egyszerűbb a dolog. Ebben a legrégebbi pontok nem függnek semmitől, és biztonságosan törölhetők. Ezért amint új .vbk jön létre új kiterjedésű, a régi .vrbs egyenként törlődik.

Egyébként miért hozunk létre minden alkalommal új .vbk-t: ha nem hoznánk létre, hanem folytatnánk a régi növekményláncot, akkor a régi .vbk végtelen ideig lefagyna bármilyen módban, megakadályozva a törlését. Ezért úgy döntöttünk, hogy amint a kiterjedés lezárásra kerül, teljes mentést készítünk az ingyenes kiterjedésről.

A kapacitás lőtérrel bonyolultabb a helyzet.

Először nézzük meg a másolási módot. Tegyük fel, hogy négy napig aktívan készítettünk mentéseket, majd lezárták a kapacitás lőterét. Nem törölünk semmit, hanem alázatosan elviseljük a megőrzést, ami után töröljük az adatokat a kapacitás lőtérről.

Körülbelül ugyanez történik mozgatási módban is - megvárjuk a retusálást, töröljük a régit a helyi tárolóból, és töröljük az objektumtárolóban tárolt.

Érdekes példa a Forever előre növekményes vezérlésére. Három ponton telepítjük a megőrzést, és hétfőn megkezdjük a biztonsági mentések készítését, amelyeket rendszeresen a felhőbe másolunk. A tároló lezárása után folytatódik a biztonsági mentések létrehozása, megtartva a három pontot, de a kapacitásvonalban tárolt adatok függőek maradnak, és nem törölhetők. Ezért várunk csütörtökig, amikor a .vbk-nk túllép a megőrzésen, és csak ezután töröljük nyugodtan a teljes mentett láncot.

És egy kis felelősségkizárás: az itt található összes példa egyetlen géppel látható. Ha több is van belőlük a biztonsági mentésben, akkor a retusálásuk attól függően változik, hogy az Active Full készült-e vagy sem.

Lényegében ez minden. Tehát térjünk át a legkeményebb funkcióra -

Állandóság

Az előző pontokhoz hasonlóan először is az, hogy ez a függvény milyen problémát old meg. Amint feltöltjük a mentéseinket valahova tárolásra, erős a vágy, hogy garantáljuk a biztonságukat, vagyis fizikailag megtiltsa a törlésüket, illetve az adott megőrzés alatti módosításukat. Beleértve az adminisztrátorokat, beleértve a root fiókjukat is. Ez lehetővé teszi, hogy megvédje őket a véletlen vagy szándékos károsodástól. Bárki, aki AWS-sel dolgozik, találkozhatott egy hasonló, Object Lock nevű funkcióval.

Most nézzük meg általánosságban a módot, majd mélyedjünk el a részletekben. Példánkban a Változatlanság négy napos visszatartással lesz engedélyezve kapacitású lőterünkön. A másolási mód pedig engedélyezve van a biztonsági mentésben.

A megváltoztathatatlanság semmilyen módon nincs kölcsönhatásban az általános megtartással. Például nem ad plusz pontot, vagy ilyesmi. Csak arról van szó, hogy egy személy nem tudja négy napon belül törölni a biztonsági másolatokat. Ha hétfőn készít biztonsági másolatot, akkor csak pénteken tudja törölni a fájlt.

A dehidratáció, az indexek és a metaadatok összes korábban kifejtett fogalma továbbra is pontosan ugyanúgy működik. De egy feltétellel - a blokk nemcsak adatokra, hanem metaadatokra is be van állítva. Erre akkor kerül sor, ha egy ravasz támadó úgy dönt, hogy törli metaadat-adatbázisunkat, és megakadályozza, hogy az adatblokkok haszontalan bináris kásává váljanak.

Itt az ideje, hogy elmagyarázzuk blokkgenerálási technológiánkat. Vagy blokkgenerálás. Ehhez vegye figyelembe azt a helyzetet, amely a megjelenéséhez vezetett.

Vegyünk egy hat napos időskálát, és az alábbiakban a megváltoztathatatlanság várható lejártának időpontját jelöljük. Az első napon veszünk és létrehozunk egy fájlt, amely az a adatblokkból és annak metaadataiból áll. Ha a megváltoztathatatlanság három napra van beállítva, logikusan feltételezhető, hogy a negyedik napon az adatok zárolása feloldásra és törlésre kerül. A második napon hozzáadunk egy új fájlt2, amely a b blokkból áll, azonos beállításokkal. A blokkot el kell távolítani a negyedik napon. De a harmadik napon valami szörnyű dolog történik - létrejön egy File3 fájl, amely egy új d blokkból és a régi a blokkra mutató hivatkozásból áll. Ez azt jelenti, hogy egy blokkhoz és annak megváltoztathatatlanságához jelzőt kell visszaállítani egy új dátumra, amely a hatodik napra tolódik el. És itt egy probléma merül fel - a valódi biztonsági mentésekben rengeteg ilyen blokk található. És annak érdekében, hogy meghosszabbítsák a megváltoztathatatlanság idejét, minden alkalommal hatalmas számú kérést kell benyújtania. Valójában ez egy szinte végtelen napi folyamat lesz, hiszen nagy valószínűséggel minden másolatnál tetemes halom deduplikált blokkot találunk majd. Mit jelent az objektumtároló szolgáltatóktól érkező nagyszámú kérés? Jobb! Hatalmas számla a hónap végén.

És annak érdekében, hogy ne véletlenül kitesd kedvenc ügyfeleidet jelentős pénzért, kitalálták a blokkgeneráló mechanizmust. Ez egy további időszak, amelyet hozzáadunk a beállított változhatatlansági időszakhoz. Az alábbi példában ez az időszak két nap. De ez csak egy példa. Valójában a saját képletüket használják, amely körülbelül tíz további napot ad a havi zárolás során.

Tekintsük továbbra is ugyanazt a helyzetet, de blokkgenerálással. Az első napon létrehozzuk a file1-et az a blokkból és a metaadatokból. Összeadjuk a generálási időszakot és a megváltoztathatatlanságot - ez azt jelenti, hogy a fájl törlésének lehetősége a hatodik napon lesz. Ha a második napon létrehozzuk a Fájl2-t, amely a b blokkból és egy hivatkozásból áll az a blokkra, akkor semmi sem történik a várt törlési dátummal. Úgy állt, mint a hatodik napon. Így igyekszünk pénzt megtakarítani a kérelmek számán. A határidő csak akkor tolható el, ha a generációs időszak lejárt. Azaz, ha a harmadik napon az új File3 tartalmaz egy hivatkozást az a blokkolására, akkor a 2. generáció kerül hozzáadásra, mivel a Gen1 már lejárt. Az a blokk törlésének várható dátuma pedig a nyolcadik napra tolódik el. Ez lehetővé teszi számunkra, hogy drámai módon csökkentsük a deduplikált blokkok élettartamának meghosszabbítására irányuló kérések számát, ami rengeteg pénzt takarít meg az ügyfeleknek.

Maga a technológia az S3 és S3 kompatibilis hardverek felhasználói számára elérhető, amelyek gyártói garantálják, hogy megvalósításuk nem tér el az Amazonétól. Innen a válasz arra a jogos kérdésre, hogy miért nem támogatott az Azure – hasonló funkciójuk van, de a konténerek szintjén működik, nem az egyes objektumok szintjén. Az Amazon egyébként két módban rendelkezik objektumzárral: megfelelőség és irányítás. A második esetben továbbra is fennáll annak lehetősége, hogy az adminok feletti legnagyobb adminisztrátor és a root feletti root az objektumzárolás ellenére mégis törli az adatokat. Megfelelés esetén minden szorosan be van szögezve, és senki nem tudja törölni a biztonsági másolatokat. Még az Amazon adminjai is (hivatalos nyilatkozataik szerint). Ezt a módot támogatjuk.

És szokás szerint néhány hasznos link:

• Про Blokkgenerálás minden részletében.
• Minden információ a Veeam biztonsági mentés és replikáció 10 a javából
• О Kapacitási szint részletekben

Forrás: will.com