Üdvözlöm blogunk olvasóit! Részben már ismerjük egymást – az angol nyelvű bejegyzéseim itt jelentek meg drága kollégám fordításában . Ezúttal közvetlenül a magyar nyelvű közönséghez szeretnék fordulni.
A debütálásomhoz olyan témát kerestem, ami széles közönséget érdekel és alapos áttekintést igényel. Daniel Defoe azt állította, hogy minden embert halál és adók várnak. A magam részéről elmondhatom, hogy minden támogatási mérnöknek a helyreállítási pontok tárolási politikájával kapcsolatos kérdésekkel kell szembenéznie (vagy ha úgy tetszik, a retenzióval). A retenzió működését négy évvel ezelőtt kezdtem el magyarázni, mint egy szintű junior mérnök, és most is magyarázom, már mint az spanyol és olasz nyelvű csapat csapatvezetője. Biztos vagyok benne, hogy második és akár harmadik szintű támogatási kollégáim is rendszeresen válaszolnak ugyanazokra a kérdésekre.
Ebben a szellemben úgy döntöttem, hogy írok egy végleges, a lehető legrészletesebb bejegyzést, amelyhez a magyar nyelvű felhasználók újra és újra visszatérhetnek, mint egy kézikönyvhöz. Az időpont megfelelő – a nemrégiben megjelent jubileumi tizedik verzió új lehetőségeket adott a már évek óta változatlan alapfunkcionalitáshoz. A bejegyzésem elsősorban erre a verzióra irányul — bár a leírtak nagy része érvényes a korábbi verziókra is, van néhány funkció, amit ott egyszerűen nem fog megtalálni. Végül, ha kicsit a jövőbe is tekintünk, elmondom, hogy a következő verzióban néhány változás várható, de erről akkor fogunk beszélni, amikor eljön az ideje. Tehát, lássunk neki.
Biztonsági másolat feladatok (Backup job)
Kezdjük a résszel, amely nem változott a 10-es verzióban. A retenzió politikáját több paraméter határozza meg. Nyissuk meg az új feladat létrehozásának ablakát, és lépjünk a Storage fülre. Itt egy paramétert fogunk látni, amely meghatározza a kívánt helyreállítási pontok számát:
Azonban ez csak a képlet egy része. A helyreállítási pontok valós száma szintén a feladathoz beállított mentési módtól függ. Ennek a paraméternek a kiválasztásához a samme fülön található Advanced gombra kell kattintani. Ez megnyit egy új ablakot számos opcióval. Számozzuk meg őket, és nézzük át őket sorban:
Ha csak az 1-es opciót aktiváljuk, a feladat "végtelen inkrementális" módban (forever forward incremental) fog működni. Itt nincsenek bonyodalmak – a feladat a teljes biztonsági mentéstől (VBK kiterjesztésű fájl) az utolsó inkrementálig (VIB kiterjesztésű fájl) a beállított számú visszaállítási pontot fogja tárolni. Amikor a pontok száma meghaladja a beállított értéket, a legöregebb inkrementálódik a teljes biztonsági mentéssel. Más szóval, ha a feladat azt állítja, hogy 3 pontot kell tárolni, akkor a következő munkamenet után a tárhelyen 4 pont lesz, majd a teljes biztonsági mentés egyesül a legöregebb inkrementálissal, és a pontok összszáma visszatér 3-ra.
A "visszafelé inkrementális" (reverse incremental) módban (2-es opció) a visszatartás is rendkívül egyszerű. Mivel ebben az esetben a legújabb pont a teljes biztonsági mentés, amelyet a úgynevezett rollback lánc követ (VRB kiterjesztésű fájlok), a visszatartás alkalmazásához elegendő egyszerűen eltávolítani a legöregebb rollbacket. A helyzet ugyanaz lesz: a munkamenet után a pontok száma 1-gyel meghaladja a beállított értéket, majd visszatér a szükséges szintre.
Vegye figyelembe, hogy a visszafelé inkrementális módban periódikus teljes biztonsági mentést is lehet aktiválni (4-es opció), de ez nem változtat a lényegeben. Igen, a láncban megjelennek teljes visszaállítási pontok, de még mindig egyszerűen eltávolítjuk a legöregebb pontokat egyesével.
Végül elérkezünk az érdekes részhez. Ha aktiváljuk az inkrementális biztonsági mentést, de emellett bekapcsoljuk a 3-as vagy 4-es opciót (vagy akár mindkettőt egyszerre), a feladat periódikus teljes biztonsági mentéseket fog létrehozni "aktív" vagy szintetikus módszerrel. A teljes biztonsági mentés létrehozásának módja nem fontos – ugyanazokat az adatokat fogja tartalmazni, és az inkrementális lánc "al láncokra" lesz felosztva. Ezt a módszert forward incrementalnek hívják, és ez okozza a legtöbb kérdést az ügyfeleink részéről.
A retenziót itt a legrégebbi láncszem (a teljes biztonsági mentéstől az inkrementális mentésig) eltávolításával alkalmazzuk. Ezzel együtt nem fogjuk csak a teljes biztonsági mentést vagy csak egy részét az inkrementumoknak eltávolítani. Az egész "alma" egyszerre kerül teljesen törlésre. Az elegendő pontok beállításának értelme is megváltozik – míg más módszerek esetében ez a maximálisan megengedett szám, amely után alkalmazni kell a retenziót, itt ez a beállítás a minimum számot határozza meg. Más szóval, miután eltávolítottuk a legrégebbi "láncszemet", a megmaradt pontok száma nem csökkenthető a minimum alá.
Megpróbálom grafikusan ábrázolni ezt a koncepciót. Tegyük fel, hogy a retenzió 3 pontra van beállítva, a feladat minden nap fut, egy teljes biztonsági mentéssel hétfőn. Ilyen esetben a retenzió akkor kerül alkalmazásra, amikor az összes pont száma eléri a 10-et:
Miért 10, amikor 3-ra állították be? Hétfőn készült egy teljes biztonsági mentés. Keddtől vasárnapig a feladat inkrementumokat készített. Végül, következő hétfőn ismét teljes biztonsági mentés készül, és csak akkor, amikor 2 inkrementumot is létrehoztunk, az egész régi láncszem eltávolítható, mivel a megmaradó pontok száma nem csökkenhet a beállított 3 alá.
Ha a gondolat világos, javaslom, próbálja meg saját maga kiszámítani a retenziót. Vegyük a következő feltételeket: a feladat először csütörtökön indul (természetesen, elkészül a teljes biztonsági mentés). A feladat szerdán és vasárnap készít teljes biztonsági mentést, és 8 helyreállítási pontot tárol. Mikor fog először alkalmazásra kerülni a retenzió?
A kérdés megválaszolásához ajánlom, hogy egy papírlapot vegyen, osztja fel a hét napjaira, és írja fel, hogy minden nap melyik pont készül. A válasz nyilvánvalóvá válik.
Válasz
Magyarázat: a válaszhoz elegendő megkérdezni magától, "mikor kerül alkalmazásra a retenzió"? A válasz – amikor el tudjuk távolítani az első 3 pontot (VBK, VIB, VIB), és a megmaradó lánc nem csökken a megengedett 8 alá. Nyilvánvalóvá válik, hogy ezt akkor tudjuk megtenni, amikor összesen 11 pontunk van, azaz a második hét vasárnapján.
Néhány olvasó ellentmondhat: "miért van erre szükség, ha van ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Végre nem tárgyaltuk a „Transform previous backup chains into rollbacks” (5-ös számmal megjelölve) opciót. Ez az opció néha zavarba ejti az ügyfeleket, akik automatikusan aktiválják azt, csak hogy egy szintetikus biztonsági másolatot készítsenek. Eközben ez az opció egy teljesen különleges biztonsági másolat módot aktivál. Anélkül, hogy részletekbe merülnék, azonnal megmondom, hogy a termék jelenlegi fejlődési szakaszában a „Transform previous backup chains into rollbacks” egy elavult opció, és nem tudok egyetlen forgatókönyvet sem elképzelni, amikor ezt használni kellene. Az értéke annyira kétséges, hogy egy ideig még Anton Hostev is felhívást tett a fórumon, kérve, hogy küldjenek neki példákat a hasznos használatára (ha vannak ilyenek, írjátok meg a megjegyzésekben, nagyon érdekel). Ha nem található ilyesmi (úgy gondolom, hogy nem), akkor ezt az opciót eltávolítják a következő verziókban.
A feladat akkor fogja létrehozni az inkrementális (VIB) biztonsági másolatokat, amikor a szintetikus teljes biztonsági másolat meghatározásra kerül. Ezen a napon valóban létrejön egy VBK, de minden pont előtt, amely a VBK-hoz vezet, visszagörgetés (VRB) történik. Ezután a feladat folytatni fogja az inkrementális biztonsági másolatok létrehozását a teljes biztonsági másolathoz a következő szintetikus biztonsági másolatig. Ennek eredményeként a láncban VBK, VBR és VIB fájlok hibrid keveréke jön létre. A megőrzési politika pedig nagyon egyszerűen alkalmazható – az utolsó VBR törlésével:
Problems
A legtöbb probléma, ami az inkrementális üzemmód használatakor felmerül, általában a teljes biztonsági másolathoz kapcsolódik. A rendszeres teljes biztonsági másolat szükséges ehhez a módhoz, különben a tároló felhalmozza a pontokat, amíg meg nem telik.
Például a teljes biztonsági másolat túl ritkán készülhet. Mondjuk, a feladat 10 pont tárolására van beállítva, de a teljes biztonsági másolatot havonta egyszer készítik el. Nyilvánvaló, hogy a tényleges pontok száma itt jelentősen meghaladja a kívánt mennyiséget. Vagy a feladat egyébként végtelen inkrementális módban van beállítva, és 50 pont tárolására. Ezután valaki véletlenül létrehozott egy teljes biztonsági másolatot. Minden, mostantól a feladat várni fog, amíg a teljes pont 49 inkrementumot felhalmoz, ezt követően lép érvénybe a megőrzési politika, és visszatér a végtelen teljes módba.
Más esetekben a teljes biztonsági mentés rendszeresen létrejön, de valamilyen okból ez nem történik meg. Itt leírom a leggyakoribb okot. Néhány ügyfél inkább a "futtatás után" ütemezési opciót használja, és beállítja, hogy a feladatok láncban működjenek. Vegyünk egy példát: van 3 feladat, amelyek minden nap futnak, és vasárnap készítenek egy teljes biztonsági mentést. Az első feladat 22:30-kor indul, a többi láncban követi. Az inkrementális mentés 10 percet vesz igénybe, így 23:00-ra minden feladat befejezi a munkát. A teljes mentés viszont egy órát igényel, ezért vasárnap a következő történik: az első feladat 22:30-tól 23:30-ig fut. A következő 23:30-tól 00:30-ig. Az utolsó feladat pedig hétfőn indul. A teljes mentés vasárnapra van ütemezve, tehát ebben az esetben egyszerűen nem lesz. A feladat megvárja a teljes mentést, hogy alkalmazza a megőrzést. Ezért légy óvatos a "futtatás után" opció használatakor, vagy ne is használd – egyszerűen állítsd be a feladatokat, hogy egy időben induljanak, és engedd meg az erőforrás-tervezőnek, hogy végezze a dolgát.
Nem egyszerű a "Törölt elemek eltávolítása" opció
Ha végigjárjuk a Storage – Advanced – Maintenance feladatbeállításait, találkozhatunk a "törölt elemek adatainak eltávolítása után" opcióval, amely napokban van meghatározva.
Néhány ügyfél azt várja, hogy ez a megőrzés. Valójában ez egy teljesen különálló opció, amelynek félreértése váratlan következményekkel járhat. Először is, meg kell magyarázni, hogyan reagál a B&R a helyzetekre, amikor a session során csak néhány gép sikeresen kerül mentésre.
Képzeljünk el egy olyan forgatókönyvet: végtelen inkrementális feladat, amely 6 pont tárolására van beállítva. A feladatban 2 gép van, az egyik mindig sikeresen ment, a másik néha hibákat adott. Végül a hetedik pontnál a következő helyzet alakult ki:
Itt az idő a megőrzés alkalmazására, de az egyik gépnél 7 pont, a másiknál viszont csak 4 van. Alkalmazásra kerül itt a megőrzés? A válasz – igen, alkalmazásra kerül. Ha még egy objektum is sikeresen lett mentve, a B&R úgy számolja, hogy a pont létrejött.
Hasonló helyzet állhat elő, ha egy gép egyszerűen nem került bele a feladatba egy adott munkamenet során. Ilyen előfordulhat például, ha a gépeket nem egyenként, hanem konténerek (mappák, tárolók) részeként adjuk meg, és egy gép ideiglenesen egy másik konténerbe migrál. A feladat ilyenkor sikeresnek számít, de a statisztikákban egy üzenetet talál, ami figyelmezteti, hogy ez a gép már nem kerül feldolgozásra a feladat által.
Mi történik, ha nem figyelünk erre? Az örökké növekvő vagy visszafelé növekvő módok esetén a „problémás” gép helyreállítási pontjainak száma a munkamenetekkel csökken, míg el nem éri az egyet, amelyet a VBK-ban mentettek. Más szavakkal, még ha a gép hosszú ideig nem is készül biztonsági mentésre, egy helyreállítási pont mégis megmarad. Más a helyzet, ha periódikus teljes biztonsági mentések vannak engedélyezve. Ha figyelmen kívül hagyjuk a B&R jeleit, akkor végül az utolsó pont törlésre kerülhet a régi lánc részeivel együtt.
Ezeknek a részleteknek a megértése után végre megvizsgálhatjuk az „Eltávolítás törölt elemek adatai után” opciót. Ez eltávolít minden pontot egy adott géphez, ha az a gép X napon keresztül nem készül biztonsági mentésre. Vegye figyelembe, hogy ez a beállítás nem reagál a hibákra (próbálták - nem sikerült). Nem szabad, hogy még csak próbálkozás sem történjen a gép biztonsági mentésével. A lehetőség hasznosnak tűnik, és mindig aktívan kell tartani. Ha az adminisztrátor eltávolította a gépet a feladatból, akkor logikus, hogy egy idő után megtisztítsa a felesleges adatokat és a láncot. Azonban a beállítás fegyelmet és figyelmet követel meg.
Példát mondanék a gyakorlatból: a feladatba több konténer került, amelyek összetétele meglehetősen dinamikus volt. Az RAM hiánya miatt a B&R szerver problémákkal küzdött, amelyek észrevétlenek maradtak. A feladat elindult, és megpróbálta elkészíteni a gépek biztonsági másolatát, kivéve egyet, amely akkoriban nem volt jelen a konténerben. Mivel sok gép hibákat adott, alapértelmezés szerint a B&R 3 további próbálkozást kell végezzen a „problémás” gépek biztonsági másolatával. Az állandó RAM problémák miatt ezek a próbálkozások több napig elhúzódottak. A hiányzó VM biztonsági másolatának újrapróbálkozása nem történt meg (a VM hiánya nem hiba). Végül, egy újabb próbálkozás során végrehajtották a „Törlés a törölt elemek” feltételt, és az összes gép pontja törlésre került.
Ezzel kapcsolatban a következőket mondhatom: ha be vannak állítva a feladatok eredményeiről szóló értesítések, és még jobb, ha integrációt használsz a Veeam ONE-nal, akkor valószínűleg nem fog előfordulni ilyen veled. Ha viszont heti egyszer csak benézel a B&R szerverre, hogy ellenőrizd, hogy minden rendben működik, akkor a potenciálisan biztonsági másolatok törléséhez vezető opciókat jobb elkerülni.
Mi került be a v.10-be
Ami előzőleg szóba került, az már sok verzión keresztül létezett a B&R-ban. Ezeknek a működési elveknek a megértése után nézzük most, hogy mi került be a jubileumi „tízesbe”.
Napi megőrzési időszak
Fent a „klasszikus” tárolási politikát tárgyaltuk, amely a pontok számán alapul. Alternatív megközelítés – a „restore points” helyett a „days” opciót adjuk meg ugyanabból a menüből.
Az elképzelés a névből világos – a megőrzés a beállított napok számát fogja tárolni, a napok mindegyikében lévő pontok száma nem számít. Ezzel kapcsolatban az alábbiakat fontos figyelembe venni:
- A jelenlegi napot nem számítjuk a megőrzés kiszámításánál
- Azok a napok, amikor a feladat egyáltalán nem működött, szintén számítanak. Ezt fontos szem előtt tartani, hogy véletlenül ne veszítsük el azoknak a feladatoknak a pontjait, amelyek nem rendszeresen működnek.
- A helyreállítási pont abból a napból számítódik, amikor a létrehozása elkezdődött (azaz ha a feladat hétfőn kezdődött, és kedden fejeződött be, akkor ez a pont hétfőtől számít).
A többi alkalmazási elvhöz hasonlóan a retenziós feladatokat is a kiválasztott biztonsági mentési módszer határozza meg. Próbáljunk ki még egy számítási feladatot, ugyanazzal a inkrementális módszerrel. Tegyük fel, hogy a retenzió 8 napra van beállítva, a feladat 6 óránként fut egy teljes biztonsági mentéssel szerdán. Ekkor a feladat nem fut vasárnap. A feladat először hétfőn indul. Mikor alkalmazzák a retenziót?
Válasz
Mint mindig, a legjobb, ha készítünk egy táblázatot. Engedjék meg, hogy egyszerűsítsem a feladatot, és nem rajzolom meg az összes pontot, amely minden nap létrejön, hiszen a napi pontok száma itt nem számít. Csak az a fontos, hogy az első hétfőn és szerdán az első pont teljes biztonsági mentés lesz, míg a többi napon a feladat csupán 4 inkrementális pontot fog létrehozni.
Megértjük, hogy a retenziót a hétfői teljes biztonsági mentés és annak inkrementálása eltávolításával alkalmazzák. Mikor fog ez bekövetkezni? Amikor a lánc maradék része 8 napot tartalmaz. Ekkor nem számítjuk a mai napot, de a vasárnapot számítjuk. Tehát a válasz – a második hét csütörtökén.
GFS archiving for regular tasks
A v.10 előtt a Nagyszülő-Apu-Fiú (GFS) tárolási módszer csak archiváló biztonsági mentések és mágneses szalagra történő másolási feladatok esetében volt elérhető. Most viszont már a normál biztonsági mentésekhez is elérhetővé vált.
Bár ez nem tartozik közvetlenül a jelenlegi témához, nem hagyhatom ki, hogy a új funkciók nem jelentik a 3-2-1-es stratégia elhagyását. Az archivációs pontok jelenléte az alap tárhelyen egyáltalán nem befolyásolja annak megbízhatóságát. Azt feltételezzük, hogy a GFS-t kiterjeszthető tárolóval (Scale-out) fogják használni, hogy ezeket a pontokat S3-ra és hasonló tárolókba átadják. Ha ezeket nem használja, érdemes továbbra is az elsődleges és archiváló pontokat különböző tárolókban tárolni.
Nézzük meg most a GFS pontok létrehozásának elveit. A feladat beállításainál, a Storage lépésben megjelent egy külön gomb, amely a következő menüt hívja elő:
A GFS lényege néhány pontra redukálható (jegyezze meg, hogy a GFS más típusú feladatok esetén másként működik, de erről később beszélünk):
- A feladat nem hoz létre külön teljes biztonsági mentést a GFS ponthoz. Ehelyett a meglévő legmegfelelőbb teljes mentést fogja használni. Ezért a feladatnak inkrementális módban kell működnie, időszakos teljes biztonsági mentéssel, vagy a teljes mentést a felhasználónak kell kézzel létrehoznia.
- Ha csak egy időszak van bekapcsolva (például heti), akkor a GFS időszak elején a feladat egyszerűen megkezdheti a várakozást egy teljes biztonsági mentésre, és az első megfelelő pontot GFS-ként jelöli.
Példa: a feladat heti GFS tárolására van beállítva, szerdai mentés felhasználásával. A feladat minden nap működik, de a teljes biztonsági mentés péntekre van ütemezve. Ebben az esetben szerdán elkezdődik a GFS időszak, és a feladat megkezdi a megfelelő pont várakozását. Az a pénteken fog megjelenni, és GFS-ként lesz megjelölve.
- Ha több időszak van bekapcsolva (például heti és havi), akkor a B&R olyan módszert alkalmaz, amely lehetővé teszi, hogy ugyanazt a pontot több időszak GFS-ként használják (helytakarékosság végett). A zászlók sorban lesznek kiosztva, a fiatalabbtól kezdve.
Példa: a heti GFS szerdára van beállítva, a havi pedig a hónap utolsó hétére. A feladat minden nap működik, és teljes biztonsági mentéseket készít hétfőn és pénteken.
A könnyebb érthetőség érdekében kezdjük a hónap előző utolsó heti időszakával. Ebben a hétben hétfőn teljes biztonsági mentés készül, de ezt figyelmen kívül hagyják, mivel a heti GFS időszak szerdán kezdődik. Viszont a pénteki teljes mentés teljes mértékben megfelel a GFS pontnak. Ez a rendszer már ismerős számunkra.
Most nézzük meg, mi történik a hónap utolsó hetében. A havi GFS időszak hétfőn kezdődik, de a hétfői VBK nem lesz GFS-ként megjelölve, mivel a feladat arra törekszik, hogy egy VBK-t mind havi, mind heti GFS pontként megjelöljön. Ehelyett a keresés a heti GFS-sel kezdődik, mert ez alapértelmezés szerint havi GFS ponttá is válhat.
Ha csak heti és éves időszakokat kapcsolunk be, akkor ezek függetlenül működnek egymástól, és 2 különálló VBK-t jelölhetnek meg megfelelő GFS időszakokként.
Biztonsági másolat (Backup copy) készítési feladatok
Egy másik feladattípus, amely gyakran magyarázatra szorul. Kezdjük az „klasszikus” működési móddal, a v.10 innovációk nélkül.
Egyszerű megőrzési módszer
Alapértelmezetten az ilyen feladatok végtelen inkrementális módban működnek. A pontok létrehozása két paraméterrel van meghatározva – a másolási intervallummal és a kívánt visszaállítási pontok számával (itt nincs visszatartási napokban). A másolási intervallum a Job első fülén van beállítva a feladat létrehozásakor:
A visszaállítási pontok száma pedig egy kicsit később, a Target fülön van meghatározva
A feladat minden intervallumban 1 új pontot hoz létre (az, hogy hány pontot hoztak létre a VM-ek számára az eredeti feladatokkal, nem számít). Az intervallum végén az új pont véglegesítésre kerül, és ha szükséges, alkalmazásra kerül a visszatartás, amely a VBK és a legrégebbi inkrementálás egyesítésével valósul meg. Ez a mechanizmus már ismert számunkra.
A visszatartás módszere GFS használatával
A BCJ is képes archivált pontokat tárolni. Ezt a Target fülön lehet beállítani, egy kicsit alacsonyabb a visszaállítási pontok számának beállítása alatt:
A GFS pontok kétféleképpen hozhatók létre – szintetikusan, a másodlagos adattárolón lévő adatok felhasználásával, vagy utánozva egy teljes biztonsági mentést és olvasva az összes adatot az elsődleges adattárolóból (ez a 3-as számú opcióval aktiválható). A visszatartás mindkét esetben jelentősen eltérő lesz, ezért külön vizsgáljuk meg őket.
Szinterné GFS
Ebben az esetben a GFS pont nem pontosan a kijelölt napon jön létre. Ehelyett a GFS pont akkor fog létrejönni, amikor az adott nap VIB-je egyesítve van a teljes biztonsági mentéssel. Ez néha félreértéseket szül, hiszen az idő telik, de a GFS pont még mindig nincs. Csak a technikai támogatás hatalmas sámánja tudja megjósolni, hogy melyik napon fog a pont végül megjelenni. Valójában varázslatra nincs szükség – elég, ha megnézzük a kijelölt pontok számát és a szinkronizálási intervallumot (hány pontot hoznak létre naponta). Próbáljuk meg saját példánkkal kiszámolni: a feladat beállítva 7 pontot tárolni, a szinkronizálási intervallum 12 óra (tehát 2 pont naponta). Jelenleg a láncban már 7 pont van, ma hétfő van, és erre a napra van kijelölve a GFS pont létrehozása. Mikor fogják létrehozni?
Válasz
Itt érdemes részletezni, hogy hogyan fog változni a lánc dinamikusan, napra lebontva:
Hétfőn az utolsó inkrementum a láncban GFS-ként van megjelölve, de más látható változás nem történik. Minden nap a feladat 2 új pontot hoz létre, és a retenció könyörtelenül előrehalad a láncban. Végül csütörtökön elérkezik az idő, hogy a retenciót alkalmazzuk az adott inkrementumra. Ez az ülés több időt fog igénybe venni, mint általában, mert a feladat "kivonja" a szükséges blokkokat a láncból, és új teljes pontot hoz létre. Ezt követően a láncban már 8 pont lesz – 7 a fő láncban + GFS.
GFS pontok létrehozása a "Teljes pont olvasása" opcióval
Fent említettem, hogy a BCJ végtelen inkrementális módban működik. Most megnézzük a szabály alóli egyetlen kivételt. A "Teljes pont olvasása" opció bekapcsolásakor a GFS pont pontosan a tervezett napon lesz létrehozva. Maga a feladat inkrementális módban fog működni, időszakos teljes biztonsági másolatokkal, amelyeket fentebb tárgyaltunk. Retenciót is alkalmaznak, a legöregebb rész eltávolításával a láncból. Azonban ebben az esetben csak az inkrementumok kerülnek eltávolításra, és a teljes biztonsági másolat GFS pontként marad. Ennek megfelelően, a retenció számítása során a GFS zászlóval megjelölt pontokat nem veszik figyelembe.
Tegyük fel, hogy a feladat be van állítva 7 pont tárolására és heti GFS pont létrehozására hétfőn. Ebben az esetben minden hétfőn a feladat valóban létrehoz egy teljes biztonsági másolatot, és GFS-ként jelöli meg. A retenciót akkor alkalmazzák, amikor a legöregebb rész inkrementumainak eltávolítása után a megmaradt inkrementumok száma nem csökken 7 alá. Így néz ki ez egy diagramban:
Tehát a második hét végére összesen 14 pont lesz a láncban. A második hét során a feladat 7 pontot hozott létre. Ha ez egy egyszerű feladat lett volna, a retenciót már alkalmazták volna. De ez a BCJ GFS retencióval, így a GFS pontokat nem számítjuk, ami azt jelenti, hogy csak 6 van. Tehát a retenciót még nem tudjuk alkalmazni. A harmadik héten újabb teljes biztonsági másolatot hozunk létre GFS zászlóval. 15 pont, de ezt ismét nem számítjuk. Végül, a harmadik hét keddi napján egy inkrementumot hozunk létre. Most, ha eltávolítjuk az első hét láncának inkrementumait, az összesített inkrementumok száma megfelel a meghatározott retenciós követelménynek.
Ahogy már említettük, ebben a módszerben rendkívül fontos, hogy a teljes biztonsági mentések rendszeresen készüljenek. Mondjuk, ha a fő megőrzési időt 7 napra állítjuk be, de csak 1 éves pont van, könnyen elképzelhető, hogy az inkrementumok száma jóval, jóval meghaladja a 7-et. Ilyen esetekben jobb a szintetikus GFS létrehozási módszert használni.
És ismét „Törölje a törölt elemeket”
Ez a lehetőség a BCJ esetében is jelen van:
Ennek a lehetőségnek a logikája ugyanaz, mint a szokásos biztonsági mentési feladatoknál – ha a gép nem kezelhető a megadott számú napig, akkor az adatai eltávolításra kerülnek a láncból. Azonban a BCJ esetében ennek a lehetőségnek az hasznossága objektíven magasabb, és íme, miért.
Normál módban a BCJ végtelen inkrementális módban működik, tehát ha valamikor a gép eltávolításra kerül a feladatból, a megőrzési idő fokozatosan eltávolítja az összes helyreállítási pontot, amíg csak egy marad – a VBK. Most képzeljük el, hogy a feladat még mindig be van állítva szintetikus GFS pontok létrehozására. Amikor eljön az idő, a feladat minden géphez létre kell hogy hozzon GFS-t a láncban. Ha valamelyik gépnek egyáltalán nincs új pontja – hát, használni kell azt, ami van. És ez minden alkalommal megtörténik. Végül olyan helyzet állhat elő:
Figyeljen a Files szekcióra: van egy fő VBK-nk és 2 hetente frissített GFS pontunk. Most nézzük meg a Restore points szekciót – ezekben a fájlokban valójában ugyanaz a gépkép található. Nyilvánvaló, hogy ilyen GFS pontoknak nincs értelme, csak helyet foglalnak.
Ilyen helyzet kizárólag szintetikus GFS használatakor fordulhat elő. Ennek elkerülése érdekében használja a „Törölje a törölt elemeket” opciót. Csak ne felejtse el beállítani megfelelő számú napra. A műszaki támogatás látott olyan eseteket, amikor az opciót kevesebb napra állították be, mint a szinkronizálás intervalluma – a BCJ őrjöngeni kezdett és törölte a pontokat anélkül, hogy létrehozta volna őket.
Vegye figyelembe azt is, hogy ez az opció nem érinti a már létrehozott GFS pontokat. Ha szeretné megtisztítani az archívumokat, azt manuálisan kell megtennie – jobb gombbal kattintva a gépre és kiválasztva a „Törlés a lemezről” lehetőséget (a megjelenő ablakban ne felejtse el beállítani a „GFS teljes biztonsági mentés eltávolítása” pipát):
Újdonság v.10 – azonnali másolat (immediate copy)
Miután megismertük a „klasszikus” funkciókat, áttérünk az újra. Az újdonság egy van, de nagyon fontos. Ez az új működési mód.
Itt nincs olyan fogalom, mint «szinkronizálási intervallum», a feladat folyamatosan figyelni fogja, hogy jelentek-e meg új pontok, és mindet másolni fogja, bármennyi is legyen belőlük. De a feladat továbbra is inkrementális marad, tehát még ha a fő feladat VBK-t vagy VRB-t hoz létre, ezek a pontok VIB-ként lesznek lemásolva. Egyébként ebben a módban nincsenek meglepetések – a standard és a GFS megőrzés a fent leírt szabályok szerint működik (igaz, itt csak szintetikus GFS érhető el).
Forgatják a lemezeket. A lemezek rotációs tárolóinak sajátosságai (rotated drives)
A folyamatos ransomware fenyegetés de facto biztonsági szabvánnyá tette az adatok olyan tárolón való meglétét, amelyhez a vírus nem férhet hozzá. Az egyik megoldás a lemezek rotációjával rendelkező tárolók használata, amikor a lemezek felváltva használatosak: míg az egyik lemez csatlakoztatva van és írásra elérhető, a többit biztonságos helyen tárolják.
Ahhoz, hogy a B&R megfelelően működjön ezekkel a tárolókkal, a tároló beállításainál, a Repository lépésnél kattintson az Advanced gombra, és válassza ki a megfelelő lehetőséget:
Ezután a VBR arra vár, hogy az időközben létező lánc eltűnjön a tárolóból, ami a lemez rotációját jelenti. A tároló típusától és a feladat típusától függően a B&R különbözően fog viselkedni. Ezt egy ilyen táblázattal lehet bemutatni:
Vizsgáljuk meg minden lehetőséget.
Normál feladat és Windows tároló
Tehát van egy feladatunk, amely az első lemezen tárolja a láncokat. A rotáció során a létrehozott lánc lényegében eltűnik, és a feladatnak valahogyan meg kell birkóznia ezzel a veszteséggel. Megnyugvást nyer egy teljes biztonsági mentés készítésével. Így minden rotáció egy teljes mentést jelent. De mi történik az offline lemezen lévő pontokkal? Ezeket megjegyzik és figyelembe veszik a megőrzés számításakor. Így a feladatban megadott pontszám az összes lemezen kívánt pontok száma. Például:
A feladat végtelen inkrementális módban működik, és úgy van beállítva, hogy 3 helyreállítási pontot tároljon. De van még egy második lemezünk, és hetente egyszer végezzük a rotációt (a lemezek száma lehet több is, ez nem változtat a lényegen).
Az első héten a feladat pontokat fog létrehozni az első lemezen, és összevonja a feleslegeseket. Így a pontok összesített száma három lesz:
Ezután csatlakoztatjuk a második lemezt. A B&R indításakor érzékelni fogja, hogy a lemez megváltozott. Az első lemezen lévő lánc eltűnik az interfészből, de az adatbázisban megmarad. Most a feladat 3 pontot fog tartani a második lemezen. A helyzet pedig a következő:
Végül ismét csatlakoztatjuk az első lemezt. A feladat új pont létrehozása előtt ellenőrzi, hogy mi a helyzet a retencióval. És a retenció, emlékeztetem, be van állítva, hogy 3 pontot tároljon. Közben 3 pont van a 2. lemezen (de az le van választva és biztonságos helyen tárolják, ahová a B&R nem tud eljutni) és 3 pont az 1. lemezen (ez viszont csatlakoztatva van). Ezért nyugodtan eltávolítható a 3 pont az 1. lemezről, mivel túllépik a retenciót. Ezt követően a feladat újra egy teljes biztonsági másolatot készít, és a láncunk így fog kinézni:
Ha a retenció napokat tárolásra van beállítva a pontok helyett, akkor a logika nem változik. Ezenkívül a GFS retenció egyáltalán nem támogatott disk rotációs adattárak használata esetén.
Hagyományos feladat és Linux adattár hálózati tárolóval
Ez a lehetőség is lehetséges, de általában kevésbé ajánlott a rájuk rakódó korlátok miatt. A disk rotációra és a lánc eltűnésére a feladat ugyanúgy reagál – egy teljes biztonsági másolat létrehozásával. A korlátozás a csökkentett retenciós mechanizmussal kapcsolatos.
Itt a rotáció során a lánc az eltávolított lemezen egyszerűen eltávolításra kerül a B&R adatbázisából. Ne feledje – az adatbázisból, a fájlok maguk azonban a lemezen maradnak. Importálhatók és helyreállításra használhatók, de nem nehéz kitalálni, hogy előbb vagy utóbb ezek az elfeledett láncok megtöltik az egész adattárat.
A megoldás a DWORD ForceDeleteBackupFiles hozzáadása, ahogy ezt ezen az oldalon megadva találja: . Ezt követően a feladat egyszerűen eltávolítja az összes tartalmat a feladat mappájából vagy az adattár mappájából (az értéktől függően) minden rotáció során.
Ez azonban nem elegáns retenció, hanem a teljes tartalom tisztítása. Sajnos a technikai támogatás során jelentkeztek olyan esetek, amikor a tárolóként egyszerűen a lemez gyökérmappáját jelölték meg, ahol a biztonsági másolatok mellett más adatok is találhatóak. Mindezek a rotáció során megsemmisültek.
Ezen kívül a ForceDeleteBackupFiles engedélyezése esetén minden típusú tárolóval működik, így még a Windows tárolók esetében is leállítja a megőrzési beállításokat, és elkezdi törölni a tartalmat. Más szavakkal, a Windows helyi lemeze a legjobb választás ilyen típusú biztonsági mentési rendszerhez.
Biztonsági másolat és Windows tároló
A BCJ-nál minden még érdekesebbé válik. Nemcsak, hogy teljes körű megőrzési beállítások állnak rendelkezésre, de nem szükséges minden lemezváltáskor teljes biztonsági másolatot készíteni! Így működik ez:
Először a B&R elkezdi létrehozni a pontokat az első lemezen. Tegyük fel, hogy a megőrzési beállítást 3 pontra állítottuk be. A feladat végtelen inkrementális módban fog működni, és összevonja az összes felesleges adatot (emlékezzünk, GFS megőrzés nem támogatott ebben az esetben).
Ezután csatlakoztatjuk a második lemezt. Mivel ezen még nincs láncolat, így teljes biztonsági másolatot készítünk, és ezután létrejön egy újabb láncolat három pontból:
Végül elérkezik az idő, hogy ismét csatlakoztassuk az első lemezt. Itt kezdődik a varázslat, mivel a feladat nem készít teljes biztonsági másolatot, hanem egyszerűen folytatja az inkrementális láncot:
Ezután ténylegesen minden lemezen saját független láncolat fog létezni. Ezért a megőrzés itt nem jelenti a pontok számát az összes lemezen, hanem a pontok számát minden egyes lemezen külön-külön.
Biztonsági másolat és Linux tároló hálózati tároló
Ismét, minden elegancia eltűnik, ha a tároló nem a Windows helyi lemezen található. Ez a szcenárió hasonlóan működik, mint a fent leírt egyszerű feladat. Minden rotáció során a BCJ teljes biztonsági másolatot fog létrehozni, míg a meglévő pontokat elfelejtjük. A szabad hely megőrzése érdekében érdemes használni a DWORD ForceDeleteBackupFiles beállítást.
Zárás
Így a hosszú szöveg végén kétféle feladatot elemeztünk. Természetesen sokkal több feladat van, de azokat egy cikk keretein belül nem tudjuk áttekinteni. Ha a cikk olvasása után kérdéseid vannak, írj kommentet, szívesen válaszolok személyesen.
Forrás: habr.com
