I’ve been running into issues trying to run a restore on our Staging Discourse instance. Staging is running v2.4.0.beta1 +36. Any idea where the breakdown might be or where to look? Thanks in advance!
Below is the end of the log output:
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] Migrating the database...
[2019-07-16 20:08:16] Reconnecting to the database...
[2019-07-16 20:08:16] Reloading site settings...
[2019-07-16 20:08:16] Disabling outgoing emails for non-staff users...
[2019-07-16 20:08:16] Clearing emoji cache...
[2019-07-16 20:08:16] Disabling readonly mode...
[2019-07-16 20:08:16] Clear theme cache
[2019-07-16 20:08:22] Extracting uploads...
[2019-07-16 20:08:40] Migrating uploads to S3...
[2019-07-16 20:08:46] Restore process was cancelled!
[2019-07-16 20:08:46] Trying to rollback...
[2019-07-16 20:08:46] Rolling back...
[2019-07-16 20:08:47] Cleaning stuff up...
[2019-07-16 20:08:47] Removing tmp '/var/www/discourse/tmp/restores/default/2019-07-16-200516' directory...
[2019-07-16 20:08:48] Unpausing sidekiq...
[2019-07-16 20:08:48] Marking restore as finished...
Below is the output after running discourse restore BACKUP_FILENAME from the command line. Any feedback is appreciated, thanks!
Disabling outgoing emails for non-staff users...
Clearing emoji cache...
Disabling readonly mode...
Clear theme cache
Extracting uploads...
Migrating uploads to S3...
Checking if default already migrated...
524 of 9474 uploads are not migrated to S3. S3 migration failed for db 'default'.
321 posts are not remapped to new S3 upload URL. S3 migration failed for db 'default'.
Looking for missing uploads on: default
Fixing missing uploads:
..........................................................................................................
116 post uploads are missing.
116 uploads are missing.
106 of 116 are old scheme uploads.
98 of 83342 posts are affected.
rake posts:missing_uploads identified 98 issues. S3 migration failed for db 'default'.
No posts require rebaking
Migrating uploads to S3 for 'default'...
Some uploads were not migrated to the new scheme. Please run these commands in the rails console
SiteSetting.migrate_to_new_scheme = true
Jobs::MigrateUploadScheme.new.execute(nil)
Restore process was cancelled!
Trying to rollback...
Rolling back...
Cleaning stuff up...
Removing tmp '/var/www/discourse/tmp/restores/default/2019-07-22-172918' directory...
Unpausing sidekiq...
Marking restore as finished...
Notifying 'system' of the end of the restore...
Finished!
[FAILED]
Restore done.
Je suis presque certain que je viens d’être touché par ce problème aussi ; je pense que cela devrait être signalé comme un bug.
(Si c’est différent, n’hésitez pas à créer un nouveau sujet séparé).
Il est plutôt important que la restauration des sauvegardes fonctionne.
Notez que la raison de l’échec n’est pas évidente lorsque vous utilisez l’interface d’administration et cliquez sur Restaurer à côté du nom de la sauvegarde ; vous obtenez :
...
Migration des pièces jointes vers S3...
Le processus de restauration a été annulé !
...
L’exécution de la restauration via la ligne de commande vous donne plus de détails :
discourse enter app
discourse restore example-net-2020-01-02-033557-v20191219112000.tar.gz
...
Reconnexion à la base de données...
Rechargement des paramètres du site...
Désactivation des emails sortants pour les utilisateurs non membres du personnel...
Vidage du cache des emojis...
Désactivation du mode lecture seule...
Vidage du cache du thème
Extraction des pièces jointes...
Remappage des pièces jointes...
Remappage de '//forum-example-net.s3.dualstack.eu-west-2.amazonaws.com/' vers '/uploads/default/'
optimized_images=3
uploads=1
Migration des pièces jointes vers S3...
Vérification si la migration par défaut a déjà été effectuée...
6 des 12 pièces jointes n'ont pas été migrées vers S3. Échec de la migration S3 pour la base de données 'default'.
1 publication n'a pas été remappée vers la nouvelle URL de pièce jointe S3. Échec de la migration S3 pour la base de données 'default'.
Recherche des pièces jointes manquantes sur : default
0 pièces jointes de publication sont manquantes.
Veuillez fournir les variables d'environnement suivantes :
- DISCOURSE_S3_BUCKET
- DISCOURSE_S3_REGION
et soit
- DISCOURSE_S3_ACCESS_KEY_ID
- DISCOURSE_S3_SECRET_ACCESS_KEY
ou
- DISCOURSE_S3_USE_IAM_PROFILE
Le processus de restauration a été annulé !
Tentative de retour en arrière...
Retour en arrière...
Nettoyage des éléments...
Suppression de la fonction du schéma discourse_functions
Suppression du répertoire temporaire '/var/www/discourse/tmp/restores/default/2020-01-06-222212'...
Reprise de sidekiq...
Marquage de la restauration comme terminée...
Notification à 'system' de la fin de la restauration...
Terminé !
[ÉCHEC]
Restauration terminée.
J’ai ajouté un peu de code de débogage dans uploads.rake juste avant « Veuillez fournir les variables d’environnement suivantes » pour afficher les variables d’environnement :
puts "ENV: " + ENV.inspect
ENV ne contenait aucune variable DISCOURSE_S3_* définie.
Y a-t-il une raison valable pour laquelle ces données ne sont pas extraites des paramètres ?
Je pense que l’idée est que si vous avez des fichiers uploadés sur S3, vous effectuerez une sauvegarde uniquement de la base de données, et cela ne risque pas d’échouer car il n’y aura pas de fichiers uploadés à inclure.
Tout à fait, mais cela ne aide pas quand la sauvegarde que vous avez inclut les téléchargements.
Pour être clair - ce n’est pas critique pour moi en ce moment, je peux commenter les lignes problématiques et terminer la restauration, mais d’autres ne le peuvent pas.
Inutile de le convertir en bug. C’est dans mes attributions et j’ai déjà consacré énormément de temps à la refactorisation du processus de restauration, à l’ajout de nombreux tests et à l’amélioration de sa fiabilité. Je vais apporter quelques ajustements supplémentaires pour réduire les risques de rupture lors de la restauration vers S3 et pour afficher plus d’informations dans l’interface d’administration.
À ma connaissance, la fonctionnalité de sauvegarde/restauration a été refaite, mais je viens de découvrir que ce problème persiste.
Une tentative de restauration sur beta11 d’une sauvegarde avec l’option enable s3 uploads activée échoue toujours avec :
[2020-02-18 09:51:38] Restauration des fichiers joints, cela peut prendre un certain temps...
[2020-02-18 09:51:38] EXCEPTION : Veuillez fournir les variables d'environnement suivantes :
- DISCOURSE_S3_BUCKET
- DISCOURSE_S3_REGION
et soit
- DISCOURSE_S3_ACCESS_KEY_ID
- DISCOURSE_S3_SECRET_ACCESS_KEY
soit
- DISCOURSE_S3_USE_IAM_PROFILE
[2020-02-18 09:51:38] /var/www/discourse/lib/file_store/to_s3_migration.rb:34:in `s3_options_from_env'
C’est exact, il s’agit d’une migration des téléversements.
Les identifiants d’accès S3 sont présents dans la base de données restaurée, il n’est donc pas nécessaire de les exiger également dans une variable d’environnement.
La fourniture des variables d’environnement entraîne également un échec :
Restauration des téléversements, cela peut prendre un certain temps...
Vérification si db8015 a déjà été migré...
200 des 206 téléversements n'ont pas été migrés vers S3. Échec de la migration S3 pour la base de données 'db8015'.
5 publications n'ont pas été remappées vers la nouvelle URL de téléversement S3. Échec de la migration S3 pour la base de données 'db8015'.
Aucune publication ne nécessite de remoulage.
Migration des téléversements vers S3 pour 'db8015'...
Téléversement des fichiers vers S3...
- Répertorier les fichiers locaux
=> 21 fichiers
- Répertorier les fichiers S3
. => 16 fichiers
- Synchronisation des fichiers vers S3
.....................
Mise à jour des URL dans la base de données...
Suppression des anciennes images optimisées...
Marquage de toutes les publications contenant des lightboxes pour un remoulage...
5 publications ont été marquées pour un remoulage
EXCEPTION : 183 des 206 téléversements n'ont pas été migrés vers S3. Échec de la migration S3 pour la base de données 'db8015'.
/var/www/discourse/lib/file_store/to_s3_migration.rb:127:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:74:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:350:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:61:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:203:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:48:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:30:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:58:in `run'
script/discourse:143:in `restore'
Je ne sais pas pourquoi cela échoue.
La plupart des téléversements étaient déjà sur S3, donc les messages « 200 des 206 téléversements n’ont pas été migrés vers S3 » et « 183 des 206 téléversements n’ont pas été migrés vers S3 » sont incorrects. Le nombre de 21 fichiers locaux est correct, et il y a environ 200 téléversements sur S3 (cela pourrait être 206 également). Je ne reconnais aucun des autres chiffres (183, 16).
Je ne sais pas non plus pourquoi le processus de restauration tente de déplacer davantage de téléversements vers S3 ? Il devrait simplement prendre les images locales de la sauvegarde et laisser les téléversements sur S3 tels quels ? Ou est-ce que je passe à côté de quelque chose ?
Finalement, j’ai fini par modifier manuellement le paramètre enable_s3_uploads dans le dump de la base de données pour le mettre à false, mais cela a entraîné le remappage de tout vers le stockage local. Et comme quelques images étaient encore locales, il a fallu beaucoup de travail pour déterminer lesquelles devaient être remappées vers S3 et lesquelles ne devaient pas l’être.
Le mélange des uploads locaux avec ceux stockés sur S3 n’est pas pris en charge. Oui, je sais, il est possible de se retrouver dans une telle situation lorsqu’un utilisateur passe du stockage local à S3 sans migrer les uploads existants vers S3, mais c’est une autre histoire…
La restauration d’une sauvegarde inclut toujours la réorientation des uploads si le système détecte des modifications affectant les URL des uploads. Cela inclut le passage du mode standalone au multisite, le passage des uploads locaux à S3, ainsi que les modifications des paramètres S3 et CDN. Tous les uploads sont restaurés à l’emplacement correct selon les paramètres, soit localement, soit sur S3.
De temps en temps, nous rencontrons des sauvegardes où la réorientation automatique et la migration vers S3 échouent pour diverses raisons. Vous pouvez vous attendre à voir davantage d’améliorations au début du cycle de développement de la version 2.5.