Szinte minden biztonsági mentési rendszert (BMS) bevezetett ügyfelünk úgy gondolja, hogy ez minden problémáját megoldja. Minden tőlük telhetőt megtettek annak érdekében, hogy mindenről biztonsági másolatot készítsenek, és baleset esetén megfelelően helyreállítsák. De gyakran előfordul így: a cég komoly problémával néz szembe, és a hagyományos mentési rendszer nem engedi, hogy a cég által célnak tartott időn belül helyreálljon. Valójában az SLA, amelynek a tartalék rendszernek meg kell felelnie, nem teljesül. Sajnos munkánk során sok szomorú példa gyűlt össze, amelyek ezt megerősítik. Az alábbiakban két esetet mutatunk be, és tanácsot adunk arra vonatkozóan, hogy milyen technikai eszközökkel csökkenthető a gyógyulási idő. Az esetek kiválasztásánál az adatbázisokhoz kapcsolódó példákra koncentráltunk, ahol a legtöbb üzleti szempontból kritikus információt tárolták.
Az összeomlás okának rövid leírása: személyzeti hiba, helytelen javítás telepítése az Oracle-en.
Egy nagyvállalatról beszélünk, amelynek kiforrott informatikai részlege van, és eleget fektet a berendezéseibe és a személyzetébe. Elég, ha azt mondjuk, hogy az Oracle DBMS két Oracle Exadatán futott, két technológiai oldalon elosztva, jól kidolgozott DR-megoldással és testreszabott biztonsági mentési rendszerrel.
Egy szomorú napon úgy döntöttek, hogy telepítenek egy javítást az Oracle DBMS-re. Sajnos a mérnök nem olvasta el az utasításokat a végéig: "Mi, nem telepítem a javítást papír nélkül?!" - és rosszul tette. A hibát néhány órával később vették észre, amikor a DBMS furcsán kezdett viselkedni, és jelenteni kezdte a naplókban. Aztán a mérnök úgy döntött, hogy visszagurul. Ez a művelet végül az adatbázis mindkét példányát rögzíti (minden változtatást sikerült készenléti állapotba replikálni), és megsértette az összes adatot.
A vállalat fő információs eszköze nélkül maradt - egy adatbázis, amelyen keresztül minden üzleti folyamat működött. Az üzlet gyakorlatilag leállt.
Az ügyfél úgy döntött, hogy visszaállítja a biztonsági másolatból. Akkoriban egy 5 TB-os adatbázis (most ~ 15 TB) visszaállítása vett igénybe - figyelem! - több mint 30 óra!Összességében 1,5 nap elteltével az alapot helyreállították egy nappal a baleset előtt. De több adat is volt! Minden mást a programozók és a munkatársak más céges rendszerekről állítottak vissza, az elsődleges dokumentációból (jelentkezési lapok, másolatok, szkennelések). Újabb 1,5 nap kemény munkába került.
2 High-end Oracle Exadata rendszer, Oracle Standby, működő biztonsági mentési rendszer és 3!!! napokig tartó teljes leállás a javítás helytelen telepítése miatt. Megengedte a cég szabályzata? Természetesen nem.
Fő probléma: pénzhiány gyors helyreállítás logikai hibákkal.
Az ilyen balesetek következményeinek enyhítése érdekében két irányba kell haladnia. Egyrészt azért, hogy gyakrabban készítsünk biztonsági mentéseket, másrészt, hogy gyorsan helyre tudjunk állni. A következő termékek segíthetnek:
Oracle FlashBack- olyan technológia, amely lehetővé teszi, hogy ne csak az új adatokat "göngyölje fel". tartalék rendszer Oracle, hanem vissza is a kívánt tranzakcióhoz. Egy ilyen sémával lehetséges lenne a rendszer visszaállítása a javítással kapcsolatos problémák kezdete előtt, ami nagyban megkönnyítené az adatok helyreállítását.
Pillanatfelvétel technológia. A pillanatképek lehetővé teszik az adatok biztonsági mentését és visszaállítását másodpercek alatt. Ugyanakkor csekély hatásuk van a teljesítményre, és elég gyakran (például óránként egyszer) lehet pillanatfelvételeket készíteni. Így egy órával vissza lehetett görgetni, és csak egy órát lehetett visszaállítani az elveszett adatokat.
Folyamatos adatvédelem- folyamatos adatvédelem. Ezek olyan szabadalmaztatott eszközök vagy szoftverek, amelyek lehetővé teszik az összes rekord naplózását, és bármikor visszagörgethetők. Az Oracle FlashBackhez hasonlóan működik, de bármilyen adat esetén.
Vevő: szövetségi szolgálat az Orosz Föderáció egyik alanyában
A baleset okának rövid leírása: hardverhiba belül lemeztömb.
A cég ezúttal valamivel fejletlenebb informatikai infrastruktúrával rendelkezik, de ügyfeleinknél inkább elterjedt: középszintű lemeztömbök, Oracle DBMS, Standby nem használatos.
Ahogy az lenni szokott, pénteken, amikor mindenki boldogan ment haza, a tömb hardver meghibásodott. A firmware hibája miatt, amikor egy lemez meghibásodott, a tömb összezavarta az adatokat. Ettől a szövetségi szintű szolgáltatás adatbázisai leálltak. Az ügyfél több mint egy napig várta a megoldást a tároló gyártójától. Az összes napló elemzése után az eladó levonta a következtetést: az adatok elvesztek!
Az ügyfél úgy döntött, hogy visszaállítja a biztonsági másolatból. Ez a folyamat körülbelül egy napig tartott, minden trükk és teljesítményhangolás ellenére (az alap elég nagy). Az adatbázis visszaállítása közben a naplók biztonsági másolata elveszett (a megőrzési időszak túl rövidre volt állítva, az SRK maga törölte őket).
Tovább - mélyebbre. A cég – sok máshoz hasonlóan – bizonyos pontokon naplózatlan műveleteket alkalmazott az Oracle-ben, ami nagymértékben javítja a teljesítményt, de nem hagy esélyt a helyreállításra, kivéve a biztonsági mentésből. Ez azt jelenti, hogy közvetlenül a műtét után kell elvégezni. Természetesen az évek során az üzemeltetési szolgálat megfeledkezett erről. Így az adatok egy része teljesen elveszett.
Még néhány napba telt az infrastruktúra szolgáltatások teljes helyreállítása - nem voltak biztonsági másolatok az operációs rendszerekről, binárisokról, konfigurációkról stb.
Az összes elveszett információt elsődleges dokumentumokból (harmadik fél adatbázisaiból, papíralapú dokumentumokból, a pénztárosok számítógépén lévő adatokból) gyűjtötték össze, ami további 3 napot vett igénybe. Előfordulhat, hogy egyes dokumentumokat soha nem sikerült visszaállítani.
Egy tömbprobléma adatvesztést és leállást okozott körülbelül egy hétig! Modern körülmények között ez a cég csődjéhez vezethet.
Következtetés. A fenti példákból látható, hogy a biztonsági mentési rendszerek telepítése és konfigurálása megtörtént, de ennek ellenére nem tudtak helyreállni az SLA-ban meghatározott időkereten belül.
Tapasztalataink alapján úgy döntöttünk, hogy kiemelünk néhány olyan problémát, amelyekre véleményünk szerint az olvasóknak kiemelt figyelmet kell fordítaniuk.
Jelenleg a mentési sebesség egyenesen arányos az adatmennyiséggel, miközben minden ügyfelünk éves adatnövekedése legalább 30%. 3-4 év alatt az adatok legalább megduplázódnak, de egyes cégeknél ez a szám még ennél is magasabb, ugyanakkor a mentési sebesség egyáltalán nem változik. Ebből egy egyszerű következtetést vonhatunk le, hogy azokat a kifejezéseket és SLA-kat, amelyek 3-4 évvel ezelőtt relevánsak voltak, most legalább meg kell duplázni. Ugyanakkor az adat-helyreállítás (RPO / RTO) üzleti igényei folyamatosan nőnek.
Fokozatosan a vállalat minden üzleti folyamata átkerül az informatikába, és a papíralapú elsődleges dokumentumok (dokumentumok másolatai és eredeti példányai, alkalmazások, szkennelések stb.) kihalnak. Minden az informatikai rendszereken belül forog, és az adatvesztés valójában mindennek az elvesztését jelenti. Az IT-nek többé nincs joga hibázni. Az általunk idézett esetekben az adatok különböző körülmények miatt folyamatosan nem álltak rendelkezésre, a cégek nem tudtak működni. Ez mind közvetlen veszteségekhez vezetett, amikor lehetetlen volt végrehajtani a szervezet fő üzleti folyamatát, mind pedig implicit, például reputációs veszteségeket, amelyeket nem olyan könnyű pénzben mérni, de amelyek a jövőben okozhatnak. nem kevesebb kár érte a céget.
A képen A helyreállítási idővel (RTO) kapcsolatos észrevételeimet tükröztem. Az adatok növekedésével a tényleges helyreállítási idő minden bizonnyal növekszik, miközben az SLA-követelmények csak szigorúbbá válnak. A grafikon azon pontja, ahol a tényleges idő megegyezik a szükséges idővel, a legtöbb ügyfél számára már eltelt.
A helyreállítási idő függése az adatmennyiségtől
Valójában a legtöbb hiba az adatok egy részének elvesztéséből adódik. Ugyanakkor a hagyományos biztonsági mentési eszközök lehetővé teszik az adatok közvetlenül a biztonsági mentésből történő visszaállítását, de gyakrabban kell visszaállítani a teljes rendszert. Ha az adatbázis 15 TB-os, akkor több napot is el kell töltenie vele. Nem ismerünk olyan ügyfeleket, akiknek RTO (Recovery Time Objective) követelménye 2 nap. Gyakorlatunkban nem volt példa arra, hogy az ügyfél azt mondaná: "Srácok, normális, hogy 2 napig gyógyulok, leszek türelmes", ha az adminisztrátor véletlenül több sort törölt az adatbázisból. Meglehetősen gyakori probléma, amellyel ügyfeleink szembesülnek, hogy hogyan különítsünk el egy kis adatot a biztonsági másolatból anélkül, hogy visszaállítanánk azt (és nem kell rá több napot töltenünk).
Egy olyan világban, ahol a papíralapú iratok eltűntek, és mindent az informatikai rendszerekben tárolnak, minden másodpercben keletkeznek olyan adatok, amelyeket azonnal meg akarunk védeni – ugyanabban a pillanatban, amikor létrejöttek. De a klasszikus biztonsági mentési rendszerek segítségével ezt nem lehet megtenni. Minden egyes adat esetében van egy bizonyos hosszú időszak, amely alatt ezek az adatok egyetlen példányban léteznek az egész világon. Ügyfeleink folyamatosan szeretnék védeni az adatokat, azok megjelenésétől kezdve. Ha úgy dönt, hogy visszaállít egy biztonsági másolatból, akkor nagy valószínűséggel egy nappal ezelőtt kell visszaállítania, akkor az aznapi adatokat máshonnan kell beszerezni. Általános szabály, hogy ezt hosszú munka rendszergazdák, néhány napig tart. A legnegatívabb forgatókönyv esetén ez veszteségbe torkollhat lényeges információkat. Természetesen a kérdés nem korlátozódik a mentésre, egy informatikai rendszer egészére vonatkozik, de az RMS témája ebben az esetben nagyon fontos, nem elhanyagolható.
Sajnos még mindig nincs olcsó és gyors lehetőség a biztonsági mentés ellenőrzésére. Természetesen ez megtehető időszakos teszt-visszaállítással, de ez emberi és informatikai erőforrások szempontjából igen költséges művelet. Ez egy külön csapat munkája, külön hardveren.
Sajnos ügyfeleink többsége nem. Gyakran előfordul, hogy mindenki készít biztonsági másolatot, de a visszaállítás idejére kiderül, hogy nem tudták megtenni - egyszerűen nem állnak helyre, az RMS külsőleg megfelelő működése ellenére. Ez különböző okokból következik be. És ezt egy példával lehet a legjobban demonstrálni. Egyik ügyfelünk SAP rendszert használt adatbázissal Oracle adatok. biztonsági mentés beépített SAP eszközökkel valósult meg az SRK egyik legnagyobb szállítója segítségével.
2 különböző biztonsági mentési házirendet állítottunk be: az egyik fájl alapú - az operációs rendszer adatait és a szoftver beállításait másolta, a másik pedig magát az adatbázist. Mivel ugyanabba a rendszerbe irányították őket, egy kizárási lista került felállításra, amelybe az adatbázist beírták. A fájlszabályzat figyelembe vette ezt a listát, és nem foglalta le azokat a könyvtárakat, amelyekben az adatbázis található. Az RMS architektúra sajátosságai miatt az adatbázis-foglalási szabályzat figyelmen kívül hagyta a kivételek listáját, és helyesen másolta a szükséges adatokat.
Az egyik szoftverkiadásban ez a gyártó kijavította ezt a „hibát”, attól a naptól kezdve mindkét irányelv figyelembe vette a kivételek listáját és megkerülte az adatbázist. Ráadásul ez semmilyen módon nem befolyásolta az RMS szoftver hibáit, mivel az normálisan működött: minden, a listában nem szereplő adatról rendesen ment a biztonsági mentés. A rendszer beszámolt működőképességéről.
Így minden több mint hat hónapig működött. Amíg meg kell gyógyulnod...
Fontos probléma a biztonsági mentés problémájának nem szisztematikus megközelítése. Az RMS-t történelmileg vagy maga a vállalat, vagy egy érintett integrátor építette fel. Az építkezéskor minden követelménynek minden bizonnyal megfelelt, funkcióját maradéktalanul ellátta. Az idő múlásával a vállalat informatikai környezete megváltozott. Ugyanakkor a tartalék rendszer a rendszer fejlődésével egyszerűen alkalmazkodott hozzá, és leggyakrabban nem figyelhető meg olyan szisztematikus megközelítés, amely figyelembe vette volna annak fontosságát, hogy a rendszer minden további szakaszban összhangban legyen a kezdeti mutatókkal. Amikor RMS-t épít ki szervezetében, ne feledje, hogy ez csak az adatvédelmi stratégiája része.
Számos esettanulmányt bemutattunk, amelyek azt mutatják, hogy az adatvédelem megközelítésének átfogónak kell lennie. Sajnos az SRC csak egy tartalék ejtőernyő, nem egy ezüstgolyó, így amikor elkezdi létrehozni, világosan meg kell értenie, hogy milyen helyet foglal el a globális adatvédelmi stratégiában.
Annak ellenőrzéséhez, hogy mennyire szisztematikusan közelítette meg az RMS felépítésének kérdését, válaszoljon néhány egyszerű kérdésre:
Saját tapasztalataink és ügyfeleink tapasztalatai alapján igyekeztünk olyan megközelítést kialakítani, amely lehetővé teszi ezen problémák megoldását vagy jelentős mérséklését. Megközelítésünk lényege:
Először is le kell választania a biztonsági mentés és a helyreállítás sebességét a rendszer kötetétől. A tárolórendszerek, az alkalmazásszoftverek és az RMS gyártói kínálnak néhány eszközt a probléma megoldására. Az alábbiakban leírom közülük a legígéretesebbeket.
A pillanatképek lehetővé teszik az adatok biztonsági mentését és visszaállítását másodpercek alatt, gyakorlatilag anélkül, hogy befolyásolná a teljesítményt. Ez a tömb segítségével történik, ugyanakkor az SRC vezérelheti, része lehet annak szabályzatának. Az ilyen biztonsági mentés és helyreállítás valóban másodpercekig tart, ami megkülönbözteti ezt a technológiát az elidegeníthető adathordozókkal rendelkező klasszikus rendszerektől.
Egy másik megoldás lehet különféle alkalmazási eszközök használata, mint például az Oracle Standby, DB2 HADR, MS SQL Always On. Mindezek az eszközök lehetővé teszik, hogy egy produktív rendszer működőképes másolata legyen az eredetitől leválasztva, és azonnal üzembe helyezhető. Ez lehetővé teszi, hogy a hibák után azonnal megkezdje a munkát.
A második az, hogy lehetőséget adjon csak a szükséges adatok helyreállítására. Megközelítésünk figyelembe veszi, hogy az adatok egy részének visszaállításakor nem kell a teljes rendszert átmásolnunk, vissza tudjuk állítani azokat az adatokat, amelyekre éppen szükségünk van. Ez az ezeket az adatokat tartalmazó, már telepített rendszerek gyors üzembe helyezésének vagy használatának képességével érhető el. Csakúgy, mint az első esetben, a pillanatképek lehetővé teszik a probléma megoldását (gyorsan megnyithat egy pillanatképet a szomszédos kiszolgálón, és kihúzhatja a szükséges adatot). Ide tartoznak a folyamatos adatvédelmi technológiák is, például az Oracle Standby Flashback funkcióval, a folyamatos adatvédelmi (CDP) megoldások. Lehetővé teszik az adatok munkapéldányának gyors üzembe helyezését a megfelelő időben.
Ha egy logikai blokkot, például egy sort vagy egy adatbázistáblát kell beszereznie, ezek az eszközök nagyban megkönnyítik a feladatot, lehetővé téve a szükséges adat visszaállítását a teljes másolat visszaállítása nélkül.
A harmadik az adatok megjelenése és védelme közötti szakadék csökkentése. Ez az adott eset sajátosságai és az adatok fontossági foka alapján többféle módon is megvalósítható.
Például kevésbé kritikus rendszerek esetén a biztonsági mentés időtartama több órára csökkenthető. Ebben az esetben pillanatfelvételeket használunk. Visszaállítási pontként szolgálhatnak, ami óránként egyszer megtehető. Néhány modern tömb elég jól megbirkózik ezekkel a folyamatokkal, és eleget tud tárolni nagyszámú rendszer pillanatképei. Ez egy nagyszerű kiút abból a helyzetből, amikor vissza kell gurulnod egy kicsit.
A legkritikusabb rendszerek esetében előfordulhat, hogy egyáltalán nincs időintervallum – az adatokat folyamatosan védeni kell. Ennek az osztálynak számos megoldása létezik, például az Oracle Standby FlashBack funkcióval, amely lehetővé teszi az adatbázis visszaállítását egy ideje az összes változás naplózásával. Használhatja az Oracle ZDLRA HSS-t is, amely szinte szinkronban fogadja az adatbázisban vagy a szoftver- és hardverrendszerekben bekövetkezett összes változást. Általános rendeltetésű mint például az EMC RecoverPoint, a Vision Solutions Double-Take szoftver. Minden változást naplóznak, és lehetővé teszik a visszaállítást az időintervallum bármely pontjára.
Amikor a biztonsági mentési és helyreállítási rendszerek innovációjáról van szó, nem hagyhatjuk figyelmen kívül az Oracle Zero Data Loss Recovery Appliance-t (ZDLRA). Az Oracle Engineered Systems családhoz tartozó szoftver- és hardverkomplexum lehetővé teszi az Oracle Database biztonsági mentését és gyors visszaállítását bármely platformról és bármely kiadásról (Enterprise és Standard). A ZDLRA virtuális biztonsági mentési adatbázisokon (Virtual Full Backup) alapul, amelyeket az első teljes biztonsági mentés és az azt követő változásnaplók alapján szereztek be. Ezeknek a virtuális biztonsági mentéseknek köszönhetően sokkal gyorsabban visszaállíthatja az adatbázist bármely időpontban, mint az RMS klasszikus használatával, a „teljes biztonsági mentés hetente egyszer, növekményes egyszer egy nap” séma szerint. Kijelenthetjük, hogy a ZDLRA folytatja az Oracle Exadata által megadott irányt. Az Exadatában a speciális Szoftvernek köszönhetően innovatív, Oracle Database feladatokra optimalizált tárolórendszert valósítottak meg. És a ZDLRA-ban van egy speciális szoftver, amely optimalizálja az Oracle Database biztonsági mentését.
Most csak a működés helyreállításáról beszélünk. Nagyobb katasztrófák vagy több idő visszanyerésének szükségessége esetén a rendszeres biztonsági mentések nélkülözhetetlen eszközök maradnak. De a jelenlegi körülmények között ez csak egy tartalék ejtőernyő, amelyet az utolsó pillanatban nyitottak ki.
A negyedik a látens hibák csökkentése. Csak egy módja van annak, hogy megbizonyosodjon arról, hogy a biztonsági másolat megfelelően működik - megpróbálja visszaállítani. Ez a leghelyesebb és legritkábban használt módszer ügyfeleink által.
De kínálunk egy kiutat ebből a helyzetből. Először is, hogy legyenek könnyen helyreállítható rendszerpéldányok. Ez ismét a pillanatfelvétel és a készenléti rendszerekről szól, amelyek gyorsan telepíthetők és tesztelhetők. Összehasonlíthatatlanul kevesebb időt és erőfeszítést igényel, mint a teljes biztonsági mentés „feltekercselése”. Ez persze nem mindig segít, de egy kicsit több reményt hagy arra, hogy vészhelyzet esetén legalább ezekkel az eszközökkel sikerüljön visszaállítani az adatokat.
Másodszor, egyes SRK-k lehetővé teszik az automatikus tesztelést. BAN BEN pontos időütemterv szerint futtathatjuk a virtuális gépeket izolált környezetben, és előre meghatározott algoritmusok segítségével ellenőrizhetjük, hogy valóban helyreálltak-e az adatok, elérhető-e az alkalmazás, konzisztens-e, és válaszol-e a szükséges kérésekre. Ily módon az adminisztrátorok megkímélhetők a hosszú rutinmunkától.
Ötödször - a biztonsági mentési rendszer átláthatósága. A leírt integrált megközelítés egy komplex rendszer felépítését foglalja magában, különböző gyártók különféle technológiáinak felhasználásával. Az a feladat, hogy ezt a rendszert valóban működőképessé tegyük, további változtatások és méretezés lehetőségét fektessük le benne, nem triviális, és kétféleképpen is megoldható:
Sajnos még nincs olyan univerzális recept, amely megoldaná az adat-helyreállítás problémáját a jelenlegi folyamatos növekedés és rendszerek bonyolultsága mellett. Csak a fenti megoldások és a szisztematikus megközelítés kombinációja teszi lehetővé a vállalatok számára az adatok helyreállítását a vállalkozás által megkövetelt időn belül.
A biztonsági mentési rendszerek biztosítják az üzleti folyamatok folytonosságát és az információk védelmét a természeti és ember okozta katasztrófáktól, a behatolók akcióitól. Ezeket a technológiákat aktívan használják különféle iparágak és méretű szervezetek informatikai infrastruktúrájában.
Adatmentés- az adatok másolatának létrehozása olyan adathordozón, amelynek célja az adatok eredeti helyére való visszaállítása sérülés vagy megsemmisülés esetén. Emellett a biztonsági mentési rendszer az egyik szükséges módszer az üzletmenet folytonosságának biztosításához. A központosított biztonsági mentési rendszer kiépítésével csökkentheti az IT-infrastruktúra teljes birtoklási költségét a biztonsági mentési eszközök optimális használatával és az adminisztrációs költségek csökkentésével (a decentralizált rendszerhez képest).
Egy elavult megközelítés, az úgynevezett "BACKUP"
Az "INFORMÁCIÓKEZELÉS" nevű modern megközelítés
A központosított biztonsági mentési rendszer többszintű architektúrával rendelkezik, amely a következőket tartalmazza:
A rendszeradminisztrátor listát vezet a biztonsági mentést végző ügyfélszámítógépekről, felvevőkről és biztonsági mentési adathordozókról, és ütemezi a biztonsági mentéseket. Mindezek az információk egy speciális adatbázisban találhatók, amelyet a mentéskezelő szerveren tárolnak.
Az ütemezésnek megfelelően vagy a kezelő parancsára a felügyeleti szerver utasítja az ügyfélszámítógépre telepített ügynökprogramot, hogy a kiválasztott házirendnek megfelelően kezdje meg az adatok biztonsági mentését. Az ügynökprogram összegyűjti és továbbítja a biztonsági mentésre szánt adatokat a felügyeleti szerver által megjelölt másolószerverre.
Ez a fajta mentés a hálózaton kívüli másolási módszer (LAN-mentes) továbbfejlesztése, mivel csökkenti a folyamatban részt vevő processzorok, memória, I/O eszközök számát. Ez a folyamat a fájlonkénti archiválással ellentétben a teljes partíciókat menti, de lehetővé teszi az egyes fájlok visszaállítását. Értelemszerűen a kiszolgálón kívüli másolás az adatokat lemezről szalagra és fordítva a szerver közvetlen közreműködése nélkül másolja. Mivel a biztonsági mentéshez további harmadik félre van szükség, amely teljes mértékben felelős a másolási folyamatért, innen származik ennek a megközelítésnek egy másik neve - másolás egy harmadik fél részvételével (Third_-Party Copy, 3PC). Ilyen berendezésként tehát egy adattároló router használható, amely átveszi a szerver által korábban ellátott funkciókat.
A SAN-architektúra egyik előnye, hogy a rendszert alkotó rendszerek nem csatlakoznak az adattároló eszközökhöz. Ez a tulajdonság a szerver részvétele nélküli biztonsági mentési technológia alapja. Ebben az esetben mind az adatszerver, mind a lemeztömbök másolásában részt vevő eszközök közvetlenül hozzáférhetnek a lemeztömbhöz. A fájlhoz kapcsolódó adatblokkok biztonsági mentését megelőzi valamilyen index, illetve a hozzá tartozó blokkok számát tartalmazó lista létrehozása. Ez lehetővé teszi a további vonzást külső eszközök biztonsági mentéshez.
Így a kiszolgálón kívüli replikáció lehetővé teszi az adatok közvetlen mozgatását a SAN-hoz csatolt lemeztömbök és -könyvtárak között. Ugyanakkor az adatok a SAN-on keresztül mozognak, és nem töltik be sem a helyi hálózatot, sem a szervereket. Az ilyen replikáció ideálisnak tekinthető olyan vállalati hálózatok számára, amelyeknek a hét 7 napján, a nap 24 órájában folyamatosan kell működniük. Különösen azok esetében, amelyeknél elfogadhatatlanul kicsivé válik az az időtartam, amely alatt a biztonsági mentések a felhasználók és az alkalmazások munkáját jelentős mértékben befolyásolják.
A modern lemeztömbök rendelkeznek azzal az eszközzel, hogy magán a tömbön belül másolatokat készítsenek az adatokról. Az ezen eszközök által létrehozott adatokat Point-In-Time (PIT) másolatoknak nevezzük, vagyis egy adott időpontban rögzítjük. Kétféle PIT-másolóeszköz létezik: a klónozás és a „pillanatkép” (pillanatkép). A klónozás általában az adatok teljes másolását jelenti. Ugyanezt igényli lemez terület, mint az eredeti adatoknál, és egy ideig. Ilyen másolat használatakor az eredeti adatokat tartalmazó lemezkötetek nem terhelődnek. Más szóval, nincs további terhelés a produktív szerver lemezalrendszerén.
A "pillanatképek" működési mechanizmusa eltérő, és megvalósítható mind szoftverben egy produktív szerveren, mind hardverben egy tömbön belül. Abban a pillanatban, amikor el kell indítani a biztonsági mentést, az ügynökprogram utasítja az alkalmazást, hogy fejezze be az összes tranzakciót és mentse el a gyorsítótárat
Sajtóközpont
Minden adatközpont alapvető kihívása, hogy szolgáltatási szintre vonatkozó megállapodást biztosítson az IT és a vállalkozás között. Az üzleti követelmények teljesítésének kulcsa az adatbiztonság garanciája, ezért minden megfelelően szervezett adatközpont adattárolási alrendszerének szerves infrastrukturális blokkja az adatmentési és helyreállítási rendszer.
A Storage Networking Industry Association (SNIA) a biztonsági mentési műveleteket a következőképpen határozza meg:
Minden adatmentési rendszer három típusra osztható az alkalmazott mentési mód szerint: lehet fájlonkénti, blokk- vagy alkalmazásszintű adatmentés.
A blokk-mentési rendszer (angol kép- vagy blokkszintű biztonsági mentés) közvetlenül a médiával működik, figyelmen kívül hagyva fájlszerkezet, és az összes tartalom teljes megőrzése – az operációs rendszer, a munkaadatok, a beállítások és egyebek. Az ilyen típusú biztonsági mentés előnye a nagy sebesség. Másolási műveletek végrehajtásakor azonban általában szüneteltetni kell az alkalmazásokat, hogy a másolat konzisztens legyen.
Fájl szintű biztonsági mentési műveletek végrehajtásakor (angol fájlszintű vagy fájlalapú biztonsági mentés) a fájlrendszert kell használni. Ebben az esetben viszonylag egyszerű feladat bizonyos fájlok visszaállítása. Általánosságban elmondható, hogy a biztonsági mentési műveletek tovább tartanak, további terhelés éri az operációs rendszert, és a nyitott fájlokhoz való hozzáférés is gondot okoz.
Biztonsági mentések az alkalmazásszintű biztonsági mentésnél is készíthetők. A másolási és visszaállítási műveletek a biztonsági mentési alkalmazásban található speciálisan használhatók szoftver interfész API (Application Programming Interface). A biztonsági másolat fájlok és esetleg más, az alkalmazás által meghatározott objektumok gyűjteménye, amelyek együttesen az alkalmazás állapotát jelzik egy adott időpontban. Nál nél ez a módszer biztonsági mentés, kompatibilitási probléma léphet fel az alkalmazások különböző verziói és a megfelelő interfészt megvalósító biztonsági mentési rendszerek között.
A biztonsági mentési rendszer az adatközpont szolgáltatási alrendszere, és a következő jellemzőkkel rendelkezik:
A biztonsági mentési rendszer felépítésénél a következőket kell tennie:
LAN biztonsági mentés
A Storage Area Networks (SAN) megjelenése előtt dedikált biztonsági mentési hálózatot használtak a maghálózat biztonsági mentési forgalmának csökkentésére, valamint egy többrétegű struktúrát, amely több másolószervert is magában foglalt. Egy másolószerver dedikálása és a hálózaton a legnagyobb mennyiségű információt feldolgozó produktív szerverekhez való „közelebb” elhelyezése lehetővé teszi a biztonsági mentési forgalom lokalizálását a másolószerver és a termelő szerverek között, és csökkenti a megosztott LAN terhelését.
LAN ingyenes biztonsági mentés
A SAN megjelenésével lehetővé vált a biztonsági mentési forgalom nem a LAN-on keresztül történő átvitele, hanem közvetlenül a szerverekről a SAN-hoz kapcsolódó tárolóeszközökre (általában szalagkönyvtárak). Ezt a módszert "LAN-mentes biztonsági mentésnek" nevezik. Ennek a módszernek a használatakor a szerver-kliens más feladatokkal együtt kiszolgálóként másolja a biztonsági mentési adatokat a SAN-on keresztül elérhető tárolóeszközökre. Ezzel egyidejűleg a biztonsági mentési ütemezés végrehajtásának feladata a mentéskezelő szerverhez van rendelve a LAN-on keresztül (TCP / IP protokollon keresztül) vezérlő műveletek kiadásával és a feladatok másolószerverek általi végrehajtásának figyelemmel kísérésével. Így a biztonsági mentési adatforgalom csökkentésének problémája a LAN-ban megoldódott.
De a "LAN-mentes biztonsági mentés" módszer nem oldja meg az "ablak" biztonsági mentés problémáját. Sőt, ez a módszer további terhelést jelent a kliensszervereken, és megterheli őket további funkciókat biztonsági mentési adatmásoló szerverek. Egyes alkalmazások lehetővé teszik az online biztonsági mentést, ez számos tranzakciós alkalmazásban és speciális biztonsági mentési szoftver opciókon, például nyílt fájlmásoló eszközökön keresztül valósul meg. Az ilyen technológiák használata azonban nem csökkenti a produktív szerverek terhelését, amelyek nagy adatmennyiséggel (terabájt vagy több) megnövelhetik az alapvető feladatok megoldásának idejét egy elfogadható küszöb felett.
szerver nélküli biztonsági mentés
Az ideális biztonsági mentési séma az lenne, ha a kliensszerver adatait a SAN-on keresztül egy tárolóeszközre másolnák egy harmadik féltől származó eszköz (amelyet "Data Mover"-nek neveznek) anélkül, hogy az ügyfélkiszolgáló számítási erőforrásait használnák vagy megszakítanák a működését. Hasonló módszer a biztonsági mentés neve „Szerver nélküli biztonsági mentés”. Az "Adatmozgató" szerepkört egy erre a célra kihelyezett szerver is elláthatja, amely ugyanahhoz a lemeztömbhöz kapcsolódik, mint a produktív szerver, vagy egy speciális eszköz - egy útválasztó.
CDP (Continuous Data Protector)
Az SNIA definíciója szerint a folyamatos adatvédelem (CDP) az adatváltozások folyamatos nyomon követésére és az eredeti adatoktól független tárolóban való tárolására szolgáló technika, amely lehetővé teszi a visszaállítást a múlt bármely időpontjában. A CDP-rendszerek blokk-, fájl- vagy alkalmazásszinten implementálhatók, és az objektumok finomszemcsés helyreállítását biztosítják bármely időpontban, akár egyetlen írási műveletig. E meghatározás szerint minden CDP-megoldás a következő tulajdonságokkal rendelkezik:
Ebben a cikkben a kis- és középvállalkozások adatmentési technikáit tekintjük át.
Az ügyfelek által feltett tipikus kérdés az 1C rendszeradatbázis, körülbelül 1 GB méretű, és az MS Access ügyféladatbázisa, körülbelül 300 MB, biztonságának biztosítása. Minden információ fontos, és egy napnál többet elveszíteni nem kívánatos. Az informatikai részleg számára elkülönített költségvetés nem haladja meg a 100 000 rubelt.
Meg kell érteni az ügyfél követelményeit - mennyi információról kell biztonsági másolatot készíteni, mennyi ideig tart a biztonsági másolatok tárolása, szükséges-e a biztonsági mentések távoli tárolása (offline).
Ha az ügyfélnek adatokat kell tárolnia a következő napokban, és a megoldás költsége minimális, akkor a legegyszerűbb és legkényelmesebb megoldás egy kis hálózati tárolás adatok (NAS – Network Attached Storage). Ezeket az eszközöket különböző hardvergyártók gyártják, 2-12 meghajtóval rendelkeznek, és a fő hozzáférési protokollokon keresztül biztosítják a hozzáférést: CIFS, NFS, HTTP, iSCSI. A megoldás blokkvázlata az 1. ábrán látható.
1. ábra NAS tároló.
Ennek a megoldásnak a költsége 15 000 és 70 000 rubel között mozog, a tárhely mennyiségétől függően.
Ennek a megoldásnak a fő hátránya a méretezés lehetetlensége a tárolási mennyiség növekedésével és a biztonsági mentés sikerének ellenőrzése.
A biztonsági mentési eljárások automatizálására egy speciális szoftver, amely vezérli a biztonsági mentések létrehozásának és a visszaállítási eljárásnak a folyamatát, valamint lehetővé teszi a különféle adathordozókkal való munkát, beleértve a szalagos eszközöket is.
A biztonsági mentések létrehozásához biztonsági mentési házirendek jönnek létre, amelyek szabályozzák a „Mit, hol és mikor”. Milyen adatokat, hova és milyen gyakran kell menteni. További jellemzők A központosított biztonsági mentési szoftver lehetővé teszi az egyes levelek és adatbázistáblák visszaállítását anélkül, hogy a teljes adatmennyiséget vissza kellene állítani. A biztonsági mentések szalagra rögzítése lehetővé teszi a biztonsági másolatok távoli tárolásának megszervezését és a fontos adatok biztonságát katasztrófa esetén. A szalagos adathordozók használata az archív másolatok tárolására lehetővé teszi az adatok leolvasását 50 évvel a megírásuk után.
Egy ilyen megoldás költsége 50 000 rubeltől kezdődik, és tartalmaz egy szervert a biztonsági mentések és a biztonsági mentési szoftverek tárolására.
biztonsági mentés csak akkor hatásos, ha rendszeresen végzik. Ha az adatok gyakran változnak, a másolásnak is gyakorinak kell lennie. Ezért sokan inkább speciális szoftvereket használnak ennek a folyamatnak a automatizálására, ahelyett, hogy manuálisan másolnák az adatokat.
Minden számítógép ki van téve a hardver meghibásodásának és sok más veszélynek, amelyek fontos adatok elvesztéséhez vezethetnek. Az üzleti világban ennek különösen súlyos hatása van, hiszen az üzleti adatok elvesztése óriási veszteségekkel és ügyfélveszteséggel jár.
A biztonsági mentési eszközök kulcsa az adatok helyreállítása. Tényleg, mi haszna a biztonsági mentésnek, ha nem tudja visszaállítani? Ezért a biztonsági mentési program kiválasztásakor ügyelni kell arra, hogy a kívánt adatokat könnyen vissza tudja állítani vele.
A Handy Backup egy megbízható biztonsági mentési és visszaállítási szoftver Windows számítógépekhez, amely egyszerű és felhasználóbarát felületéről és számos szolgáltatásáról ismert. Az adatok biztonsági mentéséhez vagy visszaállításához egyszerűen létre kell hoznia egy új „feladatot” (a lépésenkénti Feladat létrehozása varázsló segítségével). A Handy Backup segít a következő adatok biztonsági mentésében:
A Handy Backup visszaállíthatja mind a teljes biztonsági másolatot, mind a egyedi fájlokatés mappákat.
A program képes végrehajtani automatikus keresésés számos népszerű alkalmazás biztonsági mentése, beleértve az Outlook, Skype, Adobe Photoshop satöbbi.
A Handy Backup pontos másolatot készíthet a HDD-ről, beleértve az operációs rendszert, a rendszerindítási rekordokat és egyéb információkat. Teljesen másolhatja és visszaállíthatja HDD, valamint annak egyes szakaszai.
Létrehozhat egy különlegeset indítólemez helyreállítás a Handy Backup Disaster Recovery segédprogrammal, amelyből hiba esetén elindíthatja az operációs rendszert, és visszaállíthatja a rendszert, a beállításokat és az összes adatot.
A program képes dolgozni különböző Windows verziók, beleértve a Windows 8 biztonsági mentését és visszaállítását.
A program képes ODBC kompatibilis adatbázisok másolására, valamint speciális bővítményekkel rendelkezik a DB2, Oracle, MS SQL, MySQL stb. adatbázisok pontos másolásához.
Az alkalmazás képes az MS Exchange Server adatok biztonsági mentésére és visszaállítására a szerver leállítása nélkül. És hozzon létre egy automatikus biztonsági másolatot a levelekről a Yandex.Mail, Mail, Gmail, Yahoo Mail stb. szerverekről.
ALEXEY BEREZHNY, Rendszergazda. Főbb tevékenységek: virtualizáció és heterogén hálózatok. A cikkírás mellett egy másik hobbi az ingyenes szoftverek népszerűsítése.
biztonsági mentés
Elmélet és gyakorlat. Összegzés
A biztonsági mentési rendszer leghatékonyabb megszervezéséhez valódi stratégiát kell felépítenie az információk mentésére és visszaállítására.
A biztonsági mentés (vagy más néven biztonsági mentés - az angol „backup” szóból) fontos folyamat bármely IT-struktúra életében. Ez egy ejtőernyő előre nem látható katasztrófa esetén. Ugyanakkor a biztonsági mentés egyfajta történeti archívum létrehozására szolgál a vállalat üzleti tevékenységeiről az élet egy bizonyos időszakában. Tartalék nélkül dolgozni olyan, mint a szabad levegőn élni – az időjárás bármelyik pillanatban elromolhat, és nincs hová bújni. De hogyan lehet megfelelően megszervezni, hogy ne veszítsen fontos adatokat, és ne költsön rá fantasztikus összegeket?
Általában a biztonsági mentések szervezése témájú cikkek főként technikai megoldásokkal foglalkoznak, és csak alkalmanként fordítanak figyelmet az adattárolás szervezési elméletére és módszereire.
Ebben a cikkben éppen az ellenkezőjére fogunk összpontosítani: a hangsúly azon van általános fogalmak, és a technikai eszközöket csak példaként említjük. Ez lehetővé teszi számunkra, hogy elvonatkoztassunk a hardvertől és a szoftvertől, és megválaszoljunk két fő kérdést: „Miért csináljuk ezt?”, „Megtehetjük ezt gyorsabban, olcsóbban és megbízhatóbban?”.
A biztonsági mentés céljai és célkitűzései
A biztonsági mentés megszervezése során két fő feladat kerül kitűzésre: az infrastruktúra helyreállítása meghibásodások esetén (katasztrófa-helyreállítás), valamint egy adatarchívum karbantartása, hogy az elmúlt időszakok információihoz utólagosan hozzáférhessenek.
A Disaster Recovery biztonsági mentésének klasszikus példája az Acronis True Image által létrehozott kiszolgálórendszer-partíció kép.
Az archívumra példa lehet az adatbázisok havi feltöltése az 1C-ből, kazettákra rögzítve, majd egy speciálisan kijelölt helyen tárolva.
Számos tényező különbözteti meg a gyors-visszaállítási biztonsági másolatot az archívumtól:
Néha lehetséges kombinálni ezeket a feladatokat. Például egy fájlszerver havi teljes "pillanatképeinek" éves készlete, valamint a héten végrehajtott módosítások. A True Image megfelelő eszköz egy ilyen biztonsági mentés készítéséhez.
A legfontosabb dolog az, hogy világosan megértsük, mire szolgál a foglalás. Mondok egy példát: egy kritikus SQL-kiszolgáló meghibásodott egy lemeztömb meghibásodása miatt. Raktáron van a megfelelő Hardver, így a probléma megoldása csak a szoftver és az adatok visszaállítása volt. A cég vezetése érthető kérdést tesz fel: "Mikor fog működni?" - és kellemetlen meglepetést okoz, amikor megtudja, hogy a felépülés akár négy órát is igénybe vesz. A tény az, hogy a szerver teljes élettartama alatt csak az adatbázisokról készült rendszeresen biztonsági mentés, anélkül, hogy figyelembe vették volna a szerver visszaállításának szükségességét az összes beállítással, beleértve magát a DBMS szoftverét is. Egyszerűen fogalmazva, hőseink csak adatbázisokat mentettek el, és megfeledkeztek a rendszerről.
Mondok még egy példát. A fiatal szakember munkája teljes időtartama alatt az ntbackup programmal egyetlen példányt készített egy futó fájlkiszolgálóról Windows Server 2003, beleértve az adatokat és a rendszerállapotot egy másik számítógép megosztott mappájába. A lemezterület hiánya miatt ezt a példányt folyamatosan felülírták. Nem sokkal később megkérték, hogy állítsa vissza egy többoldalas jelentés korábbi verzióját, amely a mentéskor megsérült. Nyilvánvaló, hogy mivel a Shadow Copy kikapcsolt állapotában nincs archívumtörténet, nem tudta teljesíteni ezt a kérést.
|
Egy megjegyzésre Árnyékmásolat, szó szerint - "árnyékmásolat". Gondoskodik arról, hogy a fájlrendszer azonnali másolatai olyan módon készüljenek el, hogy az eredeti módosításai semmilyen módon ne érintsék azokat. Ezzel a funkcióval lehetőség van egy adott időre több rejtett másolatot készíteni egy fájlról, valamint biztonsági másolatot készíteni a menet közben írásra megnyitott fájlokról. A Kötetmásolat Árnyékszolgáltatás felelős az Árnyékmásolat működéséért. Rendszerállapot, szó szerint - "a rendszer állapota". A rendszerállapot biztonsági mentése biztonsági másolatot készít az operációs rendszerek kritikus összetevőiről Windows családok. Ez lehetővé teszi a korábban telepített rendszer visszaállítását a megsemmisítés után. A rendszerállapot másolásakor a rendszer elmenti a rendszerleíró adatbázist, a rendszerindítási és egyéb fontos fájlokat, beleértve az Active Directory, a Certificate Service adatbázis, a COM + osztály regisztrációs adatbázis és a SYSVOL könyvtárak visszaállításához szükséges fájlokat. A UNIX család operációs rendszerében a rendszerállapot másolásának közvetett analógja az /etc, /usr/local/etc könyvtárak és a rendszerállapot visszaállításához szükséges egyéb fájlok tartalmának mentése. |
Ami ebből következik: mindkét típusú biztonsági mentést kell használni: katasztrófa utáni helyreállításhoz és archív tároláshoz egyaránt. Ugyanakkor meg kell határozni a másolandó erőforrások listáját, a feladatok végrehajtásának idejét, valamint azt is, hogy hol, hogyan és mennyi ideig tárolják a biztonsági másolatokat.
Kis adatmennyiség és nem túl bonyolult IT-infrastruktúra esetén megpróbálhatja kombinálni a két feladatot egyben, például készíthet napi teljes biztonsági mentést az összes lemezpartícióról és adatbázisról. De mégis jobb különbséget tenni két cél között, és mindegyikhez kiválasztani a megfelelő eszközöket. Ennek megfelelően minden feladathoz más eszközt használnak, bár vannak univerzális megoldások, mint például az Acronis True Image csomag vagy az ntbackup program
Nyilvánvaló, hogy a mentés céljainak és célkitűzéseinek, valamint a megvalósítási megoldások meghatározásakor az üzleti követelményekből kell kiindulni.
A katasztrófa utáni helyreállítási feladat végrehajtásakor különböző stratégiákat használhat.
Bizonyos esetekben a rendszert közvetlenül "csupasz fémre" (csupasz fémre) kell visszaállítani. Ez megtehető például az Acronis True Image programmal, amely az Universal Restore modulhoz tartozik. Ebben az esetben a szerverkonfiguráció nagyon rövid időn belül újra üzembe helyezhető. Például egy 20 GB-os operációs rendszerrel rendelkező partíció teljesen reálisan nyolc perc alatt eltávolítható egy biztonsági másolatból (feltéve, hogy az archív másolat elérhető 1 GB/s-os hálózaton).
Egy másik lehetőségnél célszerűbb egyszerűen „visszaállítani” a beállításokat az újonnan telepített rendszerre, például a konfigurációs fájlok másolását az /etc mappából és a többi UNIX-szerű rendszeren (Windows alatt ez nagyjából megfelel a fájl másolásának és visszaállításának Rendszerállapot). Természetesen ezzel a megközelítéssel a kiszolgálót legkorábban az operációs rendszer telepítése és visszaállítása előtt állítják üzembe. szükséges beállításokat ami sokkal hosszabb ideig fog tartani. De mindenesetre a katasztrófa-helyreállításról szóló döntés az üzleti igényekből és az erőforrások korlátaiból fakad.
Az alapvető különbség a tartalék és a redundáns redundancia rendszerek között
Ez egy másik érdekes kérdés, amelyet szeretnék érinteni. A redundáns hardverredundancia rendszerek bizonyos redundancia hardverbe történő bevezetésére utalnak annak érdekében, hogy az egyik komponens hirtelen meghibásodása esetén fenntartsák a működőképességet. Tökéletes példa ebben az esetben a RAID tömb (Redundant Array of Independent Disks). Egyetlen lemezhiba esetén elkerülhető az információvesztés, és biztonságos csere végezhető, magának a lemeztömbnek a sajátos felépítéséből adódóan adatmenthető (a RAID-ről bővebben itt olvashat).
Hallottam ezt a mondatot: "Nagyon megbízható berendezéseink vannak, mindenhol vannak RAID tömbök, így nincs szükségünk biztonsági másolatokra." Igen, természetesen ugyanaz a RAID-tömb megmenti az adatokat a megsemmisüléstől, ha az egyik merevlemez meghibásodik. De ez az adatsérülés miatt van Számítógépes vírus vagy nem menti meg a nem megfelelő felhasználói műveletektől. Még akkor sem menti el a RAID-et, ha a fájlrendszer összeomlik egy jogosulatlan újraindítás következtében.
|
Apropó Az adatok biztonsági mentésének tervezésekor figyelembe kell venni a biztonsági mentés és a redundáns rendszerek közötti különbségtétel fontosságát, legyen szó akár szervezetről, akár otthoni számítógépekről. Kérdezd meg magadtól, hogy miért készítesz másolatokat. Ha biztonsági mentésről beszélünk, akkor ez egy véletlen (szándékos) művelet során történő adatmentést jelent. A redundáns redundancia lehetővé teszi az adatok mentését, beleértve a biztonsági másolatokat is, a berendezés meghibásodása esetén. Sok olyan olcsó eszköz van a piacon, amelyek megbízható redundanciát biztosítanak RAID-tömbök vagy felhőtechnológiák használatával (például Amazon S3). Mindkét típusú információs foglalás egyidejű használata javasolt. Andrej Vasziljev, a Qnap Russia vezérigazgatója |
Mondok egy példát. Vannak esetek, amikor az események a következő forgatókönyv szerint alakulnak: amikor egy lemez meghibásodik, az adatok a redundancia mechanizmusa miatt visszaállnak, különösen a mentett ellenőrző összegek felhasználásával. Ezzel párhuzamosan jelentősen csökken a teljesítmény, lefagy a szerver, szinte elveszik az irányítás. A rendszergazda más kiutat nem látva hideg újraindítással újraindítja a szervert (vagyis rákattint a "RESET"-re). Az ilyen élő túlterhelés eredményeként fájlrendszeri hibák lépnek fel. A legjobb, ami ebben az esetben elvárható hosszú munka lemezellenőrző a fájlrendszer integritásának visszaállításához. A legrosszabb esetben el kell búcsúzni fájlrendszerés értetlenül áll a kérdés előtt, hogy hol, hogyan és mennyi időn belül állíthatja vissza az adatokat és a szerver teljesítményét.
Még fürtözött architektúra esetén sem kerülheti el a biztonsági mentést. A feladatátvételi fürt valójában működésben tartja a rábízott szolgáltatásokat, ha az egyik kiszolgáló meghibásodik. A fenti problémák, például vírustámadás vagy a hírhedt „emberi tényező” miatti adatsérülés esetén egyetlen klaszter sem ment meg.
Az egyetlen dolog, amely a katasztrófa-helyreállítás gyengébb biztonsági mentési helyettesítőjeként működhet, az a tükör-mentési szerver jelenléte, amely állandó adatreplikációt biztosít a fő szerverről a tartalék szerverre (az elsődleges készenléti elv szerint). Ebben az esetben, ha a főszerver meghibásodik, annak feladatait a tartalék veszi át, és még adatátvitel sem szükséges. De egy ilyen rendszer meglehetősen drága és időigényes megszervezése. Ne feledkezzünk meg az állandó replikáció szükségességéről.
Világossá válik, hogy egy ilyen megoldás csak olyan kritikus szolgáltatások esetében költséghatékony, amelyeknél magas a hibatűrés és minimális helyreállítási idő. Általában az ilyen rendszereket nagyon nagy szervezetekben alkalmazzák, amelyek nagy áruforgalommal rendelkeznek. Ez a séma pedig gyengébb helyettesítője a biztonsági mentésnek, mert mindazonáltal, ha egy számítógépes vírus megsérti az adatokat, nem megfelelő felhasználói műveletek vagy az alkalmazás nem megfelelő működése, mindkét szerveren az adatok és a szoftverek érintettek lehetnek.
És természetesen semmilyen redundáns redundanciarendszer sem oldja meg az adatarchívum egy bizonyos időszakra való fenntartásának problémáját.
A "biztonsági ablak" fogalma
A biztonsági mentés nagy terhelést jelent a redundáns szerverre. Ez különösen igaz a lemez alrendszerÉs hálózati kapcsolatok. Egyes esetekben, amikor a másolási folyamat kellően magas prioritású, ez bizonyos szolgáltatások elérhetetlenségéhez vezethet. Ezenkívül az adatok másolása a változtatások idején jelentős nehézségekkel jár. Természetesen vannak technikai eszközök a problémák elkerülésére az adatok integritásának megőrzése mellett, de ha lehetséges, az ilyen menet közbeni másolást legjobb elkerülni.
A fent leírt problémák megoldásának kiútja önmagát javasolja: a másolatkészítési folyamat elindítását egy inaktív időszakra halasztani, amikor a biztonsági mentés és az egyéb működő rendszerek kölcsönös hatása minimális lesz. Ezt az időszakot "mentési ablaknak" nevezik. Például egy 8x5-ös képletet alkalmazó szervezetnél (heti öt nyolcórás munkanap) ilyen „ablak” általában a hétvégék és az éjszakai órák.
A 24x7 képlet szerint (egész héten 24 órában) működő rendszerek esetében a minimális aktivitás idejét használják ilyen időszaknak, amikor nincs nagy terhelés a szervereken.
A biztonsági mentés típusai
A mentések megszervezése során felmerülő felesleges anyagköltségek elkerülésére, illetve lehetőség szerint a biztonsági mentési ablakon túlmenően több mentési technológiát fejlesztettek ki, amelyeket az adott helyzettől függően alkalmaznak.
Teljes biztonsági mentés (vagy teljes biztonsági mentés)
Ez a biztonsági mentések készítésének fő és alapvető módja, amelyben a kiválasztott adattömb teljes egészében másolásra kerül. Ez a legteljesebb és legmegbízhatóbb biztonsági mentési típus, bár a legdrágább. Ha több adatpéldányt kell menteni, a teljes tárolt mennyiség azok számával arányosan növekszik. Az ilyen pazarlás elkerülése érdekében tömörítési algoritmusokat használnak, valamint ennek a módszernek a kombinációját más típusú biztonsági mentésekkel: növekményes vagy differenciális. És természetesen a teljes biztonsági mentés nélkülözhetetlen, ha biztonsági másolatot kell készítenie egy gyors rendszer-visszaállításhoz a semmiből.
Növekményes másolat
Ellentétben a teljes biztonsági mentéssel, ebben az esetben nem minden adat (fájlok, szektorok stb.) kerül másolásra, hanem csak azok, amelyek az utolsó mentés óta megváltoztak. A másolási idő meghatározására különféle módszerek használhatók, például a Windows család operációs rendszereit futtató rendszereken a megfelelő fájlattribútum (archív bit) kerül felhasználásra, amelyet a fájl megváltoztatásakor állít be, és a rendszer alaphelyzetbe állítja. biztonsági mentési program. Más rendszerek használhatják a fájl módosítási dátumát. Nyilvánvaló, hogy az ilyen típusú biztonsági mentést használó séma gyengébb lesz, ha időről időre nem hajtanak végre teljes biztonsági mentést. A teljes rendszer-visszaállításnál vissza kell állítania a Full backup által létrehozott legutóbbi másolatot, majd felváltva a növekményes másolatok adatait a létrehozásuk sorrendjében „gurítani”.
Mire használható ez a fajta másolat? Archív másolatok készítése esetén csökkenteni kell a tárolóeszközök fogyasztott mennyiségét (például csökkenteni kell a felhasznált szalagos adathordozók számát). Minimálisra csökkenti a biztonsági mentési feladatok elvégzéséhez szükséges időt is, ami rendkívül fontos lehet, ha napi 24 órában kell dolgoznia, vagy nagy mennyiségű információt kell letöltenie.
A növekményes másolásnak van egy árnyalata, amelyet tudnia kell. A részleges visszaállítás a kívánt törölt fájlokat is visszahozza a helyreállítási időszak alatt. Mondok egy példát. Például a teljes biztonsági mentés hétvégén, a növekményes mentés pedig hétköznapokon történik. A felhasználó hétfőn hozta létre a fájlt, kedden megváltoztatta, szerdán átnevezte, csütörtökön törölte. Tehát egy heti időszakra tartó, szekvenciális, szakaszos adat-helyreállítással két fájlt kapunk: az átnevezés előtti kedden a régi névvel, a szerdán létrehozott új névvel. Ez azért történt, mert a különböző növekményes másolatok ugyanannak a fájlnak különböző verzióit tárolták, és végül az összes változat visszaáll. Ezért az adatok szekvenciális visszaállításakor egy „olyan állapotú” archívumból érdemes több lemezterületet lefoglalni, hogy a törölt fájlok is elférjenek.
Differenciál biztonsági mentés
Ez abban különbözik a növekményestől, hogy az adatokat a teljes biztonsági mentés utolsó pillanatától másolják át. Ebben az esetben az adatok eredményszemléletű módon kerülnek az archívumba. A Windows család rendszereiben ezt a hatást úgy érik el, hogy a differenciális másolás során az archív bitet nem állítják vissza, így a megváltozott adatok addig kerülnek az archív másolatba, amíg a teljes másolat az archív biteket nullára nem állítja.
Mivel minden ilyen módon létrehozott új másolat tartalmazza az előző adatait, kényelmesebb az adatok teljes helyreállítása a katasztrófa idején. Ehhez mindössze két példányra van szükség: a teljesre és az utolsóra a differenciálisak közül, így sokkal gyorsabban életre keltheti az adatokat, mintha az összes lépést szakaszosan görgetné. Ráadásul ez a fajta másolás megkíméli a növekményes másolás fenti jellemzőit, amikor teljes felépüléssel a régi fájlok, mint egy Phoenix madár, újjászületnek a hamvakból. Kevesebb a zűrzavar.
De a differenciális másolás lényegesen gyengébb a növekményes másolásnál a szükséges hely megtakarításában. Mivel minden új másolat a korábbiak adatait tárolja, a biztonsági másolatok teljes mennyisége összehasonlítható egy teljes másolattal. És természetesen az ütemezés megtervezésekor (és annak kiszámításakor, hogy a mentési folyamat belefér-e az időablakba), figyelembe kell venni az utolsó, legvastagabb, differenciált másolat elkészítésének idejét.
Tartalék topológia
Nézzük meg, melyek a biztonsági mentési sémák.
decentralizált rendszer
Ennek a rendszernek a lényege egy bizonyos közös hálózati erőforrás(lásd 1. ábra). Például egy megosztott mappa vagy egy FTP-kiszolgáló. Biztonsági mentési programok készletére is szükség van, amelyek időről időre információkat töltenek fel kiszolgálókról és munkaállomásokról, valamint egyéb hálózati objektumokról (például az útválasztók konfigurációs fájljairól) erre az erőforrásra. Ezek a programok minden kiszolgálóra telepítve vannak, és egymástól függetlenül működnek. Kétségtelen előnye ennek a rendszernek a végrehajtásának egyszerűsége és alacsony költsége. Másoló programokként az operációs rendszerbe beépített szokásos eszközök vagy szoftverek, például DBMS alkalmasak. Ez lehet például az ntbackup program a Windows családhoz, a tar program UNIX-szerű operációs rendszerekhez, vagy a beépített SQL szerver parancsokat tartalmazó szkriptek az adatbázisok biztonsági mentési fájlokba való kiírásához. További előny a különféle programok és rendszerek használatának lehetősége, amennyiben mindegyik hozzáfér a biztonsági mentések tárolására szolgáló célforráshoz.
A hátránya ennek a rendszernek a lassúsága. Mivel a programok egymástól függetlenül kerülnek telepítésre, mindegyiket külön kell beállítani. Meglehetősen nehéz figyelembe venni az ütemezés és az időintervallumok elosztásának sajátosságait, hogy elkerüljük a célerőforrásért való versengést. A felügyelet is nehézkes, az egyes szerverekről a másolás folyamatát a többitől külön kell figyelni, ami viszont magas munkaerőköltségekhez vezethet.
Ezért ezt a sémát használják kis hálózatok, valamint olyan helyzetben, amikor a rendelkezésre álló eszközökkel nem lehet központosított mentési sémát megszervezni. Több Részletes leírás ez a séma és gyakorlati szervezése a -ban található.
Központosított biztonsági mentés
Az előző sémától eltérően ez az eset egy világos hierarchikus modellt használ, amely a "kliens-szerver" elven működik. A klasszikus változatban minden számítógépre speciális ügynökprogramok, a központi szerverre pedig egy szervermodul kerül telepítésre Szoftver csomag. Ezek a rendszerek dedikált felügyeleti konzollal is rendelkeznek szerver rész. A vezérlési séma a következőképpen néz ki: a konzolról feladatokat készítünk másolásra, visszaállításra, a rendszerről információgyűjtésre, diagnosztikára stb., és a szerver megadja az ügynököknek a szükséges utasításokat ezen műveletek elvégzéséhez.
A legtöbb népszerű biztonsági mentési rendszer ezen az elven működik, mint például a Symantec Backup Exec, a CA Bright Store ARCServe Backup, a Bacula és mások (lásd: 2. ábra).
A legtöbb operációs rendszerhez különféle ágensek mellett vannak fejlesztések a népszerű adatbázisok biztonsági mentésére és vállalati rendszerek például SM esetén SQL szerver, MS Exchange, Oracle Database és így tovább.
Nagyon kis cégek esetében bizonyos esetekben kipróbálhatja a központosított biztonsági mentési séma egyszerűsített változatát ügynökprogramok használata nélkül (lásd 3. ábra). Ez a séma akkor is használható, ha a használt biztonsági mentési szoftverhez nincs speciális ügynök implementálva. Ehelyett a szervermodul már meglévő szolgáltatásokat és szolgáltatásokat fog használni. Például adatok "kigereblyézése" a rejtettből megosztott mappák Windows kiszolgálókon, vagy másoljon fájlokat SSH-n keresztül UNIX rendszereket futtató kiszolgálókról. Ez a séma nagyon jelentős korlátai vannak az írásra megnyitott fájlok mentési problémáival kapcsolatban. Az ilyen akciók eredményeként nyissa meg a fájlokat vagy kimarad, és nem szerepel a biztonsági másolatban, vagy hibákkal másolják. Számos megoldás létezik erre a problémára, például a feladat újrafuttatása, hogy csak a korábban megnyitott fájlokat másolja, de egyik sem megbízható. Ezért egy ilyen rendszer csak bizonyos helyzetekben használható. Például 5x8-as üzemmódban dolgozó kis szervezetekben, fegyelmezett alkalmazottakkal, akik elmentik a változtatásokat és bezárják a fájlokat, mielőtt elhagyják otthonukat. Egy ilyen csonka központosított séma megszervezéséhez, amely kizárólag Windows környezetben működik, az ntbackup jó választás. Ha hasonló sémát kell használnia heterogén környezetben vagy kizárólag UNIX számítógépek között, azt javaslom, hogy a Backup PC felé nézzen (lásd).
4. ábra Vegyes biztonsági mentési séma
Mi az off-site?
Zavaros és változó világunkban olyan események fordulhatnak elő, amelyek kellemetlen következményekkel járhatnak az IT infrastruktúrára és az üzlet egészére nézve. Például tűz egy épületben. Vagy szünet a központi fűtés akkumulátorában a szerverteremben. Vagy a berendezések és alkatrészek banális ellopása. Az információvesztés elkerülésének egyik módja ilyen helyzetekben az, hogy a biztonsági másolatokat a fő helytől távolabbi helyen tárolják. szerver hardver. Ugyanakkor biztosítani kell gyors út hozzáférés a helyreállításhoz szükséges adatokhoz. A leírt módszert off-site (más szóval a másolatok vállalaton kívüli tárolása) nevezzük. Alapvetően két módszert alkalmaznak ennek a folyamatnak a megszervezésére.
Adatok írása cserélhető adathordozókra és azok fizikai mozgása. Ebben az esetben gondoskodni kell az adathordozó gyors visszaszállításának lehetőségéről hiba esetén. Például tárolja őket egy közeli épületben. Ennek a módszernek az az előnye, hogy ezt a folyamatot minden nehézség nélkül meg lehet szervezni. Hátránya az adathordozók visszaküldésének bonyolultsága és a tároláshoz szükséges információk továbbítása, valamint az adathordozó sérülésének veszélye a szállítás során.
Adatok másolása egy másik helyre hálózati kapcsolaton keresztül. Például VPN-alagút használata az interneten keresztül. Ebben az esetben az az előnye, hogy nincs szükség információval ellátott médiát valahova hordozni, a mínusz pedig az, hogy kellően széles csatornát kell használni (ez általában nagyon költséges), és meg kell védeni a továbbított adatokat (például a ugyanaz a VPN). A nagy mennyiségű adat átvitelének nehézségei nagymértékben csökkenthetők tömörítési algoritmusok vagy deduplikációs technológia alkalmazásával.
Külön érdemes megemlíteni az adattárolás megszervezésének biztonsági intézkedéseit. Mindenekelőtt ügyelni kell arra, hogy az adathordozók biztonságos helyiségben legyenek, és olyan intézkedésekről, amelyek megakadályozzák az adatok illetéktelen beolvasását. Például használjon titkosítási rendszert, kössön titoktartási megállapodásokat stb. Ha cserélhető adathordozóról van szó, akkor az azon lévő adatokat is titkosítani kell. A használt jelölési rendszer nem segítheti a támadót az adatelemzésben. A névhordozók címkézéséhez arc nélküli számozási sémát kell alkalmazni átvitt fájlokat. Hálózaton keresztüli adatok átvitelekor (mint fentebb már említettük) biztonságos adatátviteli módszereket kell használni, például VPN-alagút.
Elemeztük a biztonsági mentés megszervezésének főbb pontjait. A következő részben módszertani ajánlásokat és gyakorlati példákat adunk a hatékony mentési rendszer létrehozásához.
Kapcsolatban áll
