Hallo Leute – bin gerade dabei, von gehostetem Discourse auf selbst gehostetes umzuziehen. Habe bereits einige Testläufe erfolgreich durchgeführt, aber wenn ich versuche, den eigentlichen Umzug mit allen Uploads durchzuführen, heißt es nach ein paar Stunden des Entpackens des Archivs, dass keine solche Datei oder Verzeichnis existiert, wenn versucht wird, die Dump-Datei zu extrahieren. Stehe nun vor der Aussicht, rund 140 GB Uploads zu verlieren, es sei denn, jemand hat Ideen?
Können Sie das Protokoll bereitstellen?
Stellen Sie die Wiederherstellung über die Befehlszeile oder die Weboberfläche wieder her? Ich empfehle die Weboberfläche.
Hallo – Ich habe das Protokoll in der vorherigen E-Mail angehängt, obwohl ich es hier erneut angehängt habe. Ich habe es zuerst über die Webschnittstelle und dann ein zweites Mal über die Befehlszeile versucht. Ich habe den Verdacht, dass das Backup in irgendeiner Weise beschädigt sein könnte, da es nicht erkannt wird, wenn es auf S3 hochgeladen wird, und fast sofort abgelehnt wird, wenn ich versuche, es über den Browser hochzuladen.
restore-failure-log.txt (3,28 KB)
Das sieht so aus. Haben Sie mit dem Webbrowser oder mit scp/rsync hochgeladen? Ich würde es mit rsync erneut hochladen.
Hallo Jay – Entschuldige, ich war vorhin etwas durcheinander, da wir während dieses Migrationsprozesses auch per E-Mail mit Discourse gesprochen haben, und dort habe ich die Log-Datei angehängt.
Wenn ich mir den Fehler ansehe, vermute ich, dass das Tarball nicht tatsächlich einen SQL-Dump enthält, sondern nur Bilder. Die Datei wurde in unserem Auftrag von Discourse initiiert und geprüft. Ich habe sie über HTTP heruntergeladen und per SCP auf den Server hochgeladen, da der Browser-Upload sie abgelehnt hat.
Ja, ich habe gerade einen Befehl ausgeführt, um den Inhalt des Tarballs zu überprüfen, und er enthält nur Bilder, keinen SQL-Dump.
Können Sie überprüfen, ob die Größen der Tarballs exakt gleich sind?
- auf der CDCK-Instanz
- die heruntergeladene
- die, die Sie mit scp hochgeladen haben
Möglicherweise möchten Sie tar tfvz ausführen, um zu überprüfen, ob das Archiv nicht abgeschnitten ist.
Möglicherweise möchten Sie überprüfen, ob Ihnen irgendwo der Speicherplatz ausgeht, da ein Vielfaches der Größe des Archivs benötigt wird.
Ok, ich bin kurz weg, werde aber später nachsehen. Speicherplatz sollte kein Problem sein, da ich 512 GB habe und die Sicherungsdatei 70 GB groß ist. Ich war überrascht, dass die Datei ein paar GB kleiner war als die letzte, die wir erstellt haben. Ich hatte erwartet, dass sie etwas größer sein würde. Ich bin mir ziemlich sicher, dass aus irgendeinem Grund der SQL-Dump nicht enthalten war, was den Größenunterschied erklären würde.
Hallo @pfaffman @RGJ, hier ist ein Update zum Fortschritt. Der SQL-Dump fehlte tatsächlich im heruntergeladenen Archiv, und ich war mir nicht sicher, ob ein separater DB-Backup und das Einfügen in das Archiv funktionieren würde (und es würde mehrere Stunden zum Testen dauern). Also haben wir die Datenbank wiederhergestellt und migriert (erfolgreich).
Das Problem ist jetzt, dass all unsere historischen Bilder kaputt gehen werden, sobald Discourse alles stilllegt und den S3-Bucket / CDN abschaltet.
Ich habe alle Bilder und denke, ich kann sie hoffentlich alle in unseren S3-Bucket hochladen und dabei die gleiche Ordnerstruktur beibehalten. Ich habe einige Threads gesehen, die die Möglichkeit diskutieren, discourse.remap / dbhelper.remap zu verwenden, um die Links auf Datenbankebene massenhaft zu aktualisieren. Jegliche Gedanken dazu wären sehr willkommen!
Ich kann mir nicht vorstellen, wie das passieren konnte. Hat Ihr Browser das Backup irgendwie entpackt und enttarnt und Sie haben versucht, es wieder zusammenzusetzen?
Sie können die Leute von discourse.org bitten, Ihnen ein Backup zu geben, das die Uploads enthält. Das ist es, was Sie tun wollen. Sie aktivieren eine Einstellung include_s3_uploads_in_backup (das ist nah dran, aber mit ziemlicher Sicherheit nicht der Name der versteckten Einstellung).
Sie können auch S3-Tools verwenden, um sie alle aus ihrem Bucket herunterzuladen und wieder hochzuladen. Es gibt ein paar Themen dazu. Ich empfehle es nicht.
Ich habe kürzlich ein etwa 100 GB großes Backup von CDCK nach Digital Ocean, Droplet, Spaces Bucket und Bunny.net CDNs für 1000 US-Dollar migriert. Das tat mir leid.
Ist das nur die Datenbank?
Oh, haben Sie irgendwie nur eine Datenbankwiederherstellung durchgeführt, obwohl Sie die Bilder in der Tar-Datei haben?
Sie müssen die exakte Datei wiederherstellen, die sie erstellt haben, und Discourse sie wiederherstellen lassen. Diejenige, die die Datenbank und die Uploads enthält. Oder Sie können sich den Wiederherstellungscode ansehen und versuchen, von Hand das zu tun, was er tut, um die Bilder dem neuen Speicherort zuzuordnen. Obwohl ich denke, dass Richard die Fähigkeiten und Werkzeuge hat, um das zu tun, glaube ich nicht, dass Sie es auf diese Weise tun wollen.
Wir haben vor ein paar Monaten einen Testlauf gemacht und alles war in Ordnung. Ich glaube, sie haben diese versteckte Einstellung beibehalten, da ich dieses Mal ein Backup inklusive Uploads vom Backend auslösen konnte, obwohl wir nach etwa 12 Stunden eine Benachrichtigung erhielten, dass es fehlgeschlagen war. Ich habe dann Discourse kontaktiert und sie sagten, sie würden das Backup von ihrer Seite erstellen. Ein paar Stunden später schien das von mir initiierte Backup abgeschlossen zu sein, obwohl wir die Datei wie von Discourse empfohlen verworfen haben. Sie hatten dann eine Reihe von Problemen mit Backups, die Zeitüberschreitungen und Fehler zurückgaben, bevor sie uns schließlich mitteilten, dass eine vollständige Datei vorhanden war. Aber als ich versuchte, die Datei wiederherzustellen, nachdem die Extraktion des Archivs mehrere Stunden gedauert hatte, beschwerte sie sich, dass der Dump fehlte. Die Inspektion der Datei mit tar -tf bestätigte, dass sich kein Dump darin befand (wenn man sich andere vollständige Backups ansieht, ist dies normalerweise die erste Datei im Archiv). Da es Sonntag war, konnte ich Discourse nicht erreichen, und wir hatten versprochen, die Migration bis Montagmorgen abzuschließen, also habe ich nur ein reines Datenbank-Backup (ca. 7 GB) gemacht und dieses zur Migration verwendet.
Discourse versucht zu helfen, aber sie können jetzt wirklich nur noch begrenzt helfen, da wir die Migration abgeschlossen haben und seit Sonntagnachmittag in unserer selbst gehosteten Umgebung sind. Die einfachste Lösung wäre, dass sie unseren S3-Bucket und CDN (gegen Gebühr) aktiv lassen, aber sie haben gesagt, dass dies nicht möglich ist. Ich schätze, wir werden die historischen Bilder wohl einfach verlieren müssen.
Das ist behebbar. Laden Sie einfach den Inhalt des S3-Buckets in Ihr lokales Upload-Verzeichnis herunter und führen Sie dann eine remap in Ihrer Datenbank durch, wobei Sie die CDN- und Bucket-URLs auf die URL Ihrer Instanz umschreiben.
1 „Gefällt mir“
Ein paar Probleme – die Größe der hochgeladenen Bilder würde die SSD unseres neuen VPS volllaufen lassen, und wir haben keine Möglichkeit, eine zusätzliche Festplatte anzuschließen. Vielleicht könnten wir nur eine Teilmenge nehmen, obwohl ich nicht sicher bin, wie das angesichts der Verzeichnisstruktur funktionieren würde. Außerdem haben wir die Website bereits so konfiguriert, dass sie S3 für Uploads anstelle von lokalem Speicher verwendet.
Okay, dann kopieren Sie deren S3 (oder Backup von S3) in Ihr S3 und ordnen Sie es neu zu?
1 „Gefällt mir“
Ja, das hoffe ich auch, dass es möglich ist!
1 „Gefällt mir“
Ah. Ich verstehe. Ja, sobald Sie live sind, sind Sie verpflichtet. Es ist immer noch gut möglich, die Dateien vor dem Löschen nach S3 zu verschieben.
Sie brauchten schon immer genug Platz, um alle Bilder für die Wiederherstellung zu speichern. Sie könnten die Bilder einzeln kopieren. Es gibt auch Werkzeuge, die die Dateien direkt kopieren, glaube ich.
Der ursprüngliche Plan war, eine temporäre Azure VM zur Wiederherstellung zu verwenden, mit einer großen Festplatte, dann zurück nach S3 zu pushen, nach Abschluss ein weiteres Backup zu erstellen und schließlich zu unserem VPS zu verschieben (um die Kosten niedrig zu halten).
Ich habe also ein tar.gz, das alle Uploads enthält, und kann diese direkt in unseren S3-Bucket übertragen, wobei die Verzeichnisstruktur beibehalten wird (ich denke, der Standard-AWS-Uploader kann das heutzutage, ansonsten gibt es die CLI). Möglicherweise gibt es einige Überlegungen zu Besitzern / Berechtigungen, obwohl vielleicht nicht.
Danach wäre es das Remapping - ich bin mir nicht sicher über den Unterschied zwischen discourse.remap und dbhelper.remap. Ich würde testen, ob all dies zuerst auf einer Dummy-Installation mit ein paar Dateien funktioniert.
1 „Gefällt mir“