A biztonsági mentés nem tartozik a divatos technológiák közé, amelyekről minden vasról kiabálnak. Csak minden komoly társaságban kell lennie, ez minden. Bankunkban több ezer szerverről készítünk biztonsági mentést - ez egy összetett, érdekes munka, amelynek néhány finomsága, valamint a biztonsági mentésekkel kapcsolatos tipikus tévhitek csak elárulják.
Közel 20 éve dolgozom ezen a témán, ebből az utolsó 2 év a Promsvyazbanknál volt. A gyakorlat legelején szinte manuálisan készítettem biztonsági mentéseket olyan szkriptekkel, amelyek egyszerűen másolták a fájlokat. Aztán megjelentek a kényelmes eszközök a Windowsban: a Robocopy segédprogram a fájlok előkészítéséhez és az NT Backup a másoláshoz. És csak ezután jött el a speciális szoftverek ideje, elsősorban a Veritas Backup Exec, amelynek neve most Symantec Backup Exec. Szóval régóta ismerem a biztonsági mentéseket.
Egyszerűen fogalmazva, a biztonsági mentés az adatok (virtuális gépek, alkalmazások, adatbázisok és fájlok) másolatának megőrzését jelenti, bizonyos rendszerességgel. Minden eset általában hardveres vagy logikai hibaként nyilvánul meg, és adatvesztést eredményez. A biztonsági mentési rendszer célja az információvesztés csökkentése. Hardverhiba például annak a szervernek vagy tárolónak a hibája, ahol az adatbázis található. Logikai - ez az adatok egy részének elvesztése vagy megváltozása, beleértve az emberi tényezőt is: véletlenül töröltek egy táblát, fájlt, elindítottak egy görbe szkriptet végrehajtásra. Szabályozói követelmények is vannak bizonyos típusú információk hosszú ideig, például akár több évig történő tárolására vonatkozóan.
A biztonsági mentések legjellemzőbb felhasználási módja az adatbázisok mentett másolatának visszaállítása különféle tesztrendszerek, fejlesztők klónjainak telepítéséhez.
Van néhány tipikus mítosz a biztonsági mentéssel kapcsolatban, amelyeket már régen el kellene oszlatni. Itt vannak a leghíresebbek közülük.
1. mítosz. A biztonsági mentés régóta csak egy kis funkció a biztonsági vagy tárolórendszereken belül
A biztonsági mentési rendszerek továbbra is a megoldások külön osztálya maradnak, és nagyon függetlenek. Túl sok dolguk van. Valójában ők jelentik az utolsó védelmi vonalat az adatok integritását illetően. Tehát a biztonsági mentés a maga ütemében, saját ütemezése szerint működik. Napi jelentés készül a szerverekről, vannak események, amelyek triggerként működnek a felügyeleti rendszer számára.
Ráadásul a biztonsági mentési rendszerhez való hozzáférés példaképe lehetővé teszi, hogy a biztonsági mentések kezeléséhez a jogosultság egy részét a célrendszerek adminisztrátoraira ruházza át.
2. tévhit. Ha van RAID, már nincs szükség biztonsági másolatra.
A RAID-tömbök és az adatreplikáció kétségtelenül jó módja annak, hogy megvédjük az információs rendszereket a hardverhibáktól, és ha van készenléti szerverünk, akkor gyorsan megszervezhetjük az átállást arra az esetre, ha a főgép meghibásodik.
A rendszer felhasználói által elkövetett logikai hibákból a redundancia és a replikáció nem ment meg. Itt van egy visszaírási készenléti kiszolgáló – igen, ez segíthet, ha hibát észlel a szinkronizálás előtt. És ha kimarad a pillanat? Itt csak az időben történő biztonsági mentés segít. Ha tudja, hogy tegnap megváltoztak az adatok, akkor visszaállíthatja a rendszert a tegnapelőttire, és kinyerheti belőle a szükséges adatokat. Tekintettel arra, hogy a logikai hibák a leggyakoribbak, a jó öreg biztonsági mentés bevált és szükséges eszköz marad.
3. mítosz. A biztonsági mentés havonta egyszer készül.
A biztonsági mentés gyakorisága egy konfigurálható beállítás, amely elsősorban a biztonsági mentési rendszer követelményeitől függ. Nagyon is lehetséges olyan adatokat találni, amelyek szinte soha nem változnak és nem különösebben fontosak, elvesztésük nem lesz kritikus a vállalat számára.
Valójában havonta egyszer, de még ritkábban készíthetők biztonsági másolatok. A kritikusabb adatok azonban gyakrabban kerülnek mentésre, az RPO (Recovery point Objrective) jelzőtől függően, amely beállítja a megengedett adatvesztést. Ez lehet hetente egyszer, naponta egyszer vagy akár óránként többször is. Megvannak ezek a tranzakciós naplók a DBMS-ből.
A rendszerek kereskedelmi üzembe helyezésekor jóvá kell hagyni a biztonsági mentési dokumentációt, amely tükrözi a főbb pontokat, a frissítési eljárást, a rendszer visszaállítási eljárását, a biztonsági mentések tárolásának menetét és hasonlókat.
4. tévhit. A másolatok mennyisége folyamatosan növekszik, és teljesen elfoglal minden kijelölt helyet.
A biztonsági másolatok megőrzési ideje korlátozott. Nincs értelme például mind a 365 napi biztonsági mentést tárolni az év során. Általános szabály, hogy a napi másolatokat 2 hétig meg lehet őrizni, majd frissekre cserélik, és a hónapban először készült változat hosszú távú tárolásban marad. Azt viszont egy bizonyos ideig tárolják - minden példánynak élettartama van.
Van adatvesztés elleni védelem. A szabály érvényes: a biztonsági mentés törlése előtt létre kell hozni a következőt. Ezért az adatok nem törlődnek, ha a biztonsági mentés nem fejeződött be, például a szerver elérhetetlensége miatt. Nemcsak az időkereteket tartják tiszteletben, hanem a készletben lévő példányszámot is szabályozzák. Ha a rendszert úgy tervezték meg, hogy két teljes biztonsági másolat legyen, abból mindig kettő lesz, és a régi csak akkor törlődik, ha sikeresen új harmadikat írnak. Tehát a biztonsági mentési archívum által elfoglalt mennyiség növekedése csak a védett adatok mennyiségének növekedésével jár, és nem függ az időtől.
5. mítosz. A biztonsági mentés elkezdődött - minden lefagyott
Jobb, ha ezt mondjuk: ha minden lóg, akkor onnan nem nő ki az adminisztrátor keze. Általánosságban elmondható, hogy a biztonsági mentés teljesítménye számos tényezőtől függ. Például magának a biztonsági mentési rendszernek a sebességéről: milyen gyorsak a lemeztárolók, szalagos könyvtárak. A biztonsági mentési rendszer szervereinek sebességéből: van-e idejük adatfeldolgozásra, tömörítés és duplikáció végrehajtására. Illetve a kliens és a szerver közötti kommunikációs vonalak sebességére is.
A biztonsági mentés egy vagy több adatfolyamra mehet, attól függően, hogy a biztonsági mentés alatt álló rendszer támogatja-e a többszálú feldolgozást. Például az Oracle DBMS lehetővé teszi több szál megadását az elérhető processzorok számának megfelelően, amíg az átviteli sebesség el nem éri a hálózati sávszélesség korlátját.
Ha nagyszámú szálat próbál meg biztonsági másolatot készíteni, akkor fennáll az esélye, hogy túlterheljen egy futó rendszert, valóban lassulni kezd. Ezért az optimális szálszámot kell kiválasztani a megfelelő teljesítmény biztosítása érdekében. Ha a teljesítmény legkisebb csökkenése is kritikus, akkor van egy kiváló lehetőség, amikor a biztonsági mentést nem egy harci szerverről, hanem annak klónjáról hajtják végre - az adatbázis terminológiájában készenléti állapotban. Ez a folyamat nem indítja el a fő működő rendszert. Az adatok több adatfolyamon keresztül is lekérhetők, mivel a szervert nem használják karbantartásra.
Nagy szervezetekben külön hálózatot hoznak létre a mentési rendszer számára, hogy a mentés ne befolyásolja a termelést. Ezenkívül előfordulhat, hogy a forgalom nem a hálózaton, hanem a SAN-on keresztül továbbítható.
Igyekszünk a terhelést idővel is elosztani. A biztonsági mentések többnyire munkaidőn kívül készülnek: éjszaka, hétvégén. Ráadásul nem mind fut egyszerre. A virtuális gépek biztonsági mentése speciális eset. A folyamat gyakorlatilag nincs hatással magának a gépnek a teljesítményére, így a biztonsági mentés napközben elosztható, és nem halaszthat el mindent éjszaka. Sok finomság van, ha mindent figyelembe vesz, a biztonsági mentés nem befolyásolja a rendszerek teljesítményét.
6. mítosz. Elindult egy tartalék rendszer – ez a hibatűrés az Ön számára
Soha ne felejtsük el, hogy a tartalékrendszer az utolsó védelmi vonal, ami azt jelenti, hogy előtte még öt olyan rendszernek kell lennie, amelyek biztosítják az IT infrastruktúra és a vállalati információs rendszerek folytonosságát, magas rendelkezésre állását és katasztrófa-tűrő képességét.
Abban a reményben, hogy a biztonsági mentés visszaállítja az összes adatot, és gyorsan megemeli az elesett szolgáltatást, nem éri meg. Az adatvesztés a mentés pillanatától a meghibásodásig garantált, és az adatok több órán keresztül (szerencsés esetben napokig) feltölthetők egy új szerverre. Ezért van értelme teljes értékű hibatűrő rendszereket létrehozni anélkül, hogy mindent áthelyeznénk egy tartalékra.
7. tévhit. Egyszer létrehoztam egy biztonsági mentést, ellenőriztem, hogy működik-e. Már csak a naplókat kell megnézni
Ez az egyik legkárosabb mítosz, amelynek hamisságára csak az incidens során jön rá az ember. A sikeres biztonsági mentési naplók nem garantálják, hogy minden valóban úgy ment, ahogy kellett. Fontos, hogy előzetesen ellenőrizze a mentett másolat telepíthetőségét. Vagyis indítsa el a helyreállítási folyamatot egy tesztkörnyezetben, és nézze meg az eredményt.
És egy kicsit a rendszergazda munkájáról
Kézi üzemmódban már régóta senki nem másol adatokat. A modern SRK-k szinte mindenről képesek biztonsági másolatot készíteni, csak megfelelően kell beállítani. Ha új kiszolgálót adtunk hozzá, állítson be házirendeket: válassza ki a biztonsági másolatot készítő tartalmat, adja meg a tárolási beállításokat, és alkalmazza az ütemezést.
Ugyanakkor még mindig sok a munka a kiterjedt szerverpark miatt, beleértve az adatbázisokat, levelezőrendszereket, virtuálisgép-fürtöket és fájlmegosztásokat Windowson és Linuxon/Unixon egyaránt. Azok az alkalmazottak, akik működtetik a biztonsági mentési rendszert, nem ülnek tétlenül.
Az ünnep tiszteletére minden adminnak erős idegzetet, tiszta mozgást és végtelen helyet kívánok a mentések tárolására!
Forrás: will.com