Daten-GAU bei AMBROSIA60

• Backup, Backup, Datensicherung!

Eigentlich hätte ich es besser wissen müssen. Predige ich doch selbst immer wieder: Backup, Backup und nochmals Backup.
Das trifft bei mir auch auf alle - na ja - fast alle Serversysteme zu.

Die Ausnahme bildete bislang der Virtual Server unter VM, da ich für die Datenmengen bislang noch kein geeignetes Datensicherungskonzept entwickelt hatte.

• Entwicklungssystem

Den VMServer hatte ich bereits vor mehr als einem Jahr aufgesetzt.
Bislang war das immer ein Entwicklungsrechner, auf dem ich PHP Entwicklungen für die Produktiv Website durchführte und austestete.
Im Zusammenhang mit dem Fido-History-Project kam ich in die Verlegenheit, die MySQL4 Datenbank auf MySQL5 upzugraden.
Also duplizierte ich kurzerhand das VM-Image des Testservers zu einem neuen Server, migrierte MySQL4 auf MySQL5. Das Fido-History-Project fing dann bisschen an einzuschlafen, bis Ende 2007. Zuvor, im September aber, gab es für den MySQL5 Server ein neues Projekt.

• FidoBase MySQL Messagebase Projekt

Das Fidobase Projekt - eine Entwicklung aus einem Tosser Projekt, das sich zu einem Projekt MySQL Messagebase für Fidonet Mails wandelte.
Der Hintergrund ist eine über zig Serversysteme verteilte MySQL Datenbank die repliziert wird. Die zu erwartenden Datenmengen für ein Mailarchiv lagen zu diesem Zeitpunkt noch bei ca. 2 Gbyte.
Das in etwa war auch der Zeitpunkt zu dem ich die neue, grosse 500er Gbyte Platte einbaute, da die VMimages die Systemplatte zu sprengen drohten.
Nachdem das Projekt im Laufe des Septembers/Oktobers 2007 dann in den Produktivstatus überging, war mit einem Schlag der bislang als Entwicklungsrechner deklarierte Server ein Produktivsystem.

• Fido-History-Project DB Projekt

Gegen Ende des Jahres 2007 meldete sich ein Fidoianer ab, mit der Bitte für sein Netz vielleicht eine Statistik der Nodes/Points ihm zukommen zu lassen. Das belebte das Projekt Fido-History-Project to DB neu. Die bisherigen Perl-Sources die mir vorlagen konnte ich für die Erweiterungen, die ich durchführen wollte nicht heranziehen (dazu kenne ich mich in Perl zu wenig aus).

Also begann ich mit der Portierung des Perlscripts für den Import von Nodelist-Informationen in die MySQL5 Datenbank auf PHP. Weihnachten 2007 hing ich an Problemen zur CRC16 Kalkulation, mit der ich nicht so recht weiterkam. Bis mir dann im Januar 2008 irgendwann die Lösung des Problems dämmerte (Carriage Return + Line Feeds werden bei der MakeNL CRC16 Kalkulation mit berücksichtigt, soweit war mir das klar, was mir nur nicht klar war, dass im Script an der Stelle schon kein Carriage Return/Line Feed mehr existierte ....)
Nachdem ich noch eine ganze Reihe weiterer Hürden genommen hatte, lief ab Ende Januar der Import der Nodelist Daten in die MySQL5 Datenbank an.

Die Daten von 1984-1994 waren bereits in die DB importiert, als am Samstag die Platte ausfiel. Da ich bis zum Schluss an den Sources gearbeitet hatte, hatte ich auch keine Kopie der Sourcen auf einem anderen Rechner.
Eine Kopie des MySQL5 Servers hatte ich auch nicht.

• Materielle und Imaterielle Werte

Auf die Platte, die mich so um die 139 Euro (das für viele in der Zwischenzeit schon ziemlich, reichlich viel Geld ist) gekostet hatte, gibt es 2 Jahre Garantie. Nur nutzt mir jetzt die Garantie nicht sonderlich viel, wenn ich die Daten nicht von der Platte runterbekomme.

• Professionelle Datenrettung?

Ein Bekannter, mit dem ich mich über das Problem unterhielt, erzählte mir, dass eine professionelle Datenrettungsfirma Ende 2007 gerade ein Angebot gemacht hatte für 1400 Euro Daten wieder herzustellen.
Sollte sich der Preis tatsächlich in der Preisklasse bewegen, dann könnte das sehr wohl eine Alternative dafür sein, statt sich wieder 2 Monate oder länger wieder hinzusetzen und die Sourcen neu zu programmieren. Wenn man die Arbeit gegenrechnet, die bislang in dem Server gesteckt hat, so kann das auf ein halbes Jahr hochgerechnet werden. Dann sind 1400 Euro im Vergleich recht wenig (ein Jahresgehalt von 2800 Euro liegt weit unter der Armutsgrenze). Sieht man dagegen den Aufwand, der betrieben werden müsste, um an die Daten wieder heranzukommen - die Platte müsste sicherlich unter Reinraumbedingungen geöffnet werden um an die Innereien heranzukommen, um beispielsweise den Schrittmotor auszubauen - dann relativiert sich der Preis schon wieder.

• Reparatur oder Austausch?

Als ich die Platte heute beim Laden vorbeibrachte, hab ich die mit dem Vermerk "Reperatur vor Austausch" abgegeben. Man nahm mir aber schon die Hoffnung darauf. Schon an die 100 Leute vor mir, hätten keinen Erfolg damit gehabt. Aber, ich versuchs trotzdem ...

• Neuaufbau

Mit 2 wesentlich kleineren Platten, die als Mirror laufen, habe ich das System heute prinzipiell erst einmal wieder zum Leben erweckt.
Momentan laufen Restore Versuche damit ich eine Ausgangsbasis für die Entwicklungsumgebung und den MySQL5 Server wieder aufbauen kann.

to be continued ....

• Update [14.2.08]

Seit letzter Nacht habe ich nun wieder 2 Basis VM-Images zur Installation von Test Client Rechnern und Test Server Maschinen, so wie ich sie vor dem Daten-GAU bereits auf dem VM-Host laufen gehabt hatte.

Mit diesen Basis Images ist es mir nun möglich die verlorenen Entwicklungsprojekte successive wieder neu aufzubauen.

- CDP Node / CDP Client Testumgebung
- Fidobase SQL Messagebase unter MySQL5
- Fidohist SQL Fido-History-Project Import

Als nächstes kommt jetzt erst einmal die MySQL4 to MySQL5 Migration. Das Script dass ich mir bei meiner ersten MySQL5 Migration erstellt hatte ist mit dem Daten-GAU auch verloren gegangen, so dass ich das Rad mal wieder für mich neu erfinden darf. Das Dokument mit dem Verweis auf den verloren gegangenen Server habe ich noch auf dem Desktop meines Notebooks finden können.

• Update [18.2.08]

Das Projekt - Fidobase SQL Messagebase unter MySQL5 -
ist bis zum Stand Fr. 15.2.08 wieder hergestellt. Der Updatemechanismus seitens Dirk ist allerdings noch nicht wieder gestartet.
Zunächst vereitelte noch ein Broken Archiv den Import. Nachdem ich den Dump von Dirk ein zweites mal heruntergeladen hatte, klappte dann der Import mit der Syntax:
mysql --user=xxx --host=yyy -p fidobase < fidobase
(Danke nochmal an Kees für den Tipp, ich habe es zuvor immer mit mysqlimport versucht ...)

Mit dem Projekt - Fidohist SQL Fido-History-Project Import -
habe ich zunächst versucht die "alte" Perl Umgebung wieder herzustellen, um das Orginal Perl-Script laufen lassen zu können. Das NLARCHIVE Script benötigt eine Digest::CRC Funktion, die ich seinerzeit via CPAN in die Perl Installation eingebunden hatte.
Nun aber, bekomme ich keine Variante von Perl mit einer Funktion Digest::CRC zum Laufen :(

Alle Versuche irgendwelche Bundles (Win32, libnet32, CPAN) zu aktuallisieren oder Module hinzuzufügen (Digest::CRC) schlugen fehl. Die Umgebung, die ich bereits vor ca. 2 Jahren für das NLARCHIV Script gebastelt hatte bekomme ich nicht mehr hin :(

Ein Update mit dem Perl Paket ActivePerl-5.8.8.822-MSWin32-x86-280952 lieferte ebenso wenig eine für das NLARCHIV Script lauffähige Umgebung wie der Reset des kompletten Perl/Apache2 Pakets (Apache_2.0.54_Perl_5.8.7_PHP_4.3.11) auf eine frühere Version. Sämtliche CPAN und PPM Updates schlagen fehl :(´

Nachdem ich nun den halben Samstag und den ganzen Sonntag über dem Problem verbraten habe, werde ich Perl entgültig in die Tonne treten. :(

Meinen Entschluss, den ich bereits vor Verlust der Platte hatte, Perl Scripte in der Webumgebung zu eliminieren, werde ich nun nach diesen Erlebnissen vollends durchziehen.

Der Vollständigkeit halber:
CPAN Errors (egal was für ein Paket):
a)
Win32 v0.28 needed. Version 0.24 is installed.
oder
b)
NMAKE : fatal error U1077: 'I:\Apache\Perl\bin\perl.exe' : return code '0xff'
Stop.
i:\mvs\VC98\bin\nmake.exe test -- NOT OK
make had returned bad status, install seems impossible
oder
c)
The module libwin32 isn't available on CPAN.
Bundle summary: The following items in bundle Bundle::libwin32 had installation problems:
Win32 Win32API::File Win32API::Registry libwin32

PPM Error:
Can't locate object method "rvalidate" via package "PPM::XML::PPD::PROVIDE" at I:/Apache/Perl/site/lib/PPM/XML/ValidatingElement.pm line 38, <> line 3.

Alle Versuche dann das NLARCHIVE Script laufen zu lassen enden in der Fehlermeldung:
Can't locate Digest/CRC.pm in @INC (@INC contains: I:/Apache/Perl/site/lib
I:/Apache/Perl/lib .) at nlimport.pl line 9.
BEGIN failed--compilation aborted at nlimport.pl line 9.

Auf der Suche nach Lösungen habe ich zwar im Internet auch immer wieder die gleichen Fragen mit den gleichen Fehlermeldungen finden können, aber niemals irgendwelche Lösungen zu diesen Problemen :(
Ich habe es jetzt aufgegeben da weiter zu forschen.

• Update [22.2.08]

Das Projekt - Fidohist SQL Fido-History-Project Import -
Perl to PHP port bin ich jetzt am Stand 6. Januar angekommen. Es fehlen jetzt noch so ungefähr 3 Wochen Entwicklung um den Import der Nodelisten erneut zu starten.

Auf einen Teil der Sources konnte ich vom Stand 4. Dez 07 zurückgreifen. Zum anderen hatte ich in der Version 1 vor dem Plattencrash ziemlich lange an einer CRC16 Routine festgesessen. Hier konnte ich auf Kopien des Sourcecodes aus Mails zurückgreifen die ich damals im Zusammenhang mit einer Problemlösung versandt hatte.

• Update [26.2.08]

Projekt - Fidohist SQL Fido-History-Project Import -
An sich eine simple Funktion - extrahiere aus Sysopnamensfeldern den Nachnamen - entwickelt sich zu einem Fass ohne Boden.
An die 100 Sonderfälle und Ausnahmen die es zu berücksichtigen gilt erschweren das Vorwärtskommen in diesem Projekt. Seit nunmehr 4 Tagen bin ich am Analysieren und Debuggen.

• Update [28.2.08]

Mittwoch Abend erhielt ich eine SMS:
Bitte kommen Sie mit der Orginalrechnung und dem Reperaturauftrag bei uns vorbei. Sie erhalten ein Ersatzgerät.
Donnerstag Mittag - ich erhielt eine Ersatzplatte. Die Daten der alten Platte erhielt ich nicht. Soviel zur Möglichkeit Reperatur oder Ersatz .... :(

• Update [2.3.08]

Fido-History-Project to DB NDL2DB (former NLARCHIVE) PHP port scripts rewritten.
Nach abschliessenden Tests läuft nun der Import der Nodelisten aus dem Fido-History-Projekt Archiv an.
Damit ist nun das zweite von drei Projekten wieder auf dem Stand wie zum Zeitpunkt des Daten-Gaus vom 9.2.08.