Kedves blogunk olvasói! Részben már ismerkedünk - itt jelentek meg angol nyelvű bejegyzéseim kedves kolléganőm fordításában . Ezúttal úgy döntöttem, hogy közvetlenül az orosz ajkú közönséghez szólok.
Debütáláshoz olyan témát szerettem volna találni, amely a lehető legszélesebb közönség számára érdekes és részletes átgondolást igényel. Daniel Defoe azzal érvelt, hogy a halál és az adók mindenkire várnak. A magam részéről elmondhatom, hogy a helyreállítási pontok tárolására (vagy egyszerűbben a megőrzésre) vonatkozó házirendekkel kapcsolatban minden támogatási mérnök vár kérdéseket. 4 évvel ezelőtt XNUMX. szintű junior mérnökként kezdtem el magyarázni, hogyan működik a megtartás, és most a spanyol és olasz nyelvű csapat vezetőjeként folytatom a magyarázatot. Biztos vagyok benne, hogy a második, sőt a harmadik szintű támogatási szintről kollégáim is rendszeresen válaszolnak ugyanezekre a kérdésekre.
Ennek fényében szerettem volna egy végleges, minél részletesebb bejegyzést írni, amelyre az oroszul beszélők újra és újra visszatérhettek referenciaként. A pillanat megfelelő – a nemrégiben megjelent tizedik évfordulós verzió új funkciókkal egészítette ki az évek óta változatlan alapfunkciókat. Hozzászólásom elsősorban erre a verzióra koncentrál - bár a leírtak nagy része igaz a korábbi verziókra is, a leírt funkciók egy részét egyszerűen nem találja ott. Végezetül, kicsit a jövőbe tekintve elmondom, hogy a következő verzióban is várható némi változás, de erről majd ha eljön az ideje. Tehát kezdjük.
Biztonsági mentési feladatok
Először nézzük meg azt a részt, amely nem változott a 10-es verzióban. A megőrzési szabályzatot több paraméter határozza meg. Nyissuk meg az ablakot egy új feladat létrehozásához, és menjünk a Tárolás fülre. Itt látni fogunk egy paramétert, amely meghatározza a visszaállítási pontok kívánt számát:
Ez azonban csak egy része az egyenletnek. A tényleges pontok számát a munkához beállított mentési mód is meghatározza. Az opció kiválasztásához kattintson a Speciális gombra ugyanazon a lapon. Ez egy új ablakot nyit meg számos lehetőséggel. Számozzuk meg őket, és nézzük meg egyenként:
Ha csak az 1. opció engedélyezve van, a job "végtelenül növekményes" módban fut (örökké előre növekményes). Nincsenek nehézségek - a feladat eltárolja a beállított számú visszaállítási pontot a teljes biztonsági mentéstől (VBK kiterjesztésű fájl) az utolsó lépésig (VIB kiterjesztésű fájl). Ha a pontok száma meghaladja a beállított értéket, a legrégebbi növekmény egyesül a teljes biztonsági másolattal. Más szóval, ha a feladat úgy van beállítva, hogy 3 pontot tároljon, akkor közvetlenül a következő munkamenet után 4 pont lesz a tárhelyen, ami után a teljes mentés összevonódik a legrégebbi lépésekkel és az összes pont visszaáll 3.
Szintén rendkívül egyszerű a „fordított inkrementális” (fordított inkrementális) mód megtartása (2. opció). Mivel ebben az esetben a legújabb pont egy teljes biztonsági mentés lesz, amelyet úgynevezett visszagörgetések (VRB kiterjesztésű fájlok) láncolata követ, a megőrzés alkalmazásához elegendő a legrégebbi visszaállítást egyszerűen törölni. A helyzet ugyanaz lesz: közvetlenül a foglalkozás után a pontok száma 1-gyel meghaladja a beállított értéket, majd visszaáll a kívánt értékre.
Vegye figyelembe, hogy a fordított növekményes módban engedélyezheti az időszakos teljes biztonsági mentéseket is (4. lehetőség), de ez nem változtat a lényegen. Igen, a teljes visszaállítási pontok megjelennek a láncban, de akkor is csak a legrégebbi pontokat töröljük egyenként.
Végül elérkeztünk az érdekes részhez. Ha engedélyezi a növekményes biztonsági mentést, de engedélyezi a 3. vagy 4. opciót (vagy mindkettőt egyszerre), a feladat elkezdi az időszakos teljes biztonsági mentések létrehozását az "aktív" vagy szintetikus módszerrel. A teljes biztonsági másolat létrehozásának módja nem fontos - ugyanazokat az adatokat fogja tartalmazni, és a növekményes lánc "alláncokra" lesz osztva. Ezt a módszert forward inkrementálisnak nevezzük, és ő okozza a vásárlóink kérdéseinek jelentős részét.
A megőrzés itt a lánc legrégebbi részének törlésével történik (a teljes biztonsági mentéstől a növekményig). Ugyanakkor nem töröljük csak az üres biztonsági másolatot, vagy csak a lépések egy részét. A teljes "alláncot" egyszerre teljesen eltávolítják. Változik a pontok számának beállításának jelentése is - ha más módszereknél ez a maximálisan megengedett szám, ami után visszatartást kell alkalmazni, akkor itt ez a beállítás határozza meg a minimális számot. Vagyis a legrégebbi "allánc" törlése után a maradék rész pontjainak száma nem eshet e minimum alá.
Megpróbálom grafikusan ábrázolni ezt a fogalmat. Tegyük fel, hogy a megőrzés 3 pontra van állítva, a feladat minden nap fut, hétfőn teljes mentéssel. Ebben az esetben a visszatartás akkor kerül alkalmazásra, ha az összes pont eléri a 10-et:
Miért már 10, amikor 3-at tesznek fel? Hétfőn teljes biztonsági mentés készült. Keddtől vasárnapig a munka növekményt hozott. Végül jövő hétfőn ismét teljes mentés készül és csak 2 lépés létrehozása után lehet végre a teljes régi láncrészt törölni, mert a maradék pontok száma nem esik a beállított 3 alá.
Ha az ötlet világos, akkor azt javaslom, hogy próbálja meg saját maga kiszámítani a visszatartást. Vegyük a következő feltételeket: a feladat először csütörtökön indul el (természetesen teljes mentés készül). A feladat úgy van beállítva, hogy szerdánként és vasárnaponként készítsen teljes biztonsági másolatot, és 8 visszaállítási pontot tároljon. Mikor alkalmazzák először a visszatartást?
A kérdés megválaszolásához azt javaslom, hogy vegyen egy papírlapot, rajzolja le a hét napjai szerint, és írja le, hogy minden nap melyik pont jön létre. A válasz nyilvánvaló lesz
Válasz
Pontosítás: A válaszhoz elég feltenni magának a kérdést: „mikor alkalmazzák a visszatartást”? A válasz az, hogy mikor tudjuk eltávolítani az első 3 pontot (VBK, VIB, VIB), és a lánc többi része nem esik a szükséges 8 pont alá. Egyértelművé válik, hogy ezt akkor tudjuk megtenni, ha összesen 11 pontunk lesz, vagyis a második hét vasárnapján.
Néhány olvasó tiltakozhat: „miért mindez, ha van ? Kétségtelenül nagyon hasznos eszköz, és bizonyos esetekben én is használnám, de vannak korlátai is. Először is nem teszi lehetővé a kezdeti feltételek megadását, és sok esetben pontosan az a kérdés, hogy „van egy ilyen láncunk, mi lesz, ha változtatunk ilyen-olyan beállításokon?”. Másodszor, az eszköz még mindig nem látható. Az RPS oldalt az ügyfeleknek megmutatva nem találtam megértést, de a példában szereplő festés után (akár ugyanazt a Paint-et használva) napról napra minden világossá vált.
Végül nem vettük figyelembe a „Korábbi mentési láncok átalakítása visszagörgetésekké” opciót (5-ös számmal jelölve). Ez az opció néha megzavarja azokat az ügyfeleket, akik "menet közben" aktiválják, és egy egyszerű szintetikus biztonsági mentést szeretnének engedélyezni. Eközben ez az opció egy nagyon speciális biztonsági mentési módot aktivál. Anélkül, hogy belemennék a részletekbe, mindjárt leszögezem, hogy a termékfejlesztés jelenlegi szakaszában a „Korábbi biztonsági láncok átalakítása visszaállításokká” elavult lehetőség, és egyetlen forgatókönyv sem jut eszembe, hogy mikor kellene használni. Értéke annyira kétséges, hogy egy ideig maga Anton Gostev küldött egy hívást a fórumon keresztül, és kérte, hogy küldjön példákat a hasznos felhasználására (ha van, írja meg a megjegyzésekben, nagyon érdekel). Ha nincs ilyen (szerintem lesz), akkor a későbbi verziókban ez a lehetőség el lesz távolítva.
A feladat növekményt (VIB) hoz létre a szintetikus teljes biztonsági mentés ütemezéséig. Ezen a napon valóban létrejön a VBK, de a VBK előtti összes pontot visszagörgetéssé (VRB) alakítják át. Ezt követően a feladat a következő szintetikus biztonsági mentésig folytatja a lépések létrehozását a teljes biztonsági másolathoz. Ennek eredményeként a VBK, VBR és VIB fájlok robbanékony keveréke jön létre a láncban. A visszatartás nagyon egyszerűen alkalmazható - az utolsó VBR eltávolításával:
Problémák
Eltekintve attól, hogy ténylegesen megérti, hogyan működik, a legtöbb probléma, amely a növekményes mód használata során merül fel, általában a teljes biztonsági mentéshez kapcsolódik. Ehhez a módhoz rendszeres teljes biztonsági mentés szükséges, különben a tároló pontokat halmoz fel, amíg túlcsordul.
Például előfordulhat, hogy túl ritkán készül teljes biztonsági másolat. Tegyük fel, hogy a feladat úgy van beállítva, hogy 10 pontot tároljon, és havonta egyszer teljes biztonsági mentés készül. Nyilvánvaló, hogy a tényleges pontok száma itt sokkal nagyobb lesz, mint a beállított. Vagy a feladat általában úgy van beállítva, hogy végtelen növekményes módban működjön, és 50 pontot tároljon. Aztán valaki véletlenül teljes biztonsági másolatot készített. Ennyi, innentől a feladat megvárja, amíg a teljes pont 49 lépést halmoz fel, ezután alkalmazza a megtartást és visszatér a végtelen-teli módba.
Más esetekben a rendszer be van állítva egy teljes biztonsági másolat rendszeres létrehozására, de valamiért nem. Ide sorolom a legnépszerűbb okot. Egyes ügyfelek szívesebben használják a „futtatás után” ütemezési opciót, és úgy állítják be a feladatokat, hogy láncban futjanak. Vegyük ezt a példát: van 3 olyan feladat, amely minden nap lefut, és vasárnap hoz létre egy teljes biztonsági másolatot. Az első feladat 22.30-kor kezdődik, a többit láncban indítják. A növekményes biztonsági mentés 10 percet vesz igénybe, így 23.00:22.30-ra minden feladat befejezi a munkáját. De a teljes mentés egy órát vesz igénybe, így vasárnap a következő történik: az első feladat 23.30-tól 23.30-ig tart. A következő időpont 00.30-XNUMX között lesz. De a harmadik feladat hétfőn indul. A teljes biztonsági mentés vasárnapra van konfigurálva, tehát ebben az esetben egyszerűen nem lesz. A feladat megvárja a teljes biztonsági mentést a megőrzés alkalmazásához. Ezért legyen óvatos, amikor a „futtatás után” opciót használja, vagy ne használja azt – csak állítsa be, hogy a jobok egyszerre induljanak el, és hagyja, hogy az erőforrás-ütemező elvégezze a feladatát.
A nehéz lehetőség „Törölt elemek eltávolítása”
A Tárolás - Haladó - Karbantartás feladat beállításait végigjárva a napokban számolva a „törölt tételek adatainak eltávolítása után” opcióba botlik.
Egyes ügyfelek azt várják, hogy ez a visszatartás. Valójában ez egy teljesen külön lehetőség, amelynek félreértése váratlan következményekkel járhat. Mindenekelőtt azonban el kell magyaráznom, hogyan reagál a B&R azokra a helyzetekre, amikor csak néhány gépről van sikeres biztonsági mentés a munkamenet során.
Képzelje el ezt a forgatókönyvet: egy végtelen növekményes feladat, amely 6 pont tárolására van konfigurálva. 2 gép van a feladatban, az egyik mindig sikeresen mentett, a másik néha hibákat adott. Ennek eredményeként a hetedik pontra a következő helyzet alakult ki:
Ideje alkalmazni a visszatartást, de az egyik gépnek 7 pontja van, a másiknak csak 4. Itt is érvényes lesz a visszatartás? A válasz igen, így lesz. Ha legalább egy objektum mentésre került, a B&R úgy tekinti, hogy a pont létrejött.
Hasonló helyzet állhat elő, ha egy bizonyos munkamenet során egyszerűen nem szerepelt a feladatban egy gép. Ez például akkor fordul elő, ha a gépeket nem egyenként, hanem konténerek (mappák, tárolók) részeként adják hozzá a feladathoz, és néhány gép átmenetileg egy másik tárolóba költözik. A munka ekkor sikeresnek minősül, de a statisztikában talál egy üzenetet, amely arra figyelmeztet, hogy figyeljen arra, hogy ilyen és olyan gépet már nem dolgoz fel a munka.
Mi lesz, ha nem figyelsz rá? Végtelen növekményes vagy fordított növekményes módok esetén a "problémás" gép visszaállítási pontjainak száma munkamenetenként csökken, amíg el nem éri a VBK-ban elmentett 1-et. Más szóval, még akkor is, ha a gépről hosszú ideig nem készül biztonsági mentés, egy visszaállítási pont továbbra is megmarad. Ez nem így van, ha az időszakos teljes biztonsági mentés engedélyezve van. Ha a B&R jeleit figyelmen kívül hagyja, az utolsó pont a lánc régi részével együtt törlésre kerülhet.
Miután megértette ezeket a részleteket, végre mérlegelhetjük a „Törölt elemek adatainak eltávolítása után” lehetőséget. Törli az összes pontot egy adott géphez, ha a gépről X napig nem készül biztonsági mentés. Felhívjuk figyelmét, hogy ez a beállítás nem reagál a hibákra (kipróbált - nem működött). Még csak meg sem kísérelheti biztonsági másolat készítését a gépről. Úgy tűnik, hogy ez az opció hasznos, és mindig engedélyezve kell tartani. Ha az adminisztrátor eltávolította a gépet a feladatból, akkor logikus, hogy egy idő után megtisztítja a felesleges adatok láncát. A hangolás azonban fegyelmet és odafigyelést igényel.
Mondok egy példát a gyakorlatból: több konténer is került a feladathoz, amelyek összetétele meglehetősen dinamikus volt. A RAM hiánya miatt a B&R szerver olyan problémákat tapasztalt, amelyek észrevétlenek maradtak. A feladat elindult, és megpróbált biztonsági másolatot készíteni a gépekről, kivéve egyet, amely akkor még nem volt a konténerben. Mivel sok gép hibát generált, alapértelmezés szerint a B&R-nek további 3 kísérletet kell tennie a "problémás" gépek biztonsági mentésére. A RAM-mal kapcsolatos állandó problémák miatt ezek a próbálkozások több napig elhúzódtak. Nem történt második kísérlet a hiányzó virtuális gép biztonsági mentésére (a virtuális gép hiánya nem hiba). Ennek eredményeként az egyik ismételt próbálkozás során a „Törölt elemek eltávolítása” feltétel teljesült, és a gép összes pontja törlődött.
Ebből az alkalomból a következőket mondhatom: ha értesítéseket kap a beállított feladatok eredményeiről, és még jobb, ha a Veeam ONE-nal való integrációt használják, akkor valószínűleg ez nem fog megtörténni veled. Ha hetente egyszer megnézi a B&R szervert, hogy ellenőrizze, hogy minden működik-e, akkor jobb, ha elutasítja azokat a lehetőségeket, amelyek potenciálisan a biztonsági másolatok törléséhez vezethetnek.
A v.10 újdonságai
Amiről már korábban is beszéltünk, az a B&R-nél már sok változatnál megvolt. Miután megértette ezeket a munkaelveket, nézzük meg, mi került be a jubileumi „első tízbe”.
Napi tartás
Fentebb a "klasszikus" tárolási szabályzatot vettük figyelembe a pontok száma alapján. Alternatív megoldás, ha ugyanabban a menüben a „helyreállítási pontok” helyett „napokat” állít be.
Az ötlet a névből egyértelmű - a megőrzés a beállított számú napot tárolja, az egyes napok pontjainak száma nem számít. Ennek során ne feledje a következőket:
- Az aktuális napot nem veszik figyelembe a visszatartás számításánál
- Azok a napok is számítanak, amikor a feladat egyáltalán nem működött. Ezt érdemes szem előtt tartani, hogy véletlenül se veszítse el pontjait a szabálytalanul működő feladatoknak.
- A visszaállítási pontot a létrehozás napjától számítja (azaz ha a feladat hétfőn kezdődött és kedden fejeződött be, akkor ez egy hétfői pont)
Egyébként a feladatokonkénti megőrzés alkalmazásának elveit is a választott mentési módszer határozza meg. Próbáljunk meg egy másik számítási feladatot ugyanazzal a növekményes módszerrel. Tegyük fel, hogy a megőrzés 8 napra van beállítva, a feladat 6 óránként fut le teljes biztonsági mentéssel szerdán. Ebben az esetben a feladat vasárnap nem működik. A munka hétfőn zajlik először. Mikor alkalmazzák a visszatartást?
Válasz
Szokás szerint a legjobb jelet rajzolni. Megengedem magamnak, hogy egyszerűsítsem a feladatot, és nem fogom kihúzni az egyes napokra létrehozott összes pontot, mert itt nem számít a napi pontok száma. Számunkra csak az a fontos, hogy az első hétfőn és szerdán az első pont egy teljes mentés legyen, a többi napon a feladat egyszerűen 4 növekményes pontot hoz létre.
Megértjük magunkat, hogy a megőrzést a hétfői teljes biztonsági másolat és annak növekményének törlésével alkalmazzuk. Mikor fog megtörténni? Amikor a lánc többi része 8 napot fog tartalmazni. Ugyanakkor nem az aktuális napot számoljuk, hanem a vasárnapot, ellenkezőleg, számolunk. Tehát a válasz a második hét csütörtökje.
GFS archiválás normál munkákhoz
A 10-es verzió előtt a Grandfather-Father-Son (GFS) tárolási módszer csak a biztonsági mentési és szalagos másolási feladatokhoz volt elérhető. Mostantól rendszeres biztonsági mentésre is elérhető.
Bár ez nem kapcsolódik az aktuális témához, nem állíthatom, hogy az új funkcionalitás nem jelent eltérést a 3-2-1 stratégiától. Az archív pontok jelenléte a fő tárolóban semmilyen módon nem befolyásolja annak megbízhatóságát. Nyilvánvaló, hogy a GFS-t egy kibővített adattárral együtt fogják használni, hogy ezeket a pontokat S3-ba és hasonló tárolókra szállítsák. Ha nem használja, akkor jobb, ha továbbra is tárolja az elsődleges és archív pontokat különböző tárolókban.
Most nézzük meg a GFS-pontok létrehozásának alapelveit. A feladatbeállítások között a Tárolás lépésben megjelent egy speciális gomb, amely a következő menüt hívja meg:
A GFS lényege több pontra redukálható (megjegyzendő, hogy a GFS más típusú feladatokban másként működik, de erről később):
- A feladat nem hoz létre külön teljes biztonsági másolatot a GFS-pont alatt. Ehelyett a legmegfelelőbb elérhető teljes biztonsági másolat kerül felhasználásra. Ezért a jobnak növekményes módban kell futnia, időszakos teljes biztonsági mentéssel, vagy a felhasználónak manuálisan kell teljes biztonsági másolatot létrehoznia.
- Ha csak egy időszak van engedélyezve (például egy heti időszak), akkor a GFS időszak elején a feladat egyszerűen elkezd várni a teljes biztonsági mentésre, és az első megfelelőt GFS-ként jelöli meg.
Példa: Egy job úgy van konfigurálva, hogy egy szerdai biztonsági mentés segítségével heti GFS-t tároljon. A feladat minden nap lefut, de a teljes biztonsági mentés péntekre van ütemezve. Ebben az esetben szerdán kezdődik a GFS időszak, és a feladat elkezdi várni a megfelelő pontot. Pénteken jelenik meg, és a GFS zászlóval lesz jelölve.
- Ha egyszerre több periódus van engedélyezve (például heti és havi), akkor a B&R olyan módszert alkalmaz, amely lehetővé teszi, hogy ugyanazt a pontot több intervallum GFS-eként használják (helytakarékosság érdekében). A zászlókat felváltva osztják ki, a legfiatalabbtól kezdve.
Példa: a heti GFS szerdára, a havi GFS pedig a hónap utolsó hetére van beállítva. A feladat minden nap fut, és hétfőn és pénteken hoz létre teljes biztonsági másolatot.
Az egyszerűség kedvéért kezdjük a számolást a hónap utolsó előtti hetétől. Ezen a héten hétfőn jön létre a teljes biztonsági mentés, de figyelmen kívül hagyjuk, mert a heti GFS-intervallum szerdán kezdődik. De a pénteki teljes mentés teljesen alkalmas a GFS pontra. Ez a rendszer már ismerős számunkra.
Most gondold át, mi fog történni a hónap utolsó hetében. A havi GFS-intervallum hétfőn kezdődik, de a hétfői VBK-t nem jelölik meg GFS-ként, mivel a munka egy VBK-t kíván havi és heti GFS-pontként is megjelölni. Ugyanakkor a keresés a hetivel kezdődik, ezért értelemszerűen havivá is válhat.
Ha azonban csak a heti és az éves intervallumok vannak engedélyezve, ezek egymástól függetlenül működnek, és 2 különálló VBK-t jelölhetnek meg megfelelő GFS-intervallumként.
Másolási feladatok
Egy másik típusú feladat, amely gyakran pontosítást igényel a munkával kapcsolatban. Kezdésként elemezzük a „klasszikus” munkamódszert, innovációk nélkül, v.10
Egyszerű tartási módszer
Alapértelmezés szerint az ilyen jobok végtelen növekményes módban futnak. A pontok létrehozását két paraméter határozza meg - a másolási intervallum és a kívánt visszaállítási pontok száma (itt nincs napi megőrzés). A másolási időköz az első Feladat lapon van beállítva munka létrehozásakor:
A pontok számát kicsit távolabb, a Cél fülön határozzuk meg
A job intervallumonként 1 új pontot hoz létre (nem számít, hogy az eredeti jobok hány pontot hoztak létre a virtuális gép számára). Az intervallum végén az új pont véglegesítésre kerül, és ha szükséges, a VBK és a legrégebbi növekmény összefűzésével visszatartást alkalmazunk. Ez a mechanizmus már ismerős számunkra.
Retenciós módszer GFS használatával
A BCJ archivált pontokat is tárolhat. Ez ugyanazon a Cél lapon van konfigurálva, közvetlenül a visszaállítási pontok beállításai alatt:
A GFS-pontok kétféleképpen hozhatók létre - szintetikusan, a másodlagos adattáron lévő adatok felhasználásával, vagy egy teljes biztonsági mentés szimulálásával és az összes adat kiolvasásával az elsődleges tárolóból (a 3-as számmal jelölt opcióval aktiválva). A megtartás mindkét esetben nagyon eltérő lesz, ezért ezeket külön fogjuk figyelembe venni.
Szintetikus GFS
Ebben az esetben a GFS pont nem pontosan a kijelölt napon jön létre. Ehelyett egy GFS-pont jön létre, amikor a GFS-pont létrehozásának ütemezése szerinti nap VIB-jét egyesítik a teljes biztonsági másolattal. Ez néha félreértést okoz, mert telik az idő, de még mindig nincs GFS pont. És csak a technikai támogatás erős sámánja tudja megjósolni, hogy melyik napon jelenik meg a pont. Valójában nincs szükség varázslatra - csak nézze meg a beállított pontok számát és a szinkronizálási intervallumot (hány pont jön létre naponta). Próbáld meg kiszámolni magad a példa segítségével: a feladat 7 pont tárolására van beállítva, a szinkronizálási intervallum 12 óra (azaz napi 2 pont). Jelenleg már 7 pont van a láncban, ma hétfő van, erre a napra tervezik a GFS pont létrehozását. Melyik napon jön létre?
Válasz
Itt jobb leírni, hogyan változik a lánc dinamikája napról napra:
Tehát hétfőn a lánc utolsó lépése GFS-ként van megjelölve, de más látható változás nem történik. A feladat minden nap 2 új pontot hoz létre, és a megtartás menthetetlenül előreviszi a láncot. Végül, csütörtökön itt az ideje, hogy a visszatartást ugyanarra a növekményre alkalmazzuk. Ez a munkamenet tovább tart a szokásosnál - mert a feladat "kihúzza" a szükséges blokkokat a láncból, és új teljes pontot hoz létre. Ezentúl 8 pont lesz a láncban - 7 a főláncban + GFS.
GFS-pontok létrehozása a „Teljes pont olvasása” opcióval
Fentebb azt mondtam, hogy a BCJ végtelen növekményes módban működik. Most elemezzük a szabály alóli egyetlen kivételt. Ha engedélyezi a „Teljes pont olvasása” opciót, a GFS pont pontosan az ütemezett napon jön létre. Maga a feladat növekményes módban fog működni, időszakos teljes biztonsági mentésekkel, amit fentebb tárgyaltunk. A visszatartás a lánc legrégebbi részének eltávolításával is érvényesül. Ebben az esetben azonban csak a növekmény törlődik, és a teljes biztonsági másolat GFS-pontként marad meg. Ennek megfelelően a GFS zászlókkal jelölt pontokat nem veszik figyelembe a visszatartás kiszámításakor.
Tegyük fel, hogy a feladat úgy van beállítva, hogy 7 pontot tároljon, és hétfőn hozzon létre egy heti GFS-pontot. 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 megőrzés akkor kerül alkalmazásra, ha a legrégebbi részből való növekmény törlése után a fennmaradó lépések száma nem csökken 7 alá. Így néz ki a diagramon:
Így a második hét végére összesen 14 pont van a láncban. A második héten a feladat 7 pontot ért el. Ha egyszerű feladatról lenne szó, a visszatartást már alkalmazták volna. De ez egy BCJ GFS-megtartással, ezért nem számolunk GFS-pontokkal, ami azt jelenti, hogy csak 6. Azaz továbbra sem tudjuk alkalmazni a megtartást. A harmadik héten újabb teljes biztonsági másolatot készítünk a GFS jelzővel. 15 pont, de ezt megint nem számoljuk. És végül, a harmadik hét keddjén létrehozunk egy növekményt. Most, ha eltávolítjuk az első heti lánc növekményeit, a növekmények teljes száma kielégíti a beállított megtartást.
Mint fentebb említettük, ennél a módszernél nagyon fontos, hogy rendszeresen teljes biztonsági másolatot készítsenek. Például, ha a fő megőrzést 7 napra állítja, de csak 1 éves pontot, akkor könnyen elképzelhető, hogy a növekmény sokkal-sokkal több lesz, mint 7. Ilyen esetekben jobb a szintetikus létrehozási módszert használni. GFS.
És ismét „Törölt elemek eltávolítása”
Ez a lehetőség a BCJ-nél is elérhető:
Ennek az opciónak a logikája itt ugyanaz, mint a normál mentési feladatoknál - ha a gépet nem dolgozzák fel a megadott számú napig, akkor az adatai törlődnek a láncból. Azonban a BCJ számára ez a lehetőség objektíven hasznosabb, és itt van miért.
Normál módban a BCJ végtelen növekményes módban működik, tehát ha egy ponton a gépet eltávolítják a feladatból, akkor a megőrzés fokozatosan törli az összes helyreállítási pontot, amíg csak egy marad - a VBK-ban. Most képzeljük el, hogy a feladat szintetikus GFS-pontok létrehozására is be van állítva. Amikor eljön az ideje, a munkának létre kell hoznia egy GFS-t a lánc összes gépéhez. Ha egy gépen egyáltalán nincsenek új pontok - nos, akkor azt kell használni, amelyik van. És így minden alkalommal. Ennek eredményeként a következő helyzet állhat elő:
Figyeld a Fájlok részt: megvan a fő VBK és heti 2 GFS pont. És most a Visszaállítási pontok részhez – valójában ezek a fájlok a gép ugyanazt a képét tartalmazzák. Az ilyen GFS pontoknak természetesen semmi értelme, csak helyet foglalnak.
Ez a helyzet csak szintetikus GFS használata esetén lehetséges. Ennek elkerülése érdekében használja a „Törölt elemek eltávolítása” opciót. Ne felejtse el megfelelő számú napra beállítani. A műszaki támogatás tapasztalt olyan eseteket, amikor az opciót a szinkronizálási intervallumnál kevesebb napra állították be – a BCJ tombolni kezdett, és pontokat törölt, mielőtt idejük lett volna létrehozni őket.
Vegye figyelembe azt is, hogy ez az opció nincs hatással a meglévő GFS-pontokra. Ha az archívumot szeretné megtisztítani, azt manuálisan kell megtennie - jobb gombbal a gépre kattintva és a "Törlés a lemezről" kiválasztásával (a megjelenő ablakban ne felejtse el bejelölni a "GFS teljes biztonsági másolat eltávolítása" jelölőnégyzetet) :
Innovation v.10 – azonnali másolat (azonnali másolat)
Miután foglalkoztunk a „klasszikus” funkcióval, térjünk át az újra. Az innováció az egyik, de nagyon fontos. Ez egy új működési mód.
Nincs olyan, hogy „szinkronizálási intervallum”, a feladat folyamatosan figyeli, hogy megjelentek-e új pontok, és mindet másolja, függetlenül attól, hogy hány van. A job azonban növekményes marad, ami azt jelenti, hogy még ha a fő job VBK-t vagy VRB-t hoz létre, ezek a pontok VIB-ként lesznek másolva. Egyébként ebben a módban nincs meglepetés - mind a normál, mind a GFS-megtartás a fent leírt szabályok szerint működik (bár itt csak szintetikus GFS érhető el).
A lemezek forognak. A Rotated Drives Repository jellemzői
A ransomware vírusok folyamatos fenyegetése tette a de facto biztonsági szabvánnyá, hogy az adatok másolata olyan adathordozón legyen, ahová a vírus nem érheti el. Az egyik lehetőség a lemezforgató tárolók használata, ahol a lemezeket felváltva használjuk: amíg az egyik lemez csatlakoztatva van és írható, a többi biztonságos helyen van tárolva.
Ha meg szeretné tanítani a B&R-t az ilyen tárolókkal való együttműködésre, a lerakat beállításainál a Repository lépésben kattintson a Speciális gombra, és válassza ki a megfelelő opciót:
Ezt követően a VBR megvárja, amíg az időszakosan létező lánc eltűnik a tárolóból, ami lemezforgatást jelent. Az adattár típusától és a munka típusától függően a B&R eltérően fog viselkedni. Ezt egy ilyen táblázattal ábrázolhatja:
Vegyük fontolóra az egyes lehetőségeket.
Normál Job és Windows Repository
Tehát van egy feladatunk, amely a láncokat az első lemezre menti. A forgás során a létrehozott lánc valójában eltűnik, és a feladatnak valahogy túl kell élnie ezt a veszteséget. A teljes biztonsági másolat létrehozásában vigasztalódik. Így minden forgatás teljes mentést jelent. De mi történik a pontokkal a leválasztott meghajtón? Megjegyzik és figyelembe veszik a visszatartás kiszámításakor. Így a feladatban beállított pontok száma az, hogy hány pontot kell az összes lemezen megtartani. Íme egy példa:
A feladat végtelen növekményes módban fut, és 3 visszaállítási pont tárolására van beállítva. De van egy második lemezünk is, azt hetente egyszer forgatjuk (lehet több lemez is, ez a lényegen nem változtat).
Az első héten a feladat pontokat hoz létre az első lemezen, és egyesíti a továbbiakat. Így az összes pont három lesz:
Ezután csatlakoztatjuk a második lemezt. Indításkor a B&R észreveszi, hogy a meghajtó megváltozott. Az első lemezen lévő lánc eltűnik az interfészről, de az erről szóló információk megmaradnak az adatbázisban. A feladat most 3 pontot fog tartalmazni a második lemezen. Az általános helyzet a következő lesz:
Végül visszacsatoljuk az első meghajtót. Új pont létrehozása előtt a feladat ellenőrzi, hogy mi van ott a megtartással. És emlékeztetem önöket, a megőrzés 3 pont tárolására van beállítva. Addig is van 3 pont a 2. lemezen (de offline állapotban van, és biztonságos helyen van tárolva, ahol a B&R nem érheti el) és 3 pont az 1. lemezen (de ez csatlakoztatva van). Tehát nyugodtan eltávolíthat 3 pontot az 1. lemezről, mivel ezek meghaladják a megőrzést. Ezt követően a feladat újra létrehoz egy teljes biztonsági másolatot, és a láncunk így kezd kinézni:
Ha a megőrzés úgy van beállítva, hogy a pontok száma helyett napokat tároljon, akkor a logika nem változik. Ezenkívül a GFS-megtartás egyáltalán nem támogatott lemezforgatással rendelkező adattárak használatakor.
Normál Job és Linux Repository Network Storage
Ez a lehetőség is lehetséges, de általában kevésbé ajánlott a korlátozások miatt. A feladat ugyanúgy reagál a lemez forgására és a lánc eltűnésére - teljes biztonsági mentés létrehozásával. A korlátozás a csonka rögzítési mechanizmushoz kapcsolódik.
Itt a forgatás során a leválasztott lemezen lévő teljes lánc egyszerűen törlődik a B&R adatbázisból. Figyeljen - az adatbázisból maguk a fájlok a lemezen maradnak. Importálhatók és felhasználhatók helyreállításra, de nem nehéz kitalálni, hogy előbb-utóbb ilyen elfeledett láncok kitöltik az egész tárat.
A megoldás a DWORD ForceDeleteBackupFiles hozzáadása az ezen az oldalon jelzett módon: . Ezt követően a feladat egyszerűen elkezdi törölni a feladatmappa vagy a repository mappa teljes tartalmát (az értéktől függően) minden forgatáskor.
Ez azonban nem egy elegáns megtartás, hanem inkább a tartalom megtisztítása. Sajnos a technikai támogatás találkozott olyan esetekkel, amikor a tároló egyszerűen a lemez gyökérkönyvtára volt, ahol a biztonsági mentéseken kívül más adatok is voltak. Mindez a forgatás során megsemmisült.
Ezen túlmenően, ha a ForceDeleteBackupFiles engedélyezve van, minden típusú adattárral működik, vagyis még a Windows rendszeren lévő tárolók is leállítják a megőrzést, és megkezdik a tartalom törlését. Más szavakkal, a Windows helyi lemeze a legjobb választás egy ilyen biztonsági mentési tárolórendszerhez.
Biztonsági másolat és Windows tároló
A BCJ-vel a dolgok még érdekesebbekké válnak. Nem csak teljes értékű megőrzés van, de nem kell minden lemezcserénél teljes biztonsági másolatot készíteni! Ez így működik:
Először a B&R elkezdi pöttyöket készíteni az első lemezen. Tegyük fel, hogy a megtartást 3 pontra állítjuk. A feladat végtelen növekményes módban fog működni, és minden feleslegeset egyesít (emlékeztem arra, hogy a GFS-megtartás ebben az esetben nem támogatott).
Ezután csatlakoztatjuk a második lemezt. Mivel még nincs rajta lánc, készítünk egy teljes mentést, ami után van egy második hárompontos láncunk:
Végül itt az ideje az első meghajtó újracsatlakoztatásának. És itt jön be a varázslat, mivel a feladat nem hoz létre teljes biztonsági másolatot, hanem csak folytatja a növekményes láncot:
Ezt követően tulajdonképpen minden lemeznek saját független lánca lesz. Ezért a megőrzés itt nem az összes lemezen lévő pontok számát jelenti, hanem az egyes lemezeken külön-külön.
Biztonsági másolat és Linux adattár hálózati tárhely
Ismét minden elegancia elvész, ha a tárhely nem a helyi Windows meghajtón található. Ez a szkript a fenti egyszerű feladathoz hasonlóan működik. A BCJ minden forgatásnál teljes biztonsági másolatot hoz létre, és a meglévő pontokat elfelejti. Annak érdekében, hogy ne maradjon szabad hely nélkül, a DWORD ForceDeleteBackupFiles alkalmazást kell használnia.
Következtetés
Tehát egy ilyen hosszú szöveg eredményeként kétféle feladatot vettünk figyelembe. Természetesen sokkal több feladat van, de nem lehet mindegyiket egy cikk formátumában megvizsgálni. Ha elolvasása után még mindig van kérdése, írja meg a megjegyzésekben, szívesen válaszolok személyesen.
Forrás: will.com