NAS server herstellen is zeer ingewikkeld, blijkt uit klantcase
Denk je dat een goedkope NAS server herstellen makkelijk is? Denk dan nog maar eens na. NAS servers mogen dan wel goedkopere RAID-opslagservers zijn speciaal voor kleine tot middelgrote bedrijven, maar tegenwoordig is data van een NAS server herstellen net zo complex en moeilijk als van de allerbeste en duurdere producten van bijvoorbeeld EMC, Dell, en HP. De meeste van deze relatief kleine opslagapparaten hebben nu ook de meer geavanceerde functies zoals deduplicatie, ondersteuning voor virtualisatie, de mogelijkheid voor het maken van iSCSI-doelen etc. Hierdoor zijn de data op deze systemen over veel verschillende lagen verdeeld, lagen die stuk voor stuk hersteld en geherstructureerd moeten worden om uiteindelijk tot de ’echte’ databestanden te komen.
Klantcase: QNAP NAS server herstellen
Dat was ook het geval toen een klant van onze Duitse tak onlangs te maken kreeg met een probleem met zijn QNAP NAS server. Het RAID-6-systeem bestond uit 24 harde schijven met elk een capaciteit van 6 TB. Tijdens de installatie waren twee iSCSI LUN’s gecreëerd, het ene met meer dan 40 en het andere met meer dan 60 TB aan data. Elk LUN behoorde tot het iSCSI-doel van één Windows-Server-2012-R2-systeem en was geformatteerd als een NTFS-partitie. Daarnaast was de deduplicatiefunctie van Windows Server 2012 R2 op beide LUN’s toegepast. Toen de NAS server van de klant, de ICT-afdeling van een grote vastgoedgroep, op een dag wat traag liep werd het systeem abrupt uitgezet - zonder het systeem correct af te sluiten. Als gevolg hiervan waren beide LUN’s niet meer toegankelijk, al waren de stationsletters nog wel zichtbaar. En wat nog erger was: er was helemaal geen back-up!
Data analyse
Toen wij werden benaderd om de NAS server te herstellen, liet de analyse zien dat er voor een data recovery stuk voor stuk zes lagen data moesten worden doorgewerkt. Omdat een QNAP NAS server met een Linuxsysteem werkt, moest eerst de QNAP-NAS-RAID-6-laag gereconstrueerd worden om toegang te krijgen tot het Linux-EXT4-bestandssysteem. In dit bestandssysteem konden fragmenten van de ontoegankelijke LUN’s gevonden worden, die opnieuw opgebouwd moesten worden om tot de 64 TB en 44 TB onbewerkte LUNdata te komen. Elk fragment was ongeveer 1 TB groot, en er werden dus meer dan 100 ‘stukjes’ iSCSI met big data onder handen genomen, die moesten worden gestructureerd en in elkaar gezet om beide iSCSI-LUN-bestanden te kunnen heropbouwen.
Deze iSCSI-fragmenten werden oorspronkelijk beheerd door het QNAP-systeem en op verzoek gecombineerd, waardoor het Windows-Server-systeem dacht dat het twee bestaande LUN’s kon aanspreken. Nadat de iSCSI-bestanden blok voor blok tijdelijk naar een SSD waren gekopieerd konden de datarecoveryspecialisten deze iSCSI-LUN-bestanden samenvoegen tot één NTFS-volume. Omdat in Windows Server ook deduplicatie was ingeschakeld, moesten de ingenieurs nog meer met deze zesde, laatste laag werken om uit te zoeken welke gegevens door deze functie beïnvloed waren om zo een voor de klant bruikbaar NTFS-volume te kunnen creëren. Dit NTFS-volume werd toen van de tijdelijke SSD naar een nieuw RAID-opslagsysteem gekopieerd, dat de klant makkelijk kon aansluiten op zijn netwerk om de voorheen verloren data weer te kunnen opvragen.
Niet goed geïnstalleerd
Zelfs met onze uiterst gespecialiseerde recoverytools duurde het herstellen van de NAS server en kopiëren van zoveel data op een nieuwe back-up uiteindelijk nog meerdere weken. De afsluitende analyse van deze big data recovery case door onze recovery ingenieurs liet duidelijk zien dat de NAS server vanaf het begin niet goed was geïnstalleerd, en dit was wellicht de reden voor het mankement. Zoals wel is gebleken nam de data recovery veel tijd in beslag vanwege de grote hoeveelheid data op de server. Hierom is het juist zo belangrijk een NAS server gelijk goed te installeren voordat er data op worden opgeslagen. Daarnaast is het ook verstandig goed voorbereid te zijn op eventuele dataverliezen zoals deze.
Hoe kan je een NAS server herstel voorkomen?
Deze case liet ook zien dat hoewel dit NAS-systeem veel geavanceerde functies had, ze niet allemaal hadden moeten worden ingezet omdat kleine tot middelgrote servers zoals deze niet zo foutloos zijn als de duurdere en betere servers. Om dan de deduplicatiefunctie te gebruiken is geen goed idee, omdat het een NAS server herstellen een stuk moeilijker maakt. Omdat de harde schijven voor zo’n systeem de laatste jaren goedkoop geworden zijn is het beter om extra schijven aan te schaffen, in plaats van het onnodig complexer maken van de gegevensstructuur. Want hiermee voorkom je dat zelfs datarecovery specialisten je op een dag niet meer voor een redelijke prijs en/of binnen een aanvaardbaar tijdsbestek kunt vragen om een NAS server te herstellen.
