Hilfe bei der Wiederherstellung - System hing um Mitternacht

[RBoy]

Okay, das musste irgendwann passieren, die Dinge waren einfach zu lange zu gut. Jahre lang lief alles im Cruisemodus, das System aktualisierte sich automatisch, und ich aktualisierte Discourse alle paar Wochen. Um Mitternacht gestern zeigte Amazon an, dass das System nicht reagiert, Discourse war ausgefallen und die CPU war auf 100 % ausgelastet, bis die AWS-CPU-Ressourcen erschöpft waren. Ich konnte mich nicht am System anmelden. Das einzige Mal, dass ich nach mehreren Neustarts kurzzeitig Zugang hatte, sah ich dies in htop, das viel CPU belegte:

snap lxd activate

Wenn jemand dies schon einmal gesehen hat und erklären kann, warum dies von selbst geschehen sein könnte, wäre das für zukünftige Referenzen sehr hilfreich.

Was das dringende Problem angeht: Ich habe einen neuen Server auf AWS mit Ubuntu 20LTS neu aufgesetzt. Die Discourse-Einrichtung war überaus einfach. Ich hatte eine Kopie der app.yml-Datei, die ich verwendete, um das Discourse-Forum neu zu erstellen. Der alte Server nutzte S3 sowohl für Backups als auch für den Inhalt (Bilder usw.).

Nach dem Erstellen des Servers lud ich die neueste Discourse-Backup-Datei von S3 herunter, lud sie manuell auf den Discourse-Server hoch und klickte auf die Schaltfläche Restore. Nach einigen Minuten erhielt ich diesen Fehler:

[2022-06-09 09:01:56] ALTER TABLE
[2022-06-09 09:01:56] ALTER TABLE
[2022-06-09 09:01:56] Migrating the database...
[2022-06-09 09:02:11] == 20220308201942 CreateUploadReferences: migrating ===========================
-- create_table(:upload_references, {})
   -> 0.0486s
-- add_index(:upload_references, [:upload_id, :target_type, :target_id], {:unique=>true, :name=>"index_upload_references_on_upload_and_target"})
   -> 0.0030s
== 20220308201942 CreateUploadReferences: migrated (0.0580s) ==================

== 20220309132719 CopyPostUploadsToUploadReferences: migrating ================
-- execute("INSERT INTO upload_references(upload_id, target_type, target_id, created_at, updated_at)\nSELECT post_uploads.upload_id, 'Post', post_uploads.post_id, uploads.created_at, uploads.updated_at\nFROM post_uploads\nJOIN uploads ON uploads.id = post_uploads.upload_id\nON CONFLICT DO NOTHING\n")
   -> 0.0595s
== 20220309132719 CopyPostUploadsToUploadReferences: migrated (0.0602s) =======

== 20220309132720 CopyPostUploadsToUploadReferencesForSync: migrating =========
-- execute("INSERT INTO upload_references(upload_id, target_type, target_id, created_at, updated_at)\nSELECT upload_id, 'Post', post_id, NOW(), NOW()\nFROM post_uploads\nON CONFLICT DO NOTHING\n")
   -> 0.0076s
== 20220309132720 CopyPostUploadsToUploadReferencesForSync: migrated (0.0080s) 

== 20220330160747 CopySiteSettingsUploadsToUploadReferences: migrating ========
-- execute("WITH site_settings_uploads AS (\n  SELECT id, unnest(string_to_array(value, '|'))::integer upload_id\n  FROM site_settings\n  WHERE data_type = 17\n  UNION\n  SELECT id, value::integer\n  FROM site_settings\n  WHERE data_type = 18 AND value != ''\n)\nINSERT INTO upload_references(upload_id, target_type, target_id, created_at, updated_at)\nSELECT site_settings_uploads.upload_id, 'SiteSetting', site_settings_uploads.id, uploads.created_at, uploads.updated_at\nFROM site_settings_uploads\nJOIN uploads ON uploads.id = site_settings_uploads.upload_id\nON CONFLICT DO NOTHING\n")
   -> 0.0034s
== 20220330160747 CopySiteSettingsUploadsToUploadReferences: migrated (0.0038s) 

== 20220330160751 CopyBadgesUploadsToUploadReferences: migrating ==============
-- execute("INSERT INTO upload_references(upload_id, target_type, target_id, created_at, updated_at)\nSELECT badges.image_upload_id, 'Badge', badges.id, uploads.created_at, uploads.updated_at\nFROM badges\nJOIN uploads ON uploads.id = badges.image_upload_id\nWHERE badges.image_upload_id IS NOT NULL\nON CONFLICT DO NOTHING\n")
   -> 0.0006s
== 20220330160751 CopyBadgesUploadsToUploadReferences: migrated (0.0010s) =====

== 20220330160754 CopyGroupsUploadsToUploadReferences: migrating ==============
-- execute("INSERT INTO upload_references(upload_id, target_type, target_id, created_at, updated_at)\nSELECT groups.flair_upload_id, 'Group', groups.id, uploads.created_at, uploads.updated_at\nFROM groups\nJOIN uploads ON uploads.id = groups.flair_upload_id\nWHERE groups.flair_upload_id IS NOT NULL\nON CONFLICT DO NOTHING\n")
   -> 0.0050s
== 20220330160754 CopyGroupsUploadsToUploadReferences: migrated (0.0055s) =====

== 20220330160757 CopyUserExportsUploadsToUploadReferences: migrating =========
-- execute("INSERT INTO upload_references(upload_id, target_type, target_id, created_at, updated_at)\nSELECT user_exports.upload_id, 'UserExport', user_exports.id, uploads.created_at, uploads.updated_at\nFROM user_exports\nJOIN uploads ON uploads.id = user_exports.upload_id\nON CONFLICT DO NOTHING\n")
   -> 0.0013s
== 20220330160757 CopyUserExportsUploadsToUploadReferences: migrated (0.0041s) 

== 20220330164740 CopyThemeFieldsUploadsToUploadReferences: migrating =========
-- execute("INSERT INTO upload_references(upload_id, target_type, target_id, created_at, updated_at)\nSELECT theme_fields.upload_id, 'ThemeField', theme_fields.id, uploads.created_at, uploads.updated_at\nFROM theme_fields\nJOIN uploads ON uploads.id = theme_fields.upload_id\nWHERE type_id = 2\nON CONFLICT DO NOTHING\n")
   -> 0.0006s
== 20220330164740 CopyThemeFieldsUploadsToUploadReferences: migrated (0.0010s) 

== 20220404195635 CopyCategoriesUploadsToUploadReferences: migrating ==========
-- execute("INSERT INTO upload_references(upload_id, target_type, target_id, created_at, updated_at)\nSELECT categories.uploaded_logo_id, 'Category', categories.id, uploads.created_at, uploads.updated_at\nFROM categories\nJOIN uploads ON uploads.id = categories.uploaded_logo_id\nWHERE categories.uploaded_logo_id IS NOT NULL\nON CONFLICT DO NOTHING\n")
   -> 0.0095s
-- execute("INSERT INTO upload_references(upload_id, target_type, target_id, created_at, updated_at)\nSELECT categories.uploaded_background_id, 'Category', categories.id, uploads.created_at, uploads.updated_at\nFROM categories\nJOIN uploads ON uploads.id = categories.uploaded_background_id\nWHERE categories.uploaded_background_id IS NOT NULL\nON CONFLICT DO NOTHING\n")
   -> 0.0004s
== 20220404195635 CopyCategoriesUploadsToUploadReferences: migrated (0.0103s) =

== 20220404201949 CopyCustomEmojisUploadsToUploadReferences: migrating ========
-- execute("INSERT INTO upload_references(upload_id, target_type, target_id, created_at, updated_at)\nSELECT custom_emojis.upload_id, 'CustomEmoji', custom_emojis.id, uploads.created_at, uploads.updated_at\nFROM custom_emojis\nJOIN uploads ON uploads.id = custom_emojis.upload_id\nWHERE custom_emojis.upload_id IS NOT NULL\nON CONFLICT DO NOTHING\n")
   -> 0.0032s
== 20220404201949 CopyCustomEmojisUploadsToUploadReferences: migrated (0.0036s) 

== 20220404203356 CopyUserProfilesUploadsToUploadReferences: migrating ========
-- execute("INSERT INTO upload_references(upload_id, target_type, target_id, created_at, updated_at)\nSELECT user_profiles.profile_background_upload_id, 'UserProfile', user_profiles.user_id, uploads.created_at, uploads.updated_at\nFROM user_profiles\nJOIN uploads ON uploads.id = user_profiles.profile_background_upload_id\nWHERE user_profiles.profile_background_upload_id IS NOT NULL\nON CONFLICT DO NOTHING\n")
   -> 0.0017s
-- execute("INSERT INTO upload_references(upload_id, target_type, target_id, created_at, updated_at)\nSELECT user_profiles.card_background_upload_id, 'UserProfile', user_profiles.user_id, uploads.created_at, uploads.updated_at\nFROM user_profiles\nJOIN uploads ON uploads.id = user_profiles.card_background_upload_id\nWHERE user_profiles.card_background_upload_id IS NOT NULL\nON CONFLICT DO NOTHING\n")
   -> 0.0011s
== 20220404203356 CopyUserProfilesUploadsToUploadReferences: migrated (0.0033s) 

== 20220404204439 CopyUserAvatarsUploadsToUploadReferences: migrating =========
-- execute("INSERT INTO upload_references(upload_id, target_type, target_id, created_at, updated_at)\nSELECT user_avatars.custom_upload_id, 'UserAvatar', user_avatars.id, uploads.created_at, uploads.updated_at\nFROM user_avatars\nJOIN uploads ON uploads.id = user_avatars.custom_upload_id\nWHERE user_avatars.custom_upload_id IS NOT NULL\nON CONFLICT DO NOTHING\n")
   -> 0.0200s
-- execute("INSERT INTO upload_references(upload_id, target_type, target_id, created_at, updated_at)\nSELECT user_avatars.gravatar_upload_id, 'UserAvatar', user_avatars.id, uploads.created_at, uploads.updated_at\nFROM user_avatars\nJOIN uploads ON uploads.id = user_avatars.gravatar_upload_id\nWHERE user_avatars.gravatar_upload_id IS NOT NULL\nON CONFLICT DO NOTHING\n")
   -> 0.0069s
== 20220404204439 CopyUserAvatarsUploadsToUploadReferences: migrated (0.0276s) 

== 20220404212716 CopyThemeSettingsUploadsToUploadReferences: migrating =======
-- execute("INSERT INTO upload_references(upload_id, target_type, target_id, created_at, updated_at)\nSELECT theme_settings.value::int, 'ThemeSetting', theme_settings.id, uploads.created_at, uploads.updated_at\nFROM theme_settings\nJOIN uploads ON uploads.id = theme_settings.value::int\nWHERE data_type = 6 AND theme_settings.value IS NOT NULL AND theme_settings.value != ''\nON CONFLICT DO NOTHING\n")
   -> 0.0025s
== 20220404212716 CopyThemeSettingsUploadsToUploadReferences: migrated (0.0030s) 

== 20220526203356 CopyUserUploadsToUploadReferences: migrating ================
-- execute("INSERT INTO upload_references(upload_id, target_type, target_id, created_at, updated_at)\nSELECT users.uploaded_avatar_id, 'User', users.id, uploads.created_at, uploads.updated_at\nFROM users\nJOIN uploads ON uploads.id = users.uploaded_avatar_id\nWHERE users.uploaded_avatar_id IS NOT NULL\nON CONFLICT DO NOTHING\n")
   -> 0.0227s
== 20220526203356 CopyUserUploadsToUploadReferences: migrated (0.0234s) =======


[2022-06-09 09:02:11] Reconnecting to the database...
[2022-06-09 09:02:12] Reloading site settings...
[2022-06-09 09:02:12] Disabling outgoing emails for non-staff users...
[2022-06-09 09:02:14] Disabling readonly mode...
[2022-06-09 09:02:14] Clearing category cache...
[2022-06-09 09:02:14] Reloading translations...
[2022-06-09 09:02:14] Remapping uploads...
[2022-06-09 09:02:14] Restoring uploads, this may take a while...
[2022-06-09 09:03:05] EXCEPTION: 509 of 1823 uploads are not migrated to S3. S3 migration failed for db 'default'.
[2022-06-09 09:03:05] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:79:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:373:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:66:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:328:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:62:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:44:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:61:in `run'
/var/www/discourse/script/spawn_backup_restore.rb:23:in `restore'
/var/www/discourse/script/spawn_backup_restore.rb:36:in `block in <main>'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `<main>'

Kann mir jemand sagen, was das Problem ist und wie ich den Server von den Amazon S3-Backups wiederherstellen kann?

[Benjamin_D (Benjamin Decotte)]

Hallo,
hatten Sie nach der Neuerstellung des neuen Servers aus der app.yml Zugriff auf die Sicherungen im Abschnitt https://your.domain/admin/backups?

[RBoy]

Nein, nachdem ich es aus app.yml neu erstellt hatte, erhielt ich nur ein sauberes neues Setup ohne etwas. Ich habe das letzte Backup von S3 heruntergeladen, es manuell lokal in Discourse hochgeladen und auf Wiederherstellen geklickt.

Ich beginne mit der Wiederherstellung, sehe alle Einstellungen (einschließlich S3, die Anmeldeinformationen, alles von der Einstellungsseite) wieder, sehe alle Kategorien, Beiträge und alles. Dann, plötzlich nach ein paar Minuten, erhalte ich eine Abmeldemeldung und alle Kategorien und Themen verschwinden, und die Protokolle zeigen diesen Fehler an (es scheint eine Rückgängigmachung zu geben).

[Benjamin_D (Benjamin Decotte)]

Die S3-Konfiguration befindet sich also nicht in der app.yml (wie hier beschrieben Configure an S3 compatible object storage provider for uploads)? Sondern konfiguriert wie in Set up file and image uploads to S3?

[RBoy]

Nein, das sehe ich nicht in meiner app.yml

Alle S3-Einstellungen wurden auf den Seiten Admin → Einstellungen definiert und es funktionierte ein Jahr lang gut, bis ich es wiederherstellen musste, als der Server gestern Abend ausfiel.

@Benjamin_D

Aber wie in Einrichten von Datei- und Bild-Uploads nach S3 konfiguriert

Korrekt, dies ist, was ich zur Einrichtung der S3-Backups und -Uploads verwendet habe.

[Benjamin_D (Benjamin Decotte)]

Ich würde versuchen, die app.yml mit Ihren Einstellungen zu bearbeiten, und von dort aus sollten Sie (hoffentlich?) Ihre Backups im Admin-Bereich sehen und von dort wiederherstellen können, ohne den manuellen Import und die Uploads, die Sie nicht wiederherstellen müssten, aber in den Backups enthalten zu sein scheinen. Ich weiß allerdings nicht, warum es fehlschlägt…

[JammyDodger]

Ich glaube, das könnte daran liegen, dass Ihr Backup eine Mischung aus S3- und lokalen Uploads enthält. Ich fürchte, das liegt nicht in meinem Fachgebiet, aber es gibt eine Diskussion und eine Lösung in diesem Thema, die es Ihnen ermöglicht, den Fehler zu umgehen. Allerdings galt dies für eine viel geringere Anzahl von Fehlern, daher sollten Sie dies berücksichtigen:

Migrate_to_s3 fails

Looking at the error message from your previous post, it’s the count on line 85 which is of interest. @Falco’s suggestion for editing the script is to increase that count to ignore some number of failures. The simplest way to achieve that is by entering the container and using sed to make an in-place substitution on that specific line. cd /var/discourse ./launcher enter app sed -i '85s/0/100/' lib/file_store/to_s3_migration.rb Run the rake task again after that and it will ignore up to 100 “p…

[RBoy]

Leider ist meine Website abgestürzt, sodass mir nur noch die S3-Uploads und Backups übrig bleiben. Ich gehe davon aus, dass es für mich keine Möglichkeit gibt, verbleibende lokale Dateien jetzt auf S3 zu migrieren.

Ich frage mich also, welche Optionen ich jetzt habe? Gibt es eine Möglichkeit, von S3-Backups wiederherzustellen und die lokalen Dateien zu ignorieren? Ich habe einen Weg gefunden, den S3-Upload zu ignorieren, aber dann haben fast alle Beiträge defekte Links/Bilder (90 %+ sind wahrscheinlich in S3, weil ich den S3-Upload vor vielen, vielen Jahren eingerichtet habe).

[RBoy]

Hier ist ein Update für diejenigen, die möglicherweise mit demselben Problem kämpfen (im Grunde kann ich keine Wiederherstellung aus einem Backup durchführen und der Server ist aufgrund eines fehlerhaften System-Upgrades abgestürzt).

Nach meinem Verständnis ist die Hauptursache des Problems, dass es lokale Uploads UND S3-Uploads gibt. Wenn das Wiederherstellungstool versucht, eine Wiederherstellung durchzuführen, funktioniert es nicht, da es nicht weiß, wie es lokale und S3-Wiederherstellungen gleichzeitig verarbeiten soll (vielleicht ist es an der Zeit, dass Discourse Backups/Wiederherstellungen überdenkt).

Dank @RGJ für diesen Tipp, er schlug vor, Discourse zu zwingen, den S3-Upload während der Wiederherstellung zu ignorieren:

1. Fügen Sie eine Zeile zu Ihrer app.yml hinzu DISCOURSE_ENABLE_S3_UPLOADS=false
2. Bauen Sie Discourse neu auf ./launcher rebuild app
3. Versuchen Sie eine Wiederherstellung (entweder von der GUI-Backup-Seite oder über die CLI)
4. Entfernen Sie dann nach der Wiederherstellung diese Zeile aus app.yml und bauen Sie sie noch einmal neu auf

Während dies funktionierte, ist zu beachten, dass das Forum stark beschädigt war. Die Kategorien, Einstellungen und Beiträge wurden wiederhergestellt, jedoch waren alle Bilder, Links, eingebetteten Dokumente usw. beschädigt und fehlerhaft.

Die Notlösung:
Ich konnte den alten Server retten und extrahierte das Verzeichnis /var/discourse (tar/gz) und kopierte es auf den neuen Server und führte ./launcher rebuild app aus. Dies stellte den Betrieb des Forums vollständig wieder her, jedoch bleibt das grundlegende Problem bestehen – die Backups funktionieren NICHT, da sie eine Mischung aus lokalen und S3-Uploads enthalten.

Ich brauche also wirklich Ratschläge, wie ich dieses Problem ein für alle Mal am besten lösen kann. Ist es besser/einfacher, alle Uploads von lokal nach S3 oder von S3 nach lokal zu verschieben, und wie macht man das? Der gesamte Sinn eines Backups ist es, in solchen Situationen zu helfen, aber es hat mich im Stich gelassen, daher brauche ich Ihre Hilfe, um es in Ordnung zu bringen.

[pfaffman (Jay Pfaffman)]

Wenn Sie die Konfiguration wie in Objektspeicher für Uploads verwenden (S3 & Klone) beschrieben vornehmen, sollten Sie in der Lage sein, Folgendes auszuführen:

 rake uploads:migrate_to_s3

Wenn Sie die Verwendung von S3 beenden möchten, können Sie die Rails-Konsole aufrufen und Folgendes festlegen:

  SiteSetting.include_s3_uploads_in_backups=true

Führen Sie dann ein Backup durch, stellen Sie sicher, dass S3 nicht in Ihrer app.yml konfiguriert ist, und stellen Sie das Backup wieder her. Ich glaube, dass dies Backups lokal wiederherstellen wird.

In beiden Fällen empfehle ich jedoch immer noch, Ihre Schlüssel und den Backup-Bucket in Umgebungsvariablen in Ihrer app.yml-Datei festzulegen und dann zu überprüfen, ob Sie sie auf einer neuen Website wiederherstellen können.

[RBoy]

Okay, ich glaube, ich habe mich hier ein wenig vertan.

Ich denke, das Ideale wäre, alle Uploads lokal zu speichern und die Backups (Zips) auf S3 zu sichern. Auf diese Weise ist das Backup auf S3 verfügbar, falls etwas mit dem Server passiert, aber das Backup selbst ist in sich abgeschlossen und hat keine Abhängigkeiten, sodass es einfach auf einem neuen Server wiederhergestellt werden kann.

Wenn ich das richtig verstanden habe, sollte ich diese Anweisungen befolgen:

Wenn Sie die Verwendung von S3 beenden möchten, können Sie die Rails-Konsole aufrufen und Folgendes festlegen:

  SiteSetting.include_s3_uploads_in_backups=true
Nehmen Sie dann ein Backup vor, stellen Sie sicher, dass S3 nicht in Ihrer app.yml konfiguriert ist, und stellen Sie das Backup wieder her. Ich glaube, dass dies Backups lokal wiederherstellt.

und dann

1. Deaktivieren Sie die Option Uploads zu S3 aktivieren in Admin → Einstellungen → Dateien
2. Aktivieren Sie die Option Backup zu S3 auf der Seite Admin → Einstellungen → Backups

Ist das richtig?

@pfaffman

Aber in beiden Fällen würde ich immer noch empfehlen, Ihre Schlüssel und Ihren Backup-Bucket in ENV-Variablen in Ihrer app.yml-Datei festzulegen und dann zu überprüfen, ob Sie sie auf einer neuen Website wiederherstellen können.

Das ist der Teil, der mich verwirrt hat: Warum sollte ich die S3-Konfiguration in die app.yml-Datei einfügen?

[pfaffman (Jay Pfaffman)]

@RBoy

Das ist der Teil, der mich verwirrt hat: Warum sollte ich die S3-Konfiguration in die Datei app.yml einfügen?

Damit Sie über eine Befehlszeilenwiederherstellung auf Ihre Sicherungen zugreifen können, bevor Sie Ihre Sicherung wiederherstellen. Andernfalls müssen Sie ein Administratorkonto einrichten und dann S3 konfigurieren und dann wiederherstellen. Ebenso werden alle Einstellungen, die Sie in Ihre Datenbank eingeben, überschrieben, wenn Sie die Datenbank wiederherstellen.

Ich denke, es ist am besten, S3 nur über ENV-Variablen in der Datei app.yml zu konfigurieren. Es wäre wahrscheinlich sinnvoll, sie als versteckte Einstellungen zu kennzeichnen, wenn nicht Hunderte von Leuten überrascht wären, dass sie verschwunden sind.

[RGJ (Richard - Communiteq)]

@RBoy

Warum sollte ich die S3-Konfiguration in die app.yml-Datei einfügen?

Weil Sie sonst Probleme bei der Wiederherstellung haben werden.

[RBoy]

@Richard – Communiteq

Weil Sie sonst Probleme bei der Wiederherstellung haben werden.

Wie kann man ein Backup von S3 über die Befehlszeile wiederherstellen? Laut den Anweisungen hier: Restore a backup from the command line
Dort steht, dass man die Backup-Datei in den Ordner /var/discourse/shared/standalone/backups/default legen und dann eine Wiederherstellung über die CLI starten kann. Das habe ich auch mit Ihrem Vorschlag zuvor gemacht (was leider zu defekten Links führte), aber das funktioniert.

Wie kann man direkt von S3 über die CLI wiederherstellen?

[pfaffman (Jay Pfaffman)]

cd /var/discourse
./launcher enter app
discourse restore

Es wird die verfügbaren Backups angezeigt, von denen Sie dann dasjenige kopieren/einfügen können, das Sie wiederherstellen möchten.

[RBoy]

Danke, es wird also die S3-Backups lesen und sie als Option auflisten.

Jay, um auf einen deiner Vorschläge zurückzukommen, Assets lokal zu verschieben:

Ich denke, Sie können eine versteckte Einstellung include_s3_uploads_in_backups auf true setzen und dann ein Backup erstellen und es wiederherstellen, wenn S3 ausgeschaltet ist, um die Verwendung von S3 zu beenden.

S3-Backups mit der Konfiguration in app.yml bedeuten, dass Sie eine Wiederherstellung über die Befehlszeile mit nur der Datei app.yml durchführen können (nachdem Sie Discourse geklont und Docker installiert haben).

Muss ich für den ersten Schritt die S3-Buckets sichern oder ist dies ein Bucket-sicherer Vorgang?

[RBoy]

Nun, zumindest habe ich herausgefunden, warum mein Server letzte Nacht abgestürzt ist (und heute nach einem kompletten Neuaufbau wieder , siehe dieses Thema für Details: Ubuntu 20.04 kernel update with docker causing a crash on EC2 and Lightsail

[RBoy]

Um es von einem Backup zum Laufen zu bringen, musste ich

1. Einstellungen → Dateien → S3-Uploads aktivieren deaktivieren
2. Einstellungen → Backups → Backup-Speicherort → S3
3. Einstellungen → Backups → Backup mit Uploads aktivieren

Dann habe ich ein Backup gemacht und konnte es erfolgreich wiederherstellen. Allerdings ist eine Sache kaputt gegangen, alle Anhänge (Dateien) haben jetzt ungültige Links. Die Bilder sind alle gut, aber Links zu Anhängen wie https://domain.com/uploads/short-url/phu1HOLvkE8LWpkKYfnMPSWsvHh.zip geben mir jetzt einen Fehler

Ups! Diese Seite existiert nicht oder ist privat.

Gibt es eine Möglichkeit, diese Kurz-URL-Links zu reparieren?

[pfaffman (Jay Pfaffman)]

Sie könnten versuchen, einen HTML-Neubau (auch Rebake genannt) für eines dieser Themen durchzuführen, um zu sehen, ob das Problem behoben wird.

[RBoy]

Danke. Gibt es irgendwo eine Anleitung, wie man den Befehl zum Backen bestimmter Themen ausgibt?