Datensicherungen sind plötzlich geschrumpft, die geschrumpften Datensicherungen sind abnormal wiederhergestellt, und die Website kann nicht normal interagieren. Glücklicherweise können historische Daten im Amazon S3-Speicher-Bucket gefunden werden, sonst wären die Verluste unermesslich.
Gab es in diesem Zeitraum irgendwelche Einstellungsänderungen, die sich darauf ausgewirkt haben könnten, ob Uploads in Ihre Backups einbezogen wurden?
Ein Upgrade wurde durchgeführt, ein Thema wurde verwendet, ein benutzerdefiniertes Plugin (benutzerdefiniertes CSS) wurde zum Thema hinzugefügt, Benutzer können die Farbauswahl deaktivieren, es wurden data.yml und web_only.yml verwendet. Nach der Wiederherstellung der Daten mit 262 MByte beträgt die Sicherung jetzt nur noch 154 MByte. Diese Sicherungsdaten sind wahrscheinlich immer noch fehlerhaft.
Haben Sie zu diesem Zeitpunkt auf ein Zwei-Container-Setup umgestellt oder haben Sie es schon immer verwendet?
Die häufigste Ursache für diese Art der Nutzung ist wahrscheinlich
Ich habe versucht, vor ein paar Tagen mein letztes Backup wiederherzustellen, und der Upload auf mein Dash wurde abgelehnt. Ich dachte für einen Moment, mein Backup sei weg, also habe ich es noch einmal über FTP hochgeladen und rate mal? Wiederhergestellt! Aber das ist wieder passiert und ich würde gerne den Grund wissen.
Ich fürchte, ich bin mit der Standardinstallation besser vertraut und bin mir nicht sicher, ob die Zwei-Container-Einrichtung irgendwelche Eigenheiten hat, die hier relevant sein könnten.
Ich schiebe das mal zu Installation, um ein paar erfahrenere Augen darauf werfen zu lassen.
(@pfaffman
)
Zuvor wurde die Standardinstallation verwendet, aber die Standardinstallation hat ein Problem: Jedes Mal, wenn ich app.yml geändert habe, konnte meine Website nicht normal aufgerufen werden. Wenn ich data.yml oder web_only.yml verwendet habe, konnten Änderungen an web_only.yml vorgenommen werden, ohne dass der Websitezugriff beeinträchtigt wurde. Hat die Standardinstallation auch eine ähnliche Funktion und wie genau wird sie verwendet?
Nein. Der einzige Unterschied besteht darin, dass ein Rebuild nur den Rails- und Nginx-Teil neu erstellt. Die Datenbank und Redis bleiben gleich. Diese ändern sich selten, daher müssen sie nicht neu erstellt werden. Es funktioniert genauso. Das verstehst du schon ganz gut. (Die einzige Komplikation besteht, wenn es ein Postgres- oder Redis-Update gibt, was etwa einmal im Jahr vorkommt, obwohl es einige Datenbank-Updates gab, die aufgrund der Anforderungen des KI-Plugins erforderlich waren. Wenn du also das KI-Plugin nicht verwenden würdest, wärst du völlig in Ordnung, aber wenn du es verwenden würdest, würdest du verwirrende Datenbankfehler bekommen, wenn du nicht auch den Datencontainer neu erstellst.)
Ich vermute, dass sie Assets nach S3 verschoben haben und daher die lokalen Uploads nicht enthalten sind. Dies stimmt damit überein, dass sie sagen konnten, dass sie Dinge aus S3 wiederherstellen konnten. Oder vielleicht haben sie einige Beiträge gelöscht, die Uploads enthielten, sodass diese Uploads nicht in nachfolgenden Backups enthalten waren.
Außerdem klang es ein wenig so, als hätten sie eine Wiederherstellung durchgeführt und nicht darauf gewartet, dass sie vollständig abgeschlossen ist.
Ich habe tatsächlich ein KI-Plugin verwendet. Worauf muss ich achten, damit die Sicherungsdaten verwendet werden können? Wie sollen wir mit dieser Art von Problem umgehen?
I did use an AI plug-in. What should I pay attention to so that the backup data can be used? How should we deal with this kind of problem
Das bedeutet, dass es kein Problem gibt, solange data.yml nicht neu erstellt wird, oder muss app.yml verwendet werden, oder besteht dieses Problem sowohl im data.yml web_only-Plan als auch im app.yml-Plan?
Es bedeutet, dass es kein Problem gibt, solange data.yml nicht neu erstellt wird, oder muss app.yml verwendet werden, oder besteht dieses Problem sowohl im data.yml web_only-Plan als auch im app.yml-Plan?
Das Problem ist, dass die von data.yml erstellte Containerversion, als ich ein Backup gemacht habe, nicht unterstützt wurde, und die Datenbank wurde aktualisiert. Wenn der data.yml rebuild aktualisiert wird, wird es kein Problem geben, selbst wenn Sie ein großes Datenbankupgrade durchführen, und dann gibt es kein Problem mit dem Backup und der Wiederherstellung. Woher weiß ich, dass Ihre Datenbank stark modifiziert wurde?
Das Problem ist, dass die von data.yml erstellte Containerversion, als ich ein Backup gemacht habe, nicht unterstützt wurde, und die Datenbank wurde aktualisiert. Wenn der data.yml rebuild aktualisiert wird, wird es kein Problem geben, selbst wenn Sie ein großes Datenbankupgrade durchführen, und dann gibt es kein Problem mit dem Backup und der Wiederherstellung. Woher weiß ich, dass Ihre Datenbank stark modifiziert wurde?
@sober, als Prozesshinweis: Es ist für diejenigen, die mitlesen/helfen wollen, viel einfacher, wenn Sie eine englische Übersetzung in Ihre Beiträge aufnehmen. Könnten Sie bitte eine nachträglich einfügen. ![]()
Ich verstehe jetzt, dass das Problem ein großes Upgrade der Datenbank war, das zu Backup-Problemen führte.
Wenn Discourse aktualisiert wird, wie kann ich sicherstellen, dass die aktualisierte Version eine Beta-Version und keine Entwicklungsversion ist? Nachdem das letzte Backup fehlgeschlagen ist, muss ich mir Sorgen um die Upgrade- und Backup-Wiederherstellungsoperationen machen.
Was? Nun, ich werde auf eine Bestätigung warten, da ich nicht weiß, ob hier etwas kaputt geht.
Ich möchte nur beta2 upgraden, nicht beta2-dev, da ich befürchte, dass dev instabil ist, und das aktuelle Daten-Backup nicht normal wiederhergestellt werden kann, was fast zu Datenverlust führt. Ich habe das frühe Backup zur Sicherung verwendet, aber die Daten gingen trotzdem für eine gewisse Zeit verloren.
Das sind sie nicht, das ist nur eine kürzliche Änderung am Versionierungssystem. Technisch gesehen sollten Sie die -dev-Labels gar nicht sehen.


