Mal wieder Kunden retten

Veröffentlicht am:

Ich bekomme ein Ticket. Auf der Webseite des Kunden wird der Text eines anderen Unternehmens angezeigt. Wie kann das sein? Ich sehe im Webspace eine Datenbank-Datei und sehe Anzeichen dafür, dass ein Kollege bereits auf der Instanz aktiv war. Die Daten passen zusammen.

Ich lese im Ticket weiter, dass da bereits ein Kollege dran war und einen Datenbank-Import gemacht hat und seit dem ist das so. „Dann wende dich bitte an Kollege X. Der ist doch im Thema drin und hat alle erforderlichen Infos“. Das Ticket kommt postwendend zurück, weil Kollege X im Urlaub ist.

Ich kontaktiere den Kunden, um mir von dort die fehlenden Informationen zu holen. Das ist gar nicht so leicht, weil der Kunde mir alles erzählt, nur nicht meine Fragen beantwortet. Ich mache den Job ja schon länger und stelle daher sehr geschlossene und direkte Fragen. Manche Fragen sind sogar nur mit Nein oder Ja zu beantworten. Statt der gewünschten Informationen gibt es immer wieder die Geschichte dazu, warum er denn zur Telekom gewechselt ist. Lob auf den Service. Preis ist doch günstig und dann hat man ja auch alles aus einer Hand.

Gewechselt? Ich stelle ihm die Frage, ob die Seite denn bei uns überhaupt schonmal funktioniert hätte. Er antwortet damit, dass er ja ein Backup von jetzt und noch eines vom März hat. Vielleicht könnten wir das ja versuchen.

Ich ändere die Taktik und lass ihn labern. Aus den 10 Minuten Redefluss kann ich dann doch tatsächlich die drei für mich relevanten Informationen ziehen:

  • Die Seite hat beim alten Anbieter funktioniert, bei uns noch nie
  • Der „Webdesigner“ hat versucht, ein mit „All-in-One WP Migration and Backup“ erstelltes Backup hochzuladen und ist daran gescheitert. Deswegen wurde der Hosting-Support kontaktiert.
  • Auf den alten Anbieter gibt es keinen Zugriff mehr.

Ich beende das Gespräch und schau ins Log. Tatsächlich ist die Backupdatei 700 MB groß und laut Log bricht der Upload ab, weil nicht genug Speicher zur Verfügung steht. Die üblichen Konfigurationen um den Upload zu ermöglichen wollen nicht funktionieren. Eine Möglichkeit, dieses dicke Backup-Paket lokal auseinander zu nehmen, hab ich nicht gefunden.

Verdammt. Das alles ist weder mein Job noch meine Aufgabe. Ich hab hier nur den richtigen Absprung verpasst. Denn eigentlich sollte ich ja rausfinden wie die falschen Inhalte dahinkommen, und das war einfach der Kollege X der etwas versprochen hat und das nicht halten konnte. Aber irgendwie ist es ja auch eine Limitierung des Hostings, also irgendwie dann doch mein Problem. Und der Kunde war auch ziemlich verzweifelt. Na gut, mal schauen.

Ich installierte mir auf meinem lokalen Proxmox-Server ein WordPress. Hier konnte ich relativ problemlos das Backup importieren. Dann wechselte ich in die Konsole und führte eine Sicherung der WordPress Installation als ZIP her. Knappe 500 MB. Die Datenbank exportierte ich ebenfalls (30 MB). Macht das tolle WordPress-Plugin satte 170 MB overhead? Das ist doch Scheiße. Beide Dateien schob ich auf einen öffentlich erreichbaren FTP-Server und holte von dort die Daten auf die Kundeninstanz.

Das WordPress entpacken, dann die Datenbank importieren und die wp-config.php anpassen. Fertig. Leider gab es immer wieder kleine Probleme. Der FTP Server wollte keine sichere Verbindung zulassen, in der Datenbank-Datei war ein falscher Datenbankname eingetragen und so weiter. Alles lösbar – aber es braucht halt alles seine Zeit.

Insgesamt hat mich das ganze wohl 2 Stunden gekostet. Zeit, die ich in der Ferien-Saison eigentlich überhaupt nicht habe. Aber der Kunde war dann wohl am Ende ganz glücklich.