Damit die neugierigen Nasen
nicht dumm sterben müssen:
Es ist vollbracht !
Hat sich etwas hingezogen, weil sich noch ein paar Komplikationen und Behinderungen dazugesellten, und sowohl der TE als auch ich zeitweise was anderes zu tun hatten. Aus Datenschutzgründen wurde die Kommunikation zur Behebung mittels ca 500 PM's abgewickelt.
Die 4 Platten im RAID5, der ausgefallen war am Controller A, wurden nach dem Hoppala in willkürliche Reihenfolge an Controller B gesteckt, und der Array dort neu initialisiert, partitioniert und Quick-formatiert, bevor klar war, dass das Restore der Sicherungsdateien nicht funktioniert und die Sache zum Super-GAU für die unersetzlichen und hochwichtigen Daten wurde.
Erst wurden sicherheitshalber alle Platten geklont, und ich hab mich über die Klone hergemacht und gerätselt - bis sich herausgestellt hat, dass das Klonprogramm nichts auf die Klonplatten geschrieben hatte und da immer noch alter Scheiß von irgendwann früher draufstand. Auf einer der 4 Originalplatten zeigte sich ein Defekt - der Grund, warum der Controller A früher gezickt hatte? Ein Großteil des Plattenbereiches konnte nichtmal mehr mit ddrescue rausgelesen werden.
Also weiter mit nur 3 Platten, was ein RAID-Cntroller kann, kann Ernst auch...
Irgendwann später stellte sich dann heraus, dass Controller B mit anderer Sektorsize als Controller A am Array arbeitete, und früher ein GPT Datenträger(alle Hinweise darauf fein säuberlich gelöscht), danach aber ein Basisdatenträger drauf war. Nach diesen Erkenntnissen war es nur noch ein kleiner Schritt zu richtigen alten Reihenfolge(die Info in den Metadaten auf den HDDs war durch den neuen Controller ebenfalls vollständig zerstört).
Mit der richtigen Reihenfolge dann im üblichen Hokuspokus den RAID neu definiert, und die defekte Platte rausgerissen, kam GetDataBack zum Einsatz. Rauskopieren, was zu retten ist - 1,36 Mio Dateien, aber eine riesige wichtige Datenbank war nicht dabei.
Also ab ins Eingemachte, MFT inspiziert ... dort schien alles OK. Aus den MFT-Daten die genaue Lage der Dateien, und aus den Erkenntnissen, wie die Platten nachher bei der Zerstörung gereiht waren, alle zerstörten Sektoren rausgerechnet, von der Datenbank war keiner in den 340 Fragmenten auf der HDD dabei. Resümee: GetDataBack kann mit solch speziell angeordneten MFT-Einträgen nicht umgehen, eindeutig ein Programmierfehler im GDB.
Nachdem klar war, wo genau die Zerstörungen stattgefunden hatten, die Partition reaktiviert und die Datenbank auf normalem Wege rauskopiert - oh Wunder, sie ist intakt.
Seit Beginn der Woche ist das System wieder up und läuft wie zuvor ohne Probleme; alle Dateien gerettet, davon aber alle zerstörten (ca. 170) nicht so wichtige Dateien mit insgesamt 128MB Schrott identifiziert und wegen Nichtverwendbarkeit ausgesondert. Macht eine Wiederherstellungsrate von 99,987% - mehr ginge beim besten Willen nicht.
Unmittelbar nach dem ersten misslungenen Klonversuch wurden die Originalplatten für eine Wiederherstellungsprognose auch einem Datenrettungsunternehmen zur Verfügung gestellt. Deren Remoteanalyse scheiterte offenbar an der 4. defekten Platte, worauf die Originalplatten (nach 2. erfolgreichem Klonversuch) dem Unternehmen zugesandt wurden.
Das Ergebnis war eine Liste der rettbaren Dateien, welche sich auf dem RAID befanden, ohne Hinweise darauf, welche davon zerstört sein könnten oder tatsächlich sind.
Das Angebot einer HDD mit den geretteten Dateien lag im 5-stelligen Euro Bereich und unterschied sich nicht von dem bis zu diesem Zeitpunkt schon per GDB(Lizenz: 100 €) extrahiertem Ergebnis.
Die verbleibenden intakten 3 Originalplatten in richtiger Reihenfolge angeordnet, hätten selbst an jedem einfachen Onboard-Controller ein voll funktionsfähiges, aber degraded Array mit allen Dateien(auch der 170 zerstörten Inhalts) ergeben, wie sich dann nach vollständiger Zerstörungsanalyse ergab(aus Sicherheitsgründen erst am Schluss erfolgreich in die Praxis umgesetzt, um willkürliche Selbstzerstörungen durch ein möglicherweise beschädigtes Dateisystem zu vermeiden) ...
Dank dieses etwas anspruchsvolleren (und damit unterhaltsameren) Problemes konnte ich meine Methoden und Werkzeuge zur Rettung von RAIDs wieder mal kräftig verbessern.
Die Moral von der Geschicht: Es helfen selbst die ausgeklügeltsten Backup-Strategien nichts, wenn man deren Funktion nicht in unangekündigten Notfallsübungen verifiziert.
