Impossible d'utiliser une restauration depuis NodeChef

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..

Cette table ne fait pas partie de Discourse, donc je suppose que c’est une spécificité de NodeChef ?

En tout cas, vous devrez modifier votre fichier de sauvegarde et supprimer les données et les références de cette table.

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.

Ma sauvegarde provient également d’une version antérieure, cela va-t-il poser des problèmes ?

Que voulez-vous dire par version antérieure ? Quelle est son ancienneté ?

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)

Par ailleurs, comment remplacer le fichier dump.sql à l’intérieur du fichier tar.gz par celui modifié ?

# 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

Merci @RGJ, mon site est de nouveau opérationnel et fonctionne parfaitement. Il ne reste plus qu’à réinstaller quelques plugins.

Merci aussi infiniment à toi @Falco pour m’avoir aidé à identifier le problème dès le départ.