Az oldalon most nem azokról az esetekről szeretnénk írni, nelyek rutinmunkának számítanai az adatmentést végzőknek (letörölt állományok, véletlenül megformázott merevlemez adatainak visszaállítása, leesett, tönkrement merevlemezek, memóriakártyák helyreállítása) hanem kifejezetten néhány adatmentés szempontjából bonyolultabb érdekesebb esetetről, mely akár tanulságként is szolgálhat látogatóinknak ezáltal elkerülve egy edatveszteséget.
Egy igen érdekes - adatmentés szempontjából izgalmas - esettel találkoztunk. Egy 4 lemezes QNAP NAS, 4x 3TB merevlemezzel, RAID5 konfigurációval került hozzánk. Az adatok közvetlen elvesztéséhez emberi hiba vezetett. Szigorú értelemben szinte majdnem minden adat veszteséghez emberi hiba vezet, hiszen a biztonsági mentés hiánya már önmagában az, itt mégis egy másik hiba vezetett a RAID tömb leállásához. Az esetet azért is írjuk kiemelten le, hogy az alább olvasottakat lehetőleg senki se próbálja ki, főleg nem védőháló, azaz biztonsági másolat nélkül.
A 4 db merevlemezből (WD Green desktop sorozatú HDD) egy már korábban meghibásodás miatt kiesett a RAID tömbből (pont az 1. lemez) melyet helyesen a tulajdonos a Western Digital NAS Edition diszkjére cserélt ki. Ezt követően az eszköz sokáig hibátlanul működött. Gondolt egyet az eszköz tulajdonosa, milyen jó lenne, a megmarad 3 régi (azaz nem NAS-ba baló) lemezt is kicserélni WD Red diszkekre. Menet közben kihúzta a 2. lemezt. Ezt persze a RAID tömb „túlélte” hiszen un. sérült (degraded) módban de működött tovább. Meg is kapta az új lemezt, melyre látszólag vissza is állította a RAID tömböt (helyesen megvárta ügyfelünk, hogy visszaszinkronizálja az adatokat). A NAS ekkor hibátlannak vélte a RAID kötete. Következett a 3. merevlemez cseréje. Abban a pillanatban, amikor ez a csere megtörtént, I/O hibára hivatkozva a helyreállítás leállt, a RAID tömb többé nem volt elérhető. A helyreállítás szerencsére sikerült, az adatokat hibátlanul visszaállítottuk, ezzel az adatmentés szerencsésen lezárult. Most mégis leírnánk, hogy mi vezetett ahhoz, hogy ez a módszere nem működött.
Alapvetően – bár igen veszélyes és kockázatos így frissíteni a merevlemezeket – akár sikerülhetett volna. A baj abból származott, hogy – ellentétben az első merevlemez cseréjével – most nem vadonatúj lemezek kerültek a kivettek helyére, hanem már használtak. Ezzel talán nem is lett volna baj, ha ezek a merevlemezek nem egy másik NAS-ból származtak volna, melyben 3 db 3TB-os merevlemez alkotta a RAID5 tömböt. A merevlemezen található és nem törölt RAID információ olyan szinten megzavarta a QNAP NAS rendszerét – mely egyébként beágyazott Linux– melynek így nem sikerült a visszaszinkronizálás és a harmadik lemez eltávolításakor a RAID tömb 2 diszket veszítve azonnal leállt. Az adatmentés nehézségét és egyben szépségét is pont ez adta, ugyanis összesen 6 merevlemezből kellett kiválasztani 3 megfelelőt melyből vissza lehetett állítani az elveszett adatokat.
Az legérdekesebb esetek közé sorolható a címben megnevezett két egymáshoz kapcsolódott tárolóhoz adatmentése. Amikor az eszközt a megrendelő eljuttatta laboratóriumunkba a következő nem mindennapi helyzettel találkoztunk. A Synology DS1812 NAS tárolóban (8 lemezes NAS) 8db 1TB-os merevlemez, míg a hozzá kapcsolódott DX513 extenderben (5 lemezes bővítő) 5db 4TB-os merevlemez került beépítésre. A rendszer sokáig teljesen hiba nélkül üzemelt, mígnem egyik pillanatról a másikra nem volt elérhető. Utóbb kiderült, hogy az egyik merevlemez meghibásodása (szektorhibák) vezetett a kötet leállásához, még akkor is, ha ennek nem szabadott volna bekövetkeznie. Az összes merevlemez nettó kapacitás 28TB volt, ennek ellenére a felhasználó (bár pontos emléke nem volt), a nettó kapacitást nem megközelítő, összesen kb. 10-11TB hasznos adatterületről számolt be. Azt tudta továbbá, hogy egyetlen kötetben szerepeltek a diszkek mely szerinte RAID 5 konfigurációban voltak. Nem tudtunk mást tenni, igyekeztünk mindent megtudni a NAS előéletéről, hiszen aki a konfigurációt készítette nem informatikus volt, egyszerűen csak átlagos informatikai ismeretekkel rendelkező felhasználó. A beszélgetés során kiderült (itt kiemelnénk azt, hogy miért is fontos az ügyfelek kikérdezése), hogy valamikor régen a DS1812 NAS-t 8db 1TB-os diszkkel vásárolták és kezdték használni. Amikor a tárhely kevésnek bizonyult, vásárolták a kiegészítő extendert, melyet csatlakoztattak a meglévő NAS-hoz, ezt követően pedig kiterjesztették a RAID konfigurációt. Ekkor már sejthető volt, hogy miért csak ilyen kisméretű tárhely állt rendelkezésre. Történt ugyanis, hogy a 4TB-os merevlemezeket egyszerűen csak 1TB-sonént használta a NAS, hiszen nem új kötetet hoztak létre csak kiterjesztették a korábbit. (Zárójelben jegyezzük meg, hogy a mai NAS-os valóban tudják a RAID tötetek kiterjesztését, de ez nem egy veszélytelen folyamat, így biztonsági mentés nélkül nehogy belefogjon bárki is.) Innen már egyszerűbb volt a helyzet, csak a hatalmas adatmennyiség miatt (hiszen minden merevlemezről biztonsági másolat készült) ez nem ment egyik pillanatról a másikra. A RAID mentése szempontjából a végéhez közeledtünk a folyamatnak. Bár – ellentétben a felhasználó állításával – végül is RAID6 konfigurációban szerepelt a kötet, azt összeállítani már nem volt különösen nehéz. Egy nem várt fordulat következett ekkor be. Az adatok legnagyobb része (persze a legfontosabbak) titkosítva szerepeltek a köteten, használták ugyanis a Synology file titkosító lehetőségét (Linux CryptoFS file renszer). Jelszó persze nem volt és nem is emlékeztek rá. Amiket kaptunk egyik sem bizonyult megfelelőnek. Nem maradt hát más lehetőség fel kellett „éleszteni” a NAS-t hiszen abban tárolva volt a jelszó és így hozzá lehetett férni az adatokhoz. Végül is ez is sikerült, így minden elveszett adatot vissza tudtunk adni a tulajdonosának.
Egy másik érdekes adatmentés, mely esetében is emberi hiba vezetett az adatok elvesztéséhez. A történet egy Windows 2012 szerverrel és 2db 3TB-os tükörben azaz RAID1-ben lévő merevlemezzel kezdődik, ahol annak telepítője bekapcsolta erre a kötetre a Windows 2012 szerverben elérhető deduplication rulet. Ez nem tesz mást, mint a duplikált állományokból – függetlenül azok helyétől - csak egy példányt tárol le, így – főleg ha sok a duplikátum – jelentős helyet takarít meg. (Zárójelben jegyezzük meg, hogy esetünkben a 3TB adatterületen összesen 2,4 TB adat volt, ami azonban összesen csak 1,1TB helyet foglalt le, jelentős megtakarítást eredményezett a duplikáció kiszűrése.) Egy kisebb, de növekvő cégről volt szó, ahol úgy gondolták nem költenének a Windows 2012 szerverhez kliensek vásárlására, hanem helyette a Windows 2012 Esential szervert vennék meg, mely összesen 25 felhasználót engedélyez (igaz tovább nem bővíthető). A kötet másolása (2,4TB adat) több mint egy napig tartott volna, így a rendszergazda úgy gondolta, megspórolja ezt az időt, nem készít biztonsági másolatot, úgyis van 2 példány belőle, hanem majd ezekből egyet az új szerverbe helyezve átmásolja az adatokat. Csakhogy nem tudott a deduplikációról – nem ő telepítette a rendszert korábban – és nem is tűnt fel neki a jelentős adatmennyiség, ami a foglaltsággal ellentmondott. Újratelepítette a rendszert két másik merevlemezre, s döbbent rá arra, hogy nem tudja visszamásolni az adatokat. Ekkor – még mindig nem tudva a deduplikációról – nem megfelelő adatmentő szoftverekkel nekiállt maga lementeni az adatokat, persze sikertelenül, viszont tönkretéve a tükör mindkét példányát. Ekkor kaptuk meg a lemezeket, ahonnan aztán nem kis munkával, (a sérült file rendszert is javítva) de sikerült visszaállítanunk az adatokat ráadásul szinte hiánytalanul.
Viszonylag egyszerű, mégis tanulságos adatmentéssel kerültünk szembe, amikor egy igen régi, több mint 7 éves Apple Mac számítógépet hoztak be hozzánk. A készülék összesen 4db merevlemezt rejtett magában (1db 250GB-osat és 3db 750GB-osat). A felhasználónak sajnos fogalma sem volt arról, hogy milyen RAID konfigurációban szerepelnek a merevlemezek. Amire emlékezett az később tévesnek bizonyult. Úgy gondolta ugyanis, hogy a négy merevlemez RAID5 konfigurációban szerepel, mely természetesen már akkor megdőlt, amikor nem 4db egyforma merevlemezt találtunk a számítógépben. (Zárójelben jegyezzük meg, hogy elméletben a négy merevlemez szerepelhetett volna egyetlen RAID kötetben, de ekkor a nagyobb merevlemezek is csak 250GB-osként, tehát jelentős adatterület veszteséggel lehettek volna használatban. Erre egyébiránt akkor szokott sor kerülni, ha – hibatűrő RAID konfiguráció esetén - az időközben meghibásodó merevlemezek helyett nagyobbakat tettek volna.) Sajnos a rendelkezésre álló helyre sem emlékezett, melyből következtetni lehetett volna a RAID konfigurációra. Megfejteni persze adatmentés végző szakembernek nem jelent különösebb gondot , de megnöveli az adatmentés idejét, így az árát is. Végül szerencsésen alakult a mentés, mert – bár a három merevlemezből az egyik már jelentős mennyiségű hibás szektort tartalmazott – a RAID0 egyébként egyáltalán nem hibatűrő RAID kötet sikerült összeállítani a HFS+ partíció kis mértékű file rendszeri sérüléseit javítani, így a rajta tárolt állományokat lementve a tulajdonosnak visszaadni.
Speciális adatmentések körébe sorolt eset hozott hozzánk egy ügyfelünk 2015 év utolsó napjaiban. Nem klasszikus adatmentésről volt szó, hiszen nem elveszett állományokat kellett visszaállítanunk logikai vagy éppen fizikai sérült merevlemezekről. Egy megsérült állomány – jelen esetben egy Windows Bakcup Filet (BKF) – kellett a lehetőségekhez képest helyreállítani. Az eset apropójául egy sajnos manapság igen gyakori Crypto, más néven zsarolós vírus szolgált. Az egyik a szerverhez kapcsolódott kliens számítógép fertőződését követően a vírus nagyon rövid idő alatt átkódolta a szerveren található valamennyi értékes állományt. Szerencsére volt biztonsági mentés, ráadásul - az adatok visszaállíthatósága szempontjából kifejezetten kedvező - Microsoft Windows Backup állományba inkrementálisan mentették az adatokat. Tették ezt minden nap, ráadásul úgy, hogy volt egy hétfői, keddi, szerdai, csütörtöki és egy pénteki egymástól teljesen független állomány. A Windows Backup alapvetően szalagos egységekre lett kitalálva ahol egy kiinduló állapothoz képest mindig csak a változásokat tárolják le, így minden esetben a korábbi állományok is megmaradnak. Észlelve a vírusfertőzést nem kellett (volna) mást tenniük, mint valamelyik backup állományt egy tetszőleges napra (célszerűen a vírusfertőzést megelőző napon készültet a vírusfertőzés előtti napra) visszaállítani. Mégis sajnos hiba csúszott a gépezetbe, ugyanis – bár minden nap elkészült a biztonsági mentés a változásokról – a mentés visszaállíthatóságát senki soha nem ellenőrizte (Tanulságként említjük meg, hogy rendszergazdák által igen gyakran elkövetett hiba). 2015. februárjában ugyanis mind az öt állomány megsérült, így egyszerűen nem lehetett visszaállítani azokat. Ennek realizálódásakor fordult ügyfelünk hozzánk. Végül sikerült visszaállítani a legtöbb adatot a legutolsó a vírusfertőzés előtti napnak megfelelő állapotban. Amelyeket nem azok egy banális még jóval korábban elkövetett hiba miatt maradtak mentetlenül. Közvetlenül nem tartozik az adatmentéshez, de leírjuk, hátha valakinek mégis egyszer tanulságként szolgál hasonló esetben (bár a Microsoft Backup már nem került bele a legújabb operációs rendszerekbe. Windows Server 2008R2-től és Windows 7-től desktop rendszerektől). A bkf fájlokat valamikor 2009-ben hozták létre, ettől a ponttól az egyes állományokba hetente egy-egy mentés került inkrementálisan. Így állományonként több mint 300 mentésnek kellett volna lennie. Nem volt azonban csak 183. Valamikor ugyanis 2012-ben valaki letörölhette vagy elmozgathatta ezeket az állományokat a helyükről úgy, hogy a Windows Bakup katalógusát nem törölte, az inkrementálás miatt, az újonnan létrehozott állományokba csak a megváltozott dokumentumok kerültek. Így a 2012. nyara előtt keletkezett, de az óta soha meg nem változott állományokat nem lehetett visszaállítani. Ezek az állományok mentésre csak akkor kerültek, amikor a vírus módosította őket, de azokat nemcsak nem volt érdemes, de felesleges is lett volna visszaállítani, hiszen ezen átkódolt formában a szerveren meg is voltak.
Adatmentés szempontjából egy másik egyszerű esettel álltunk szemben amikor ügyfelünk egy 2db egyenként 3TB-os lemezből álló Western Digital MyBook külső adattárolót hozott be hozzánk. A benne lévő lemezek RAID0-ban voltak, melyek valamilyen ismeretlen okból szétestek. A 6TB-os RAID kötet összeállítása itt sem okozott különösebb gondot, sajnos azonban az összeállított RAID kötet a sérülésnek köszönhetően file rendszeri hibákat tartalmazott. Ezek javítása után közel 100%-os adatmentéssel sikerült az elveszett adatokat visszaállítani.
Két 1TB-os, igencsak sérült merevlemez érkezett hozzánk adatmentésre. A lemezek a nem hibatűrő RAID0 konfigurációban voltak. Szerencsére még éppen az utolsó pillanatban érkeztek ahhoz (persze a RAID vezérlő már hibásnak vélte őket és le is állította a kötetet, ezért volt szükség az adatmentésre), hogy a winchestereket megbontása nélkül le tudjuk menteni őket. A mentés után összeállítható volt a RAID kötet, de a szektorhibák azért megtették hatásukat, ugyanis a két partícióra osztott kötet második partíciója igen csak sérült volt. Annyira azért szerencsére mégsem, hogy ne sikerült volna a file rendszeri hibákat legalább részben javítani, így végül is valamennyi, a felhasználó számára értékes adatot hiánytalanul visszaállítani.
Hollandiából kaptuk a címben is szereplő 4 db 500GB-os SSD-t. A szerver - egyben a annak konfigurációja, különös tekintettel a RAID csatolóra -, amelyben az adathordozók működtek nem volt ismert számunkra. Mindösszesen annyit tudtunk, hogy a 4 merevlemez RAID10 konfigurációban működött egy VmWare Hypervisor storage-ként, a storage pedig néhány virtuális gépnek adott otthont. A RAID kötet helyreállítása itt sem okozott különösebb gondot, bár összesen 3 variációból kellett kiválasztani a legmegfelelőbbet (pontosabban a legépebbet) hiszen a 2-2 merevlemez melynek egyformának kellett volna lennie nem voltak tökéletesen egyformák. A leállás körülményeiről sem tudtunk semmit, az azonban megállapítható volt, hogy a kötet nagyon súlyosan megsérült. A helyreállítást követően – a sérült storage másik általunk konfigurált VmWare Hypervisor alá történő „mountolása” után – a rajta tárolt virtuális gépek egy kivételével elindíthatóak voltak, a legfontosabb azonban sajnos nem. A helyreállított storage sérült file rendszere a méretét is helytelenül látta, lemásolni azonban csak az első 8MB-ot lehetett. Nem maradt más hátra, valahogy vissza kellett állítani a nem működő virtuális gépet. Nem volt elengedhetetlen a sérült virtuális gép elindítása, csak a virtuális lemezben található vállalatirányítási rendszer adatbázis állománya. Végül ezt is sikerült visszaállítani, bár működésre már nem bírtuk, igaz azonban az is, hogy ebbe nem is fektettünk túl sok energiát. A megrendelő számára az adatállományok gyors visszaállítása már teljesen megfelelt.
Hamarosan ...