A Kapacitás Szint (vagy ahogy mi itt hívjuk — kaptir) még a Veeam Backup and Replication 9.5 Update 4 idején jelent meg Archive Tier néven. Az ötlet lényege, hogy lehetőséget adjon a backupok áthelyezésére, amelyek kiesnek az ún. operatív helyreállítási ablakból, objektumalapú tárolókba. Ez segített felszabadítani a lemezterületet azoknak a felhasználóknak, akik szűkében voltak a helynek. Ezt az opciót Move Mode-nak hívták.

Ehhez az egyszerűnek tűnő művelethez elegendő volt két feltételt betartani: minden pontnak, amely a mozgatott backupban van, kívül kell esnie a már említett operatív helyreállítási ablakon, amely kifejezetten a UI-ban van megadva. A másik: a láncnak ún. „lezárt állapotban” (sealed backup chain vagy Inactive Backup Chain) kell lennie. Ez azt jelenti, hogy idővel nem történik változás ebben a láncban.

De a VBR v10-ben a koncepció új funkciókkal bővült — megjelent a Copy Mode, Sealed Mode és az Immutability nehezen kiejthető neve.

Ezekről az izgalmas dolgokról fogunk ma beszélni. Először arról, hogyan működött ez a VBR9.5u4-ben, majd a tizedik verzióval kapcsolatos változásokról.

És bocsássanak meg a tiszta nyelv hívei, de túl sok kifejezést nem lehet lefordítani.
Így itt sok anglicizmus fog szerepelni.
És sok gif.
És kép.

Itt a legkevésbé sem bánom. Cikk szerzője.

Hogyan volt

Nos, kezdjük a műveleti helyreállítási ablakkal és a lezárt backup-al (vagy ahogy a dokumentációban hívják: Inactive Backup Chain). Ezek megértése nélkül nem lehet a továbbiakat elmagyarázni.

Ahogy a képen is láthatjuk, van egy backup láncunk adategységekkel, amely a Performance tier SOBR tárolón található, és amelyhez a Kapacitás Szint csatlakozik. A mi operatív backup ablakunk három napra van beállítva.

Ennek megfelelően a hétfőn létrehozott .vbk lezárja az előzőláncot, amelynek ablaka három nap. Így tehát nyugodtan lehet kezdeni a három napnál régebbi dolgokat a kapacitás szintre szállítani.

De mit is jelentett a lezárt lánc, és mi küldhető a kapacitás szintre az update 4-ben?

A Forward Incremental esetében a lánc lezárásának jele az új teljes backup létrehozása. Nem számít, hogyan történik ez a teljes backup: az úgynevezett synthetic full és active full backupok is számítanak.

Visszafelé a műveleti ablakon kívül eső összes fájl.

Forward increment esetében a rollback-ok mind a .vbk fájlra vonatkoznak, ha a teljesítményszélességen van egy másik .vbk.

Most nézzük meg a Backup Copy láncokkal való munkavégzés lehetőségét. Itt csak a GFS megőrzés alá tartozó fájlok kerültek átadásra. Mert minden, ami frissebb backup copy láncokban található, bármilyen módon módosítható lehet.

Most nézzünk be a gép alá. Ott egy úgynevezett dehidrációs folyamat zajlik — üres backup fájlok hagyása a szélességi elérhetőségen, és blokkok áthelyezése ezekből a fájlokból a kapacitás tárolóra. Ennek a folyamatnak az optimalizálásához a dehidrációs indexet használják, amely lehetővé teszi, hogy ne másoljunk le blokkokat, amelyek már átkerültek a kapacitás tárolóba.

Nézzük meg, hogyan néz ki ez egy példán keresztül: tegyük fel, hogy van egy .vbk fájlunk, amely kilépett a műveleti ablakból, és egy zárt lánchoz tartozik. Ezért teljes joggal áthelyezhetjük a kapacitás tárolóba. Az áthelyezés pillanatában létrejön egy metainformációs fájl a kapacitás tárolón, és az áthelyezett fájl blokkjai. A metainformációs fájlban a hivatkozási szinten le van írva, hogy a fájlunk mely blokkokból áll. A képen a mi első fájlunk a, b, c blokkokból áll, és a metainformációk tartalmazzák ezekre a blokkokra vonatkozó hivatkozásokat. Amikor érkezik egy második .vbk fájl, amely áthelyezésre kész és a, b és d blokkokból áll, a dehidrációs index elemzése alapján megértjük, hogy csak d blokkot kell áthelyeznünk. A metainformációs fájlja pedig tartalmazni fogja a két korábbi blokk hivatkozását és egy új blokkét.

Ezért az üres blokkok adatokkal való újratöltésének folyamata a regenerációnak hívják. Itt már a legöregebb .vbk fájlra támaszkodó regenerációs indexet alkalmazzák a helyi teljesítményszélességen. Tehát, ha a felhasználó vissza szeretne állítani egy fájlt a kapacitás tárolóból, először létrehozunk a legöregebb teljes backup blokkjainak indexét, és a kapacitás tárolóból csak a hiányzó blokkokat másoljuk. A képen bemutatott esetben, hogy a FullBackup1.vbk-t a regenerációs index szerint regeneráljuk, csak a C blokk hiányzik, amelyet a kapacitás tárolóból megszerzünk. Ha a kapacitás tároló felhő alapú objektumtároló, ez hatalmas költségmegtakarítást tesz lehetővé.

Itt úgy tűnhet, hogy ez a technológia azonos a WAN gyorsítókban használtal, de ez csak látszólagos. A gyorsítók globális deduplikálást alkalmaznak, míg itt a fájlok egy adott offsetje alapján helyi deduplikálás használatos. Ez a különböző feladatok megoldásának eltéréséből adódik: itt nagy fájlok, teljes biztonsági mentések másolására van szükség, és a kutatásaink alapján még ha hosszú idő is telik el közöttük, ez a deduplikáló algoritmus a legjobb eredményt adja.

De több index az indexek istene! Van egy index az adatok helyreállításához is! Amikor elindítjuk egy kapacitás rétegben elhelyezkedő gép helyreállítását, csak az egyedi adatblokkokat olvassuk, amelyek nem találhatóak a teljesítmény rétegben.

Hogy alakult

Ezen a bevezető részen ennyi. Elég részletes, de, ahogy már említettem, ezek a részletek elengedhetetlenek az új funkciók működésének magyarázatához. Tehát felesleges bevezetés nélkül térjünk át az elsőre.

Másolási mód

Többnyire a meglévő technológiákra épül, azonban teljesen más logikát hordoz magában.

Ennek a módnak a célja, hogy biztosítsa, hogy minden adat, amely a helyi kiterjesztésen helyezkedik el, rendelkezik egy másolattal a kapacitás rétegben.

Ha egyenesen összehasonlítjuk a Move és a Copy módokat, akkor így alakul:

Mozgatni csak lezárt láncot lehet. A másolási módban minden eljut, függetlenül attól, hogy mi történik a biztonsági mentési feladatban.
A mozgatás akkor aktiválódik, amikor a fájlok kilépnek a biztonsági mentés operációs ablakából, míg a másolás azonnal aktiválódik, amint egy biztonsági mentési fájl megjelenik.
Az új adatok másolásának nyomkövetése folyamatosan történik, míg a mozgatás négyóránként aktiválódott.

Az új mód vizsgálatánál javaslom, hogy a egyszerű példáktól haladjunk a bonyolultabbak felé.

A legbanálisabb esetben új fájlok jelennek meg izgalommal, és ezeket egyszerűen átmásoljuk a kapacitás rétegbe. Függetlenül attól, hogy milyen módot használnak a biztonsági mentési feladatban, függetlenül attól, hogy az lezárt lánchoz tartozik-e vagy sem, függetlenül attól, hogy lejárt-e a működési ablakunk. Egyszerűen csak átvittük és lemásoltuk.

A folyamat, amely a háttérben zajlik, továbbra is dehidratálás, ahogyan azt korábban leírtuk. A másolási módban figyeli, hogy ne másoljunk már meglévő blokkokat a tárolónkon. Az egyetlen különbség az, hogy míg a mozgási módban a valódi fájlokat üres fájlokkal helyettesítettük, addig itt nem nyúlunk hozzájuk, és mindent úgy hagyunk, ahogy van. Egyébként ez továbbra is egy dehidratációs index, amely szigorúan arra törekszik, hogy kímélje a pénzedet és az idődet.

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

Nézzük meg részletesen.

A kezdés standard: létrejön egy biztonsági mentési fájl, és azonnal lemásolják. Ehhez egy inkrement ágyazódik és szintén lemásolják. Ez így folytatódik, amíg meg nem értjük, hogy a fájlok kikerültek a műveleti ablakunkból, és egy lezárt lánc jött létre. Ekkor hajtjuk végre a dehidratációs műveletet, és üres fájlokkal helyettesítjük ezeket a fájlokat. Természetesen a kapacitás rétegre semmit sem másolunk újra.

Mindez az izgalmas logika mindössze egyetlen pipára épül a felületen: Copy backups to object storage as soon as they are created.

De mire jó ez a Copy mód?

Talán érdemes így átfogalmazni a kérdést — milyen kockázatok ellen védjük magunkat ezzel? Milyen problémát segít megoldani?

A válasz egyértelmű: természetesen az adatok helyreállítása. Ha van egy teljes másolatunk a helyi adatokból az objektum tárolón, akkor nem számít, mi történik a produkcióval, mindig helyreállíthatjuk az adatokat az elvont amazonon elhelyezett fájlokból.

Ezért nézzük meg a lehetséges forgatókönyveket, a legegyszerűbbtől a bonyolultabbakig.

A legegyszerűbb baj, ami ránk zúdulhat, ha az egyik fájl elérhetetlenné válik a biztonsági mentési láncban.

Egy szomorúbb történet, ha megrongálódik a SOBR tároló egyik kiterjesztése.

Még rosszabbá válik a helyzet, amikor az egész SOBR tároló elérhetetlenné válik, de a kapacitás réteg működik.
És mindez igazán rossz, amikor a biztonsági mentési szerver tönkremegy, és az első gondolatod az, hogy megpróbálsz tíz perc alatt eljutni a kanadai határra.

Most nézzük meg külön-külön minden egyes helyzetet.

Amikor elvesztettünk egy (de akár többet is) mentési fájlt, elegendő, ha elindítjuk a keresési folyamatot a tárolóban, és az elveszett fájl helyére egy üres fájl kerül. A rehidratálási folyamat révén (amelyről a cikk elején volt szó) a felhasználó letöltheti az adatokat a kapacitás tárolóból a helyi tárolóba.

Most a helyzet bonyolultabbá válik. Tegyük fel, hogy a SOBR két kiterjesztésből áll, amelyek teljesítmény üzemmódban működnek, ezért a .vbk és .vib fájlok meglehetősen egyenetlen rétegben vannak elosztva rajtuk. Egy adott időpontban az egyik kiterjesztés elérhetetlenné válik, és a felhasználónak sürgősen vissza kell állítania a gépet, amelynek egy része éppen ezen a kiterjesztésen található.

A felhasználó elindítja a helyreállító varázslót, kiválasztja azt a pontot, amelyre vissza szeretné állítani, és a varázsló a munka során ráébred, hogy a helyi tárolón nincsenek meg a szükséges helyreállítási adatok, így azokat le kell tölteni a kapacitás tárolóból. Közben a helyi tárolón maradt blokkok nem fognak letöltődni a felhőből. Hála a visszaállítási indexnek (igen, erről is volt szó a cikk elején).

Ennek az esetnek a részfajtája, ha az egész SOBR tároló elérhetetlenné válik. Ilyen esetben nincs mit másolnunk a helyi tárolókból, így minden blokk a felhőből lesz letöltve.

És a legérdekesebb helyzet: elhalt a mentési szerver. Itt két lehetőség van: vagy a rendszergazda ügyes volt és készített konfigurációs mentéseket, vagy a rendszergazda önmagának gonosz burratíno, és nem készített konfigurációs mentést.

Az első esetben elegendő, ha valahol telepít egy tiszta VBR installációt, és a biztonsági mentéseiből helyreállítja az adatbázist a standard eszközökkel. A folyamat végén minden visszatér a megszokott kerékvágásba. Vagy pedig az egyik fenti forgatókönyv szerint állítják vissza.

De ha az admin saját magának ellensége, vagy a konfigurációs mentés is egy mitikus kudarctól szenvedett, akkor még itt sem hagyjuk a sorsára. Erre az esetre bevezettük az Import Object Storage nevű új eljárást. Ez lehetővé teszi, hogy kihagyjuk a SOBR tároló manuális újbóli létrehozásának folyamatát és annak kapacitásához való csatlakozást a következő átvizsgálással, hanem egyszerűen hozzáadjuk az objektum tárolót a Vima felülethez és elindítjuk az Import Storage Repository eljárást. Az egyetlen dolog, ami az Ön és a mentései közé állhat, az egy jelszó megadása, ha a mentései titkosítva voltak.

Ennyit a Copy Mode-ról, most áttérünk

Sealed Mode

A fő ötlet az, hogy a kiválasztott SOBR tároló területen új mentések nem jelenhetnek meg. A v10 előtt csak Maintenance Mode volt, amikor teljesen tiltotta a bármilyen munkát a tárolóval. Egyfajta hardcore mód, ahol csak az Evacuate gomb érhető el, amely egyszeri átköltöztetéssel szállította a mentéseket egy másik területre.

A Sealed Mode egy „lágyabb” változat: megtiltjuk az új mentések létrehozását és fokozatosan töröljük a régiakat a kiválasztott megőrzési idő szerint, de közben nem veszítjük el a lehetőséget, hogy a megőrzött pontokból helyreálljunk. Nagyon hasznos, amikor közeledik a hardver élettartamának vége, és azt ki kell cserélni, vagy egyszerűen fel kell szabadítani valami fontosabb számára, de nem tudunk mindent egyszerre áthelyezni. Vagy nem lehet törölni.

Ennek megfelelően a működési elv viszonylag egyszerű: minden írási műveletet (új adatok keletkezését) kell tiltanunk, lehetővé téve az olvasást (visszaállításokat) és a törlést (megőrzést).

Mindkét mód egyidejűleg használható, csak figyelembe kell venni, hogy a Maintenance prioritása magasabb.

Példaként vegyük figyelembe egy két területből álló SOBR-t. Tegyük fel, hogy az első négy napban a mentéseket Forward Forever Incremental módban készítettük, majd lezártuk a területet. Ez odavezet, hogy új aktív teljes mentést indítunk a második elérhető területen. Ha a megőrzésünk négy, akkor amikor az az zárolt területen lévő lánc elérte a határait, nyugodt lelkiismerettel törölhető.

Vannak olyan helyzetek, amikor a törlés korábban történik. Például ez a Forward incremental időszakos teljes mentésekkel. Ha az első két napon teljes biztonsági mentést készítünk, és csütörtökön úgy döntünk, hogy lezárjuk a tárolót, akkor pénteken, amikor létrejön egy új teljes mentés, a hétfői fájl törlésre kerül, mivel ehhez a ponthoz nincsenek függőségek. Magának a pontnak sincs senkitől való függősége. Ezt követően megvárjuk, amíg négy pont jön létre a rendelkezésre álló területen, és töröljük a maradék három pontot, amelyek egymástól függetlenül nem törölhetők.

Az ügyek egyszerűbbek a Reverse Incremental esetében. Itt a legöregebb pontok senkitől sem függenek, és nyugodtan törölhetők. Ezért, amint létrejön egy új .vbk egy új területen, a régi .vrb fájlokat egyenként törölni fogjuk.

Egyébként, miért készítünk minden alkalommal új .vbk fájlt: ha ezt nem tennénk, és folytatnánk a régi inkrementális láncot, akkor a régi .vbk végtelen ideig lógna a bármelyik módban, megakadályozva a törlését. Ezért elfogadtuk, hogy amint a terület lezárul, új teljes biztonsági másolatot készítünk egy szabad területen.

Bonyolultabb a helyzet a kapacitás területekkel.

Kezdjük a copy móddal. Tegyük fel, hogy négy napon keresztül aktívan készítünk biztonsági másolatokat, majd a kapacitás területet lezárják. Nem törlünk semmit, hanem türelmesen várjuk a megtartási időt, majd töröljük az adatokat a kapacitás területről.

Hasonló dolog történik a move módban is — várjuk a megtartást, töröljük a régit a helyi tárolóból, és töröljük az objektumtárolóban lévőt.

Érdekes példa a Forever forward incremental esetén. Beállítjuk a megtartást három pontra, és hétfőtől kezdve készítünk biztonsági másolatokat, amelyek megbízhatóan mentésre kerülnek a felhőbe. A tároló lezárása után a biztonsági másolatok továbbra is készülnek, megtartva a három pontot, de a kapacitás területen tárolt adatok továbbra is függőben maradnak, és nem törölhetők. Ezért megvárjuk a csütörtököt, amikor a .vbk-nk meghaladta a megtartási időt, és csak ezután töröljük az összes mentett láncot.

Egy kis megjegyzés: az összes példa egy gépre vonatkozik. Ha több gép van a biztonsági mentésben, akkor a megtartásuk eltérő lesz attól függően, hogy készítettünk-e Active Full mentést vagy sem.

Ezzel el is érkeztünk a végére. Így áttérünk a legkeményebb funkcióra —

Immutability

Ahogyan a korábbi pontoknál, először is arról van szó, hogy milyen problémát old meg ez a funkció. Amint a biztonsági másolatainkat tárolásra elmentjük, sürgető igény merül fel a megőrzésük garantálására, azaz fizikailag megakadályozni azok törlését és bármilyen módosítását a megadott megőrzési időszak alatt. Ez vonatkozik az adminisztrátorokra is, még a root fiókjaik alatt is. Ez lehetővé teszi a véletlen vagy szándékos rongálás elleni védelmet. Aki dolgozik az AWS-sel, találkozhatott e funkcióval Object Lock néven.

Most nézzük meg az üzemmódot általában, aztán mélyebben belemerülünk a részletekbe. Példánkban az Immutability be lesz kapcsolva a négy napos megőrzési időszakunkhoz. A biztonsági másolatnál a Copy üzemmódot aktiváljuk.

Az Immutability nem kölcsönhatásba lép az általános megőrzési időszakkal. Például nem ad hozzá további pontokat vagy hasonlót. Csak négy napon keresztül a felhasználó nem tudja törölni a biztonsági másolatok fájljait. Ha hétfőn készítünk biztonsági másolatot, akkor azt pénteken lehet csak törölni.

Minden korábban magyarázott koncepció, mint a dehidrálás, indexek és metadaták továbbra is pontosan ugyanúgy működik. De egy feltétele van — a blokkok nemcsak az adatokra, hanem a metadatákra is vonatkoznak. Ezt azért tették, hogy ha egy alattomos támadó úgy dönt, hogy eltünteti a metadátáinkat, a blokkok az adatokkal ne váljanak haszontalan bináris masszává.

És most elérkezett a nagyszerű pillanat a blokkgenerálási technológiánk ismertetésére. Vagyis a block generation-ra. Ehhez vizsgáljuk meg a helyzetet, ami ehhez a megoldáshoz vezetett.

Vegyünk egy hatnapos idővonalat, és alul jelöljük a várható immutability lejárati időt. Az első napon létrehozunk egy fájlt, amely az "a" adatsorból és annak metaadataiból áll. Ha az immutability három napra van beállítva, logikus feltételezni, hogy a negyedik napon az adatok feloldásra és törlésre kerülnek. A második napon egy új "file2" fájlt adunk hozzá, amely a "b" adatsorból áll, ugyanazokkal a beállításokkal. Az "a" blokkot továbbra is törölni kell a negyedik napon. De a harmadik napon bekövetkezik a borzalmas dolog – létrejön a "File3" fájl, amely egy új "d" blokkból és egy hivatkozásból áll az régi "a" blokkra. Ez azt jelenti, hogy az "a" blokk immutability jelzőjét új időszakra kell átállítani, amely a hatodik napra tolódik. Itt problémák merülnek fel – a valós biztonsági másolatokban óriási mennyiségű ilyen blokk keletkezik. Ahhoz, hogy meghosszabbítsuk az immutability időszakot, minden alkalommal hatalmas számú kérést kell végrehajtanunk. És lényegében ez egy majdnem végtelen napi folyamat lesz, mivel nagy valószínűséggel minden másoláskor hatalmas mennyiségű deduplikált blokkot fogunk találni. Mit jelent a szolgáltatók objektum tárolóinál a nagy számú kérés? Helyes! Óriási számlát a hónap végén.

Annak érdekében, hogy ne zúdítsuk a költséges pénzt ügyfeleinkre, kidolgozták a blokk generációs mechanizmust. Ez egy kiegészítő időszak, amelyet az immutability időszakhoz adunk. Az alábbi példa szerint ez az időszak két napot jelent. De ez csak példának számít. A valóságban egy saját képletet használnak, amely körülbelül tíz további napot biztosít havi zárás esetén.

Folytassuk a helyzet vizsgálatát, de most a blokk generálásával. Az első napon létrehozunk egy file1-t a blokk a és a metaadatokból. Összeadjuk a generálási időszakot és az immutabilitást - ez azt jelenti, hogy a fájl törlésének lehetősége a hatodik napig elérhető. Ha a második napon létrehozunk egy File2-t, amely blokk b-ből és blokk a-ra mutató hivatkozásból áll, akkor a kiszabott törlési dátum nem változik. Az továbbra is a hatodik napra esik. Ezzel próbáljuk csökkenteni a kérések számát. Az egyetlen eset, amikor a határidő módosulhat, az, ha a generálási időszak lejárt. Tehát, ha a harmadik napon az új File3 blokk a-ra mutató hivatkozást tartalmaz, akkor a generálás 2 hozzáadódik, mivel Gen1 már lejárt. A blokk a várható törlési dátuma a nyolcadik napra tolódik. Ez drasztikusan csökkentheti a deduplikált blokkok életciklusának meghosszabbítására irányuló kérések számát, ami jelentős megtakarítást eredményez a klienseink számára.

Magának a technológiának elérhetők az S3 felhasználók és az S3-kompatibilis hardverek számára, amelyek gyártói garantálják, hogy az implementációjuk nem különbözik az Amazonétól. Itt van a válasz egy jogos kérdésre, miért nem támogatott az Azure - van hasonló funkciójuk, de az konténerek szintjén működik, nem pedig különálló objektumok szintjén. Érdekesség, hogy az Amazonon belül az objektumlok a compliance és governance két módjában létezik. A második esetben a legnagyobb adminisztrátor, aki mindent irányít, a legfőbb root administrator ellenére is törölheti az adatokat. A compliance esetében viszont minden szigorúan rögzítve van, és senki nem törölheti a biztonsági mentéseket, még az Amazon adminisztrátorai sem (hivatalos nyilatkozataik szerint). Éppen ezt a módot támogatjuk.