Je rencontre exactement le même problème lors de la migration depuis le même fournisseur que dans ce fil, mais ce sujet étant clos, je vais bien créer un nouveau thread, car je suis au bout du rouleau en essayant de résoudre ce problème.
voici le journal
[2020-08-30 02:34:59] [DÉMARRÉ]
[2020-08-30 02:34:59] 'username' a démarré la restauration !
[2020-08-30 02:34:59] Marquage de la restauration comme en cours...
[2020-08-30 02:34:59] Vérification de l'existence de /var/www/discourse/tmp/restores/default/2020-08-30-023459...
[2020-08-30 02:34:59] Copie de l'archive vers le répertoire temporaire...
[2020-08-30 02:35:00] Décompression de l'archive, cela peut prendre un moment...
[2020-08-30 02:35:01] Extraction du fichier de sauvegarde...
[2020-08-30 02:35:07] Validation des métadonnées...
[2020-08-30 02:35:07] Version actuelle : 20200820232017
[2020-08-30 02:35:07] Version restaurée : 20191209095548
[2020-08-30 02:35:07] Activation du mode lecture seule...
[2020-08-30 02:35:07] Mise en pause de Sidekiq...
[2020-08-30 02:35:07] Attente jusqu'à 60 secondes pour que Sidekiq termine l'exécution des tâches...
[2020-08-30 02:35:14] Création des fonctions manquantes dans le schéma discourse_functions...
[2020-08-30 02:35:15] Restauration du fichier de sauvegarde..
D’ailleurs, par curiosité, ils avaient pas mal de plugins préinstallés. Devrai-je les installer sur ma nouvelle construction pour que la sauvegarde fonctionne, ou puis-je les installer après coup ?
Une restauration ne échouera pas sans eux, mais il est généralement préférable d’avoir tout en place dans votre app.yml avant d’exécuter la restauration.
Non, cela ne posera pas de problème, la restauration la mettra automatiquement à jour vers la version actuelle.
Dans ce cas, il est fortement recommandé d’installer les extensions avant de restaurer la sauvegarde.
Je n’ai trouvé qu’une seule occurrence de ceci dans le fichier .sql. J’espère que la suppression des parties surlignées devrait suffire. (Je suppose que le premier fait référence à public.spatial_ref_sys)
# Compresser dump.sql et le placer dans le même répertoire que la sauvegarde
gzip dump.sql
# Copier le fichier de sauvegarde vers fixed-* ; remplacez ceci par le nom de votre propre fichier de sauvegarde
cp backupfilename-2020-08-30-123456-v20200830123456.tar.gz fixed-backupfilename-2020-08-30-123456-v20200830123456.tar.gz
# Décompresser
gzip -d fixed-backupfilename-2020-08-30-123456-v20200830123456.tar.gz
# Supprimer le fichier dump.sql.gz original de l'archive.
# Notez que le nom du fichier de sauvegarde ne contient pas .gz à cette étape.
tar f fixed-backupfilename-2020-08-30-123456-v20200830123456.tar --delete dump.sql.gz
# Ajouter le nouveau dump.sql.gz. Notez que le nom du fichier de sauvegarde ne contient pas .gz à cette étape.
tar fr fixed-backupfilename-2020-08-30-123456-v20200830123456.tar dump.sql.gz
# Le recompresser. Notez que le nom du fichier de sauvegarde ne contient pas .gz à cette étape.
gzip fixed-backupfilename-2020-08-30-123456-v20200830123456.tar