Mentés három lábon egy kis cégnek: mit véd, mit nem — és honnan tudja, hogy tényleg megvan

Ez a cikk arról szól, hogyan néz ki egy kis cég mentése három lábon, ha nem csak papíron akarjuk, hogy meglegyen. Mi kerül a külső lemezre, hogyan lesz a „lefutott” állításból mérés, miért kap a mentés saját bukás-értesítőt a felügyeleti rendszer mellett, és mit nem véd egy helyben álló külső lemez. A számok egy valódi, általunk üzemeltetett munkaállomás mentéséből valók, nem katalógusból.

Miért három lábon áll egy használható mentés?

A mentésnél a leggyakoribb hiba nem az, hogy nincs. Az, hogy van, csak senki nem tudja, mikor futott le utoljára sikeresen, és mit lehetne belőle visszaállítani. A „van mentésünk” egy állítás. A „tegnap éjjel kiment a külső lemezre a teljes anyag, és ha nem sikerül, arról levelet kaptunk volna” egy mérés. A kettő között van az a néhány hét, ami alatt egy kis cég észrevétlenül elveszíti a könyvelését.

Az iparági alapszabály egyszerű: legyen az adatból három példány, legalább két különböző adathordozón, és az egyik legyen fizikailag máshol. Mi ezt három lábnak hívjuk, mert így látszik a lényeg: mindegyik láb mást véd, és külön-külön kell működniük. Ha az egyik kiesik, a másik kettő nem pótolja.

A legtöbb kis cégnél a második és a harmadik láb hiányzik, az elsőről pedig senki nem tudja megmondani, mikor futott le utoljára. A következő szakaszok azt írják le, hogyan épül fel ez a gyakorlatban egy helyi munkaállomáson, és hol szokott elbukni.

Az első láb: teljes helyi másolat külön lemezre

Az első láb egy 2 TB-os külső SSD. Nem divatból SSD: a napi mentésnek az éjszakai ablakban le kell futnia, és nagy fájlszámnál a lemez sebessége dönti el, hogy ott végez-e, vagy belelóg a munkaidőbe. Ha belelóg, a kollégák előbb-utóbb kihúzzák a lemezt.

A lemezen két külön kötet van. Az egyikre dolgozik a mentőscript — ide mennek a projektek, az adatbázis-kiírások és a konfiguráció —, a másik a gép beépített, verziózott rendszer-mentése. A szétválasztás szándékos: a két mentés más ütemben, más logikával és más hibákkal fut, és ha egy fájlrendszer-hiba az egyik kötetet elviszi, a másik megmarad. Egy köteten osztozva egy elszabaduló verziózott mentés simán megeszi a napi másolat helyét is.

Egy teljes helyi mentés nagyságrendje egy tipikus munkaállomáson: 137 GB, 1,07 millió fájl. Ez azért érdemel külön mondatot, mert a legtöbb kkv-nál a mentés nem a gép egészére vonatkozik, hanem néhány kijelölt mappára: a fontos mappák mentve vannak, a gép nincs. A különbség egy meghibásodásnál derül ki — a fájlok megvannak, a működő környezet nem.

Amiről érdemes nyitott listát vezetni: a verziózott rendszer-mentésnek legyen méret-korlátja, különben szétterül az egész köteten; a mentendő mappák listája avuljon együtt a géppel; és legyen egy hely, ahol a mentés ismert, még nem javított hiányosságai össze vannak írva. Ez a különbség a rendben lévő és a rendben lévőnek hitt üzemeltetés között: az elsőnek van listája arról, mi nincs rendben.

A mount-őr: csak akkor zöld, ha a lemez tényleg ott van

A legcsendesebb mentési hiba a következő. A mentés célmappája akkor is létezik, ha a külső lemez nincs csatlakoztatva — csak éppen üres, és a belső lemezen van. Ilyenkor a másolás lefut, a script sikeres visszatérési értéket ad, a napló tele van „kész” sorokkal. Az adat viszont a belső lemezre került, arra a lemezre, ami ellen épp védekezni akartunk. Amikor a külső lemezt legközelebb bedugják, a mentés „megvan”, csak a tartalma három hetes.

A védekezés egyetlen fájl. A külső köteten van egy jelzőfájl, és a mentés indulás előtt megkeresi. Ha a fájl nincs ott, a kötet nincs csatlakoztatva: a futás nem indul el, és nem „sikeres”, hanem bukás. Ez néhány sor a script elején, cserébe a mentés státusza innentől a valóságot mondja, nem a mappaszerkezetet.

Az elv általánosítható, és az üzemeltetés egyik alapszabálya nálunk: a rendszer csak arra mondhatja, hogy zöld, amit tényleg megmért. Ugyanebbe a hibaosztályba tartozik az is, amikor egy ütemezett feladat naplója sikert ír ki anélkül, hogy megnézte volna, sikerült-e — rendszerek átvizsgálásakor ez szokott egész riasztási útvonalakat elrejteni. Erről külön cikkben írtunk: Hamis zöld: négy hibaminta.

A gyakorlati tanács egyszerű: minden mentésnél legyen egy feltétel, ami a célt ellenőrzi, nem a parancs lefutását. Külső lemeznél a jelzőfájl; hálózati megosztásnál egy próbaírás és -olvasás; felhős tárolónál a feltöltött fájl méretének visszaolvasása. Egy sor kód, és megszűnik a mentések leggyakoribb hazugsága.

A csapda, amit csak az ütemezett futás hoz elő

Van egy hibaosztály, amit teszteléssel szinte lehetetlen elkapni: a mentés kézzel indítva hibátlanul lefut, ütemezetten viszont mindig elbukik. A kolléga kipróbálja, működik; a gép éjjel elindítja, és nem működik. Ez a leggonoszabb fajta, mert a kézi próba pont az ellenkezőjét bizonyítja annak, ami valójában történik.

A leggyakoribb ok nem a lemez és nem a script, hanem az engedélyrendszer. A mai operációs rendszerek a cserélhető köteteket külön engedélyhez kötik, és ezt az engedélyt az a környezet kapja meg, amelyikből a felhasználó megadta. Az ütemezőből, a háttérben, felhasználói munkamenet nélkül induló futás nem. A mentés tehát pontosan azt teszi, amit kérnek tőle, csak nem éri el a lemezt — és erről semmilyen látványos hibaüzenet nem érkezik.

A tanulság rövid: ha egy ütemezett feladat a kézi futással ellentétben bukik, először az engedélyeket nézze, és csak utána a kódot. A megoldás pedig legyen szerkezeti, ne egy „majd figyelünk rá” típusú kerülőút — az ütemezett futás vagy megkapja a szükséges engedélyt, vagy egy erre a célra korlátozott, naplózott úton fut le, amelyik rendelkezik vele.

A második tanulság a felügyeletről szól. Egy ilyen bukás napokig el tud tartani zöld státusz mellett, ha a riasztása el van némítva, és a némítás a mérést is kivette az állapotsorból. Ezért hangzik nálunk a szabály így: némítani szabad, a mérést kivenni nem. Az elnyomott, de fennálló hiba visszakerül a napi állapotsorba — csendben, de láthatóan.

Hogy egy riasztás-logika pontosan hogyan tud zöldet mutatni egy halott job fölött, azt a Hamis zöld: négy hibaminta szedtük szét; hogy ebből mi az, amit egy üzemeltetési havidíj megvesz, azt az üzemeltetési havidíj cikkben soroltuk tételesen.

A bukás-értesítő: egy levél, nem napi zaj

A fenti csapda egy szerkezeti hiányosságra is rávilágít. A legtöbb felügyeleti rendszer az ütemezett feladatok kilépési kódját nézi, a mentés naplóját nem — vagyis ha a mentés „szépen” fut le rossz eredménnyel, nincs, ami szóljon. Ezért kap nálunk minden mentés saját, a felügyelettől független értesítőt: a kilépési kód figyelése önmagában nem fogja meg a rosszul lefutott mentést.

Az értesítő él-vezérelt: állapotváltáskor szólal meg, nem állapotot közöl. Ez a különbség dönti el, hogy két hét múlva olvassa-e még valaki.

Az élesítés előtt öt forgatókönyvön mentünk végig, mielőtt a levelező-sablon egyáltalán élesbe került. Egy értesítő, ami rossz pillanatban szólal meg — vagy pont a fontos pillanatban hallgat —, rosszabb a semminél: hamis biztonságot ad, és megtanítja az embert figyelmen kívül hagyni a saját rendszerét.

Ez a minta bármilyen ütemezett feladatra átvihető, nem csak mentésre. Két szabály elég hozzá: szóljon állapotváltáskor, és a riasztásban legyen benne az is, mit tegyen az, aki elolvassa. Egy riasztás, amiben nincs cselekvés, csak rossz érzés.

Mit nem véd ez a mentés — és mikor kell a harmadik láb

Legyünk pontosak abban, mit vettünk meg egy teljes helyi mentéssel. Véd a lemezhiba, a véletlen törlés, az elrontott frissítés és az ellopott munkaállomás ellen. Nem véd a tűz, a beázás, a betörés és a túlfeszültség ellen, mert a külső lemez kkv-knál jellemzően ugyanabban a szobában áll, mint a gép. És nem véd a zsarolóvírus ellen sem, amely a csatlakoztatott kötetet ugyanúgy titkosítja, mint a belsőt.

Ezért van harmadik láb: napi, titkosított másolat egy távoli szerverre. Ide nem kell mindent kivinni. A távoli lábra az kerüljön, ami pótolhatatlan: a titkos konfigurációs fájlok és kulcsok, az adatbázis-kiírások, a belső tudásbázis és az állapotfájlok. A filmek, a telepítők és a gyorsítótárak nem — azok bármikor újra letölthetők, és csak drágítják a tárolást.

A titkosítás itt kötelező elem. A távoli tároló definíció szerint valaki más gépe, és az adatnak ott is olvashatatlannak kell lennie. A kulcsot pedig nem ugyanoda tesszük, ahova a mentést — ez a leggyakoribb hiba a titkosított mentéseknél.

Három jel közül bármelyik elég ahhoz, hogy a harmadik láb ne legyen halasztható:

• Az adat elvesztése megállítja az üzletmenetet. Ha holnap reggel nincs meg az ügyfélnyilvántartás vagy a könyvelés, hány napig tudnak dolgozni?
• Jogszabály vagy szerződés írja elő a megőrzést. Számlák, munkaügyi iratok, ügyféladat — ezeknél az „elveszett a lemez” nem védekezés.
• Minden egy telephelyen van. Egy szoba, egy áramkör, egy zár. Ez a leggyakoribb eset kkv-nál, és a legolcsóbban orvosolható.

És van egy negyedik dolog, ami nélkül mind a három láb csak remény: a visszaállítás próbája. A mentés megléte és a visszaállítás sikere két különböző állítás. Az elsőt a napló mondja meg, a másodikat csak egy tényleges próba: kiválasztunk egy mappát vagy egy adatbázist, visszatöltjük egy külön helyre, és megnézzük, használható-e. Évente egyszer, felírt dátummal. Aki ezt nem csinálja meg, annak nincs mentése, csak mentési szándéka.

Gyakori kérdések

Mi az a 3-2-1 mentési szabály?

Legyen az adatból három példány, legalább két különböző adathordozón, és az egyik legyen fizikailag máshol. Mi ezt három lábnak hívjuk: teljes helyi másolat külső lemezre, verziózott rendszer-mentés egy másik köteten, és egy távoli, titkosított másolat. Mindegyik más kockázat ellen véd, ezért nem helyettesítik egymást.

Elég egy külső merevlemez mentésnek egy kis cégnél?

Kezdetnek sokat ér, de egyedül kevés. A gép mellett álló lemez nem véd a tűz, a beázás, a betörés és a zsarolóvírus ellen, mert azt a csatlakoztatott kötetet is eléri. Ha az adat elvesztése megállítaná a működést, kell mellé egy távoli, titkosított másolat is.

Honnan tudom, hogy tényleg lefutott a mentés?

Onnan, hogy a mentés a célt ellenőrzi, nem csak a parancs lefutását. A külső köteten legyen egy jelzőfájl, amit a mentés indulás előtt megkeres: ha nincs ott, a futás bukás, nem siker. A naplóban pedig legyen egy dátumozott, ellenőrizhető sor arról, mennyi adat került ki.

Miért nem elég a napi „minden rendben” levél?

Mert két hét alatt láthatatlan lesz, és magával viszi a valódi riasztást is. A mi értesítőnk állapotváltáskor szól: bukásnál egy levél a napló utolsó 25 sorával és az újrapróbálás parancsával, helyreálláskor egy „ismét megy”, ismétlődő bukásnál néma marad.

Véd a mentés a zsarolóvírus ellen?

Csak az a láb véd, amelyik nincs folyamatosan csatlakoztatva vagy írható a fertőzött gépről. A folyamatosan bedugott külső lemezt a zsarolóvírus ugyanúgy titkosítja, mint a belsőt. Ezért kell távoli, titkosított másolat, amelynek a kulcsa nem ugyanott van, ahol a mentés.

Mikor derül ki, hogy a mentés valójában nem működik?

Jellemzően a visszaállításnál, vagyis a legrosszabb pillanatban. A leggyakoribb eset az, hogy az ütemezett futás nem kap engedélyt a cserélhető kötethez, miközben kézzel indítva hibátlanul fut — és a státusz közben zöld marad. Ezért javasoljuk az évenkénti visszaállítási próbát és a mentés saját, független bukás-értesítőjét.

A következő lépés: a húszperces mentés-ellenőrzés

Ha egyetlen dolgot visz el ebből a cikkből, ez legyen: nyissa meg a mentés utolsó naplóját, és nézze meg a dátumot. Ha nincs napló, vagy nem tudja, hol van, az önmagában a válasz. Az alábbi hét kérdés húsz perc alatt végigmegy, és mindegyikre vagy van egy ellenőrizhető válasz, vagy van egy teendő.

Nálunk ez a hét kérdés a folyamat-audit üzemeltetési szakaszának része: végigmegyünk azon, mi fut, mi jelez, ki nézi, és mi az, ami csak papíron van meg. Az audit menetét és árát az AI-audit árak oldalon írtuk le, az automatizálás teljes ívét pedig az AI-automatizálás útmutatóban.

Egy dolgot érdemes tisztázni a hatókörről. A mentés kiépítése önmagában nem termék — a fenti receptet a saját rendszergazdája is végigviszi. A mentés felügyelete viszont az üzemeltetési havidíj része: a mount-őr, a bukás-értesítő és a napi állapotsorban látszó mentés-sor mind ide tartozik, és ha a rendszerét nem mi építettük, ez a réteg utólag is ráépíthető — a tételes listát az üzemeltetési havidíj cikkben írtuk le. Ha eddig eljutott, már többet tud a mentéséről, mint a kkv-k többsége.