Neben Herausforderungen ganz anderer Art, die hier nicht zum Gegenstand des öffentlichen Interesses gemacht werden, wurde in diesen Tagen auch eine schwerwiegende Entscheidung betreffend der Nutzung mit diesem hier zur Anwendung gebrachten Redaktionssystem SPIP gemacht.

Eins seiner Besonderheiten - und Vorteile - war und ist es, neben der letztendlich veröffentlichten Artikelseite, immer auch alle Schritte zu dokumentieren, die gegangen wurden, bis es zu dieser Publikation kommt.

Wer einmal in einem Archiv sich mit der Entstehungsgeschichte eines literarischen wie auch wissenschaftlichen Dokuments beschäftigt hat, weiss, welch einen Wert es hat, nachverfolgen zu können, wie es Schritt um Schritt gewachsen ist, immer wieder neuen Korrekturen unterworfen, um dann dennoch in vielen Fällen gar nicht bis zu einer Veröffentlichung bereitgestellt wurde.

In der - für die NutzerInnen dieser Seite nicht sichtbaren - Überarbeitung gehören immer wieder neue Updates und Anpassungen, beispielsweise an die jeweils zu aktualisierende PHP-Version.

Um Vorgänge wie diese durchzuführen, wird auf dem "managed server" immer zuvor eine Datensicherung [1] und eine Arbeitskopie erstellt, "dev.daybyday.press".

Inzwischen aber haben wir das Problem, die inzwischen riesigen Tabellen für Versionierung und Besucherstatistiken aus mehr als einem Jahrzehnt Redaktionstätigkeit noch problemlos sicher zu können. Mit dieser Meldung bricht auf dem Rootserver das SPIP-Backup ab:

Erreur fatale lors de la copie de la table spip_visites_articles

Es gibt auch in einem solchen Falle sogenannte workarounds, indem jede einzelne der insgesamt 70 Tabellen, die SPIP und seine Plugins für DayByDay verwendet, einzeln mit Adminer exportiert und ebenso Schritt für Schritt in die Kopie der Website importiert wird.

Die Stellungnahme des Admin ist an diesem Punkt eindeutig:

Das habe ich getan, nachdem die Arbeit an der SQL-Kommandozeile ebenfalls keinen zuverlässigen Import der im SQL-Format gespeicherten Daten ermöglicht hat. Die üblichen Fehlerquellen wie falsche Zeichensätze o.ä. habe ich berücksichtigt, aber es treiben sich scheinbar in den vielen Daten einige Zeichenketten herum, die in Kombination mit der schieren Anzahl der Datensätze ein routiniertes Sichern und Zurückspielen ohne zusätzliche Werkzeuge, die gefunden und eingerichtet oder für diesen Zweck programmiert werden müssten, zuverlässig verhindern.

Was tun?

Die Löschung aller Daten, die letztlich für den täglichen Betrieb der Website www.daybyday.press nicht benötigt werden.

Oder ein langwieriges händisches Sichern und Zurückspielen der Daten, ein händisches Anlegen von Backups im MySQL-Format.

Oder die Anmietung eines neuen, wesentlich leistungsfähigeren Servers, was die Kosten für dessen Betrieb um mindestens 100 Euro pro Monat erhöhen würde.

Die Antwort:

Die dritte Alternative wäre Peanuts, wenn es sich hier nicht um ein ganz und gar nicht-kommerzielles Projekt handeln würde. Die Zweite verbietet sich erst recht aufgrund des damit verbundenen zeitlichen Mehraufwands. Was also bleibt, ist die Löschung aller früheren Versionierungsaufzeichnungsdaten und aller alten Zugriffszahlen.

Das ist bitter, aber wahr(scheinlich die einzige Lösung).