FHEMwiki Datenverlust

Zrrronggg! · 02 Mai 2013, 22:28:15

Okay, ich habe sehr schlechte Nachrichten.

Ich habe eben mit dem Admin vom Wiki telefoniert.

Das Wiki lag (mit einigen anderen Wikis) auf einem Server bei einem der einschlägigen Hoster und zwar auf einem Raid 1, also gespiegelten Platten.

vor 2 Tagen sind
1. Beide Platten innerhalb weniger Stunden kaputt gegangen.
2. Das BackUp war korrupt (vermutlich unbemerkt schon länger)

D.H. das Wiki ist ... weg.

Was noch vorhanden ist, ist
a) alle Uploads (Bilder etc.)
b) ein riesen Binärfile das mal die Datenbank mehrerer Wikis war aber jetzt korrupt ist.

Es besteht eine kleine Resthoffnung, das der Admin das Binärfile reparieren kann um so wenigstens die Daten extraieren zu können. Ein weitere Chance mag sein, sich die Platten zusenden zu lassen und die noch mal eingehender zu untersuchen. Zusammengenommen gibt das eine Restchance von vielleicht 10% dass das Wiki noch mal erweckt werden kann.

Weitaus grösser ist die Chance, dass das wiki in der jetzigen Form hinüber ist.
Betroffen von diesem Desaster ist nicht nur das FHEM Wiki sondern auch einige andere Wikis und der Admin hat mehr oder weniger schlaflose Nächte und kein gute Zeit to say the least.
Am Telefon klang er wirklich bedrückt , ja sogar niedergeschlagen.

Ich schlage vor das jeder versucht, seine eingestellten Dinge aus dem Netz zu kratzen, aus'm Googel-Cache oder aus Wayback solange es noch geht, damit wir perspektivisch was neues Aufbauen können.

Zrrronggg! · 02 Mai 2013, 23:02:03

Eventuell kann jemand dieses Tool

http://warrick.cs.odu.edu//new.php

installieren und damit versuchen den Content aus web.archive.org zu holen.

Ich ziehe das Webarchiv gerade mit einem Sucker ab, was aber wegen des inneren Aufbaus des Webarchivs ein ziemlich unübersichtliches Ergebnis bringen wird.
Trotzdem besser als nix. Stand ist Januar diesen Jahres.

PeMue · 03 Mai 2013, 06:03:09

Hallo zusammen,

habe mir für mich persönlich ziemlich viele Informationen vom Wiki als PDF runtergezogen (FritzBox, EM1000, 1-wire, Max, Photovoltaik, teilweise Raspberry Pi), die ich zur Verfügung stellen könnte, Zeitraum ca. Dezember bis jetzt. Text müsste extrahierbar sein, Bilder sind ja scheinbar noch da.

Gruß PeMue

justme1968 · 03 Mai 2013, 09:39:56

leider kann nicht anbieten ein eventuelles neues wiki zu hosten...

ich kann aber anbieten backups in mehreren generationen auf zwei gespiegelten netapps und zusätzlich in einer generation auf zwei bzw. drei gespiegelten diskstaions die offline stehen aufzubewaren.

gruss
andre

fritz · 03 Mai 2013, 10:31:44

Zitat von: justme1968 schrieb am Fr, 03 Mai 2013 09:39leider kann nicht anbieten ein eventuelles neues wiki zu hosten...

Ich gehe mal davon aus, dass hinter den Kulissen bereits ein neues Wiki vorbereitet wird, man sollte nur nicht jeden von Anfang an daranlassen. Falls nicht, Platz für ein temporäres Wiki hätte ich noch auf meinem Webspace - es könnte nur keine Dauerlösung sein (zu wenig Platz und Zeit für die Administration).

<F>

Zrrronggg! · 03 Mai 2013, 16:32:47

ZitatIch gehe mal davon aus, dass hinter den Kulissen bereits ein neues Wiki vorbereitet wird

Stand jetzt noch nicht.

Wir haben aktuelle dank der Mitwirkung diverser Personen sowohl den Google Cache mehroder weniger aller Artikel als auch den Bestand aus der Waybackmachine aka webarchive.org.

Die hochgeladenen Bilder haben wir auch.

Daraus wieder ein Wiki zu basteln ist einiges an Arbeit, aber nicht unmöglich. Ich werde mit dem Betreiber des Wikis drüber reden, wie wir weiter vorgehen, also z.b. ob er bereit ist das auch in Zukunft zu hosten oder jemand anders die Domain übernimmt und ein Wiki hostet. Dann können wir uns überlegen, wie wir die Daten da wieder rein bekommen.

Kurz:
Die gute Nachricht: Das meiste an Daten, also Texten und Bildern ist da.
Die schlechte Nachricht: Das ist nur die halbe Miete und es steht noch echte Arbeit an.

Ralph · 03 Mai 2013, 19:06:35

Ich wüsste gern, wer dieser Hoster war, damit ich nicht aus Versehen dort etwas ablege.
Möchte mir jemand diesen Hoster eindringlich empfehlen ?

Zrrronggg! · 03 Mai 2013, 19:21:57

Ich weiss, wer der Hoster war, aber ich weiss nicht, ob es tatsächlich (alleine) die Schuld des Hosters war. Daher werde ich das jetzt hier nicht sagen, obwohl es eine unserer Konkurenten war.

Zrrronggg! · 03 Mai 2013, 20:13:37

Achtung - an alle die helfen wollen:

- den Webarchive -Bestand haben wir (3x)
- den Google Cache haben wir (2x)
- die hochgeladnen Bilder haben wir

D.H. der blanke Datenbestand ist vorhanden, Stand einige Wochen bzw einige Tage alt.

Ihr braucht das also nicht noch mal machen.

Puschel74 · 03 Mai 2013, 20:30:08

Hallo,

leider, oder nun zum Glück im Unglück, habe ich (noch) keinen Wiki-Artikel verfasst.
Aber gut das der Datenbestand noch vorhanden ist - wenn nun auch immer noch jede Menge Arbeit ansteht.

Allerdings könnte vllt. ein Admin die 2 Beiträge zusammen legen wenn das geht?
Also diesen hier mit dem Link - wenn das geht.
2 Beiträge zum selben Thema brauchen wir wirklich nicht - zumal ich der Meinung bin das es besser ist alles in einem Beitrag
zu konzentrieren. Erst recht wegen der vielen Arbeit die noch ansteht.
Wenn das zusammen legen nicht gehen sollte könnte ja einer der beiden Beiträge mit einem Verweis auf den anderen geschlossen werden.

Grüße

Edith: Ich mach jetzt aber keine Umfrage deswegen ;-)

Zrrronggg! · 04 Mai 2013, 18:17:21

Okay, hier ist der aktuelle Stand:

Das Wiki läuft (ohne Daten natürlich) . Arno ist bereit es weiter zu hosten.

Wir haben uns jetzt entschlossen, nicht auf die serh geringe Chance zu warten, dass von den Platten noch was zu holen ist, sondern angesichts der vielen Mithelfer, die die Daten aus Google geholt haben, das Wki neu zu befüllen.

Alle hochgeladenen Bilder (immerhin über 800 Stück) sind schon wieder alle im Wiki .

Ich sehe mich jetzt schon mal ein bisschen um, und kopiere schon mal ein paar Daten rein zum Testen wie das geht.

Wer Useraccounts braucht, um beim Befüllen mitzuhelfen mailt bitte an
soulman@fhemwiki.de (soulman@fhemwiki.de)

Arnio hat auch versprochen, das Thema BackUp nochmal anders anzugehen, z.b. durch ein Box-Plug In oder sowas.

Zrrronggg! · 06 Mai 2013, 20:31:56

Aktueller Stand:

Wir versuchen, die von vielen hier bereitgestellten Google-Cache-Daten per Script ins Wiki zu laden.
das Script muss dabei die in HTML vorliegenden Seiten so aufbereiten, dass sie wieder dem Wikiformat entsprechen.
Hoffentlich bekommen wir auch die Verlinkung wieder hin, das würde ne Menge Arbeit sparen.
Ich selbst hatte diese Möglichkeit nach 2-3 Parsingversuchen als zu schwierig aufgegeben aber es gibt ja zum Glück Leute, die in Scripting bisschen fitter sind als ich.

Wir werden aber sicher keine Ergebnisse vor ca. Mittwoch haben.

So oder so: Die Daten liegen vor, es geht im Moment nur da drum wie wir die mit am wenigsten Arbeit wieder in Wiki bekommen.

Drückt mal die Daumen.

UliM · 06 Mai 2013, 22:53:14

Zitat von: Puschel74 schrieb am Fr, 03 Mai 2013 20:30Wenn das zusammen legen nicht gehen sollte könnte ja einer der beiden Beiträge mit einem Verweis auf den anderen geschlossen werden.

Done - anderer Fed geschlossen, hier geht's weiter.
Viel Erfolg,
Uli

fritz · 07 Mai 2013, 00:17:03

Zitat von: Zrrronggg! schrieb am Mo, 06 Mai 2013 20:31Ich selbst hatte diese Möglichkeit nach 2-3 Parsingversuchen als zu schwierig aufgegeben aber es gibt ja zum Glück Leute, die in Scripting bisschen fitter sind als ich.

Ich denke, es ist nicht die beste Idee, aus den HTML-Links direkt Wiki-Links zu rekonstruieren (na gut, ich weiss nicht so genau, wie Wiki-Links aussehen, aber sie müssen ja anders sein, da man sie auch auf nicht existierende Einträge anlegen kann). Ich würde so vorgehen: Bei der Aufbereitung der HTML-Seiten kennzeichne ich nur im Text, wo ein Link ist - und vielleicht noch, auf welchen Begriff er zeigt (das muss ja nicht identisch mit dem linkenden Text sein) - durch ein spezielles Konstrukt, z.B. §L L§ oder ähnliches, was nicht so häufig vorkommt. Wenn man das nicht hinkriegt, dann den Link unverändert übernehmen, vielleicht "deaktivieren", indem man aus "<a href..." z.B. "<x href..." macht und aus "/a" dann "/x". (Nach dem Motto: wir lassen uns ein x für ein a vormachen :-)
Wenn dann alle Texte aufbereitet und im Wiki sind, würde ich einige Links manuell anlegen, um "echte Links" im Wiki zu haben - und dann das ganze Wiki exportieren. Das Exportergebnis sollte, wenn ich recht erinnere, eine XML-Datei sein. Die kann man analysieren (wie sehen meine manuell angelegten Links aus?) und entsprechend manipulieren. Perl und reguläre Ausdrücke dürften dabei gute Dienste leisten. Anschließend das Ergebnis wieder in ein/das Wiki importieren und prüfen (deshalb würde ich erst mal ein "Testwiki" nehmen), und bei erfolgreicher Prüfung freischalten.

Würd' ich übernehmen können, komme aber nicht vor Mittwoch dazu. Aber vielleicht könnt ihr schon mal irgendwo einen Teilexport ablegen, damit man mal sieht, wie das aussieht (habe ein paar längere Zugfahrten vor mir, die lassen sich prima zu so etwas nutzen)

<F>

Zrrronggg! · 07 Mai 2013, 02:44:00

Die Links sind echt nicht das Problem, ich habe mich da unscharf ausgedrückt.
Es geht natürlich da drum, die HTML Eigenheiten zu parsen und zu ersetzen.
Also aus HTML <H2> ... </H2> das Wikiequvalent "== ... ==" zu machen und aus
"<a href... ...</a> das Wikiequivalent [[...]] etc.
Das ist aber der EINFACHE Teil:
Ob ein Link intern ist oder nicht kann man im HTML Code gut erkennen, da das Wiki da lustigerweise absolute Links bei der Auslieferung draus macht. D.h. auch in internes Links sind in der HTML Source so aus:

Code Auswählen

http://www.fhemwiki.de/wiki/Kategorie:HOWTOS

Das lässt sich also schon parsen, man muss nur "http://www.fhemwiki.de/wiki/" ersetzen durch
"[[" und das Ende des Strings vor Space dann mit "]]" ergänzen. Der Teil ist also lustigerweise gar nicht mal so anspruchsvoll, ebenso wie die Überschriften, die man schon mit einem simplen Suchen und Ersetzen fixen könnte. Ich habe da schon schöne Erfolge mit einem Texteditor erzielen können.

Zumindest für mich war das grössere Problem, die durch das Wiki automatisch angelegten Inhaltsverzeichnisse eines Artikels zu erkennen und zu ENTFERNEN, das das Wiki dieses Verzeichnis ja aus dem Überschriften selber generiert. Ebenso sind Tabellen schwierig zu entzerren.

Das ist ja gerade das komplizierte. ICH könnte das nicht auf die Schnelle, jedenfalls nicht ohne mich da eher Wochen als Tage reinzuknien. Das liegt auch daran, dass ich selber das letzte mal vor 20 Jahren richtig programmiert habe und ich gerade noch ein bisschen AppleScript und die 3 Brocken Perl die man bei FHEM so braucht drauf habe. Ich bräuchte schon alleine paar Tage um bei Applescript wieder up to speed zu kommen in den Feinheiten der Stringmanipulationen.
Aber andere haben sich schon erboten und sind wohl verhalten optimistisch. Ziel ist, morgen oder übermorgen einen Testlauf zu machen und das Ergebnis mal anzusehen. Zuletzt muss man sich auch um die WikiAPI kümmern, oder das direkt in die Datenbank schreiben, denn man will auch 450 an sich korrekte Textfiles nicht per Hand da reinmachen. Auch da gibt's wohl schon Ideen.

Ich habe keine Vorstellung wie das Ergebnis aussehen wird. Damit du z.b. nicht doppelt arbeitest, können wir das doch einfach mal abwarten. Wenn nicht: Jede Hilfe willkommen.

Und letztlich sind es auch "nur" 450 Artikel, Kleinigkeiten kann man eventuell auch manuell oder mit einem Wikibot fixen.

Kurzum: Gerade die Links machen mir eigentlich die wenigsten Sorgen, der ganze andere Clutter der wieder raus muss ist womöglich mehr Aufwand.