Modification de la base de données dans une sauvegarde pour supprimer une balise de clé dupliquée afin qu'elle ne échoue pas lors de la restauration

Ceci est une version très condensée de mes dernières 24 heures, bien que cela n’ait pas encore fonctionné, j’espère donc que quelqu’un pourra poster où cela a mal tourné ci-dessous.

Ma mise à jour Discourse a échoué en raison d’une clé dupliquée, l’une de mes balises est doublée. Pour résoudre le problème de mise à jour, j’ai dû effectuer une nouvelle installation de Discourse, puis charger ma dernière sauvegarde, mais le rechargement échoue car il se bloque sur la clé dupliquée. J’ai donc dû aller à l’intérieur de la sauvegarde pour modifier la balise fautive en quelque chose de différent.

Pour une raison quelconque, la sauvegarde recompressée avec le problème de balise dupliquée corrigé est nettement plus petite que la sauvegarde d’origine, et échoue lorsque j’essaie de la restaurer, donc quelque chose s’est mal passé avec le processus de recompression.

1) Localisation des sauvegardes : Pour localiser vos sauvegardes Discourse, vous pouvez utiliser la commande suivante :

sudo find / -name "*.tar.gz"

Cela recherchera sur votre système tous les fichiers de sauvegarde avec l’extension “.tar.gz”. Par défaut, il devrait se trouver à l’intérieur de votre conteneur à : shared/backups/default

2) Création d’une copie : Une fois que vous avez trouvé la sauvegarde avec laquelle vous souhaitez travailler, créez une copie de celle-ci pour vous assurer d’avoir une sauvegarde du fichier d’origine. Utilisez la commande “cp” :

bash

sudo cp /chemin/vers/sauvegarde_originale.tar.gz /chemin/vers/copie_sauvegarde.tar.gz

3) Extraction de la copie : Extrayez le contenu du fichier de sauvegarde copié à l’aide de la commande “tar” :

bash

tar -xzvf /chemin/vers/copie_sauvegarde.tar.gz

Cela extraira les fichiers de sauvegarde dans un répertoire temporaire.

4) Modification des balises dans la base de données : Naviguez vers les fichiers de sauvegarde extraits et ouvrez le fichier de base de données pertinent à l’aide d’un éditeur de texte. J’ai rencontré un problème avec des balises “socialmedia” dupliquées, ce qui a empêché une restauration réussie. Dans une grande base de données, il y a de nombreuses instances de balises, et probablement pour la balise spécifique que vous recherchez, j’ai donc recherché ‘immutable socialmedia’ en utilisant Ctrl W dans Nano, ce qui m’a mené directement là-bas.

sudo nano /chemin/vers/base_de_donnees_extraite.sql

J’ai modifié une instance de la balise “socialmedia” en “socialmedia2”, puis j’ai effectué une recherche rapide pour vérifier qu’elle n’apparaît plus qu’une seule fois. Je peux corriger ces balises depuis la section administration une fois que la restauration réussit.

5) Recompression : Après avoir modifié les fichiers de sauvegarde, créez un nouveau fichier de sauvegarde avec le contenu corrigé. Utilisez la commande suivante pour compresser les fichiers modifiés :

tar -czvf /chemin/vers/nouvelle_sauvegarde_modifiee.tar.gz /chemin/vers/repertoire_fichiers_modifies

6) Déplacement vers le bon fichier : Déplacez le nouveau fichier de sauvegarde modifié vers le répertoire approprié où les sauvegardes sont stockées. L’emplacement par défaut est généralement “/shared/backups/default” :

sudo mv /chemin/vers/nouvelle_sauvegarde_modifiee.tar.gz /shared/backups/default/

7) Arrêt et redémarrage des services : Avant de restaurer la sauvegarde modifiée, assurez-vous d’arrêter les services pertinents pour éviter tout conflit potentiel pendant le processus de restauration. Utilisez la commande “./launcher stop app” pour arrêter l’application Discourse :

./launcher stop app

8) Restauration de la sauvegarde : Pour restaurer à partir de la sauvegarde modifiée, utilisez la commande “discourse restore” avec le chemin d’accès au nouveau fichier de sauvegarde :

discourse restore /shared/backups/default/nouvelle_sauvegarde_modifiee.tar.gz

Ou vous pouvez le faire via /admin sur votre site car il devrait maintenant apparaître dans la section des sauvegardes.

9) Vérification de la restauration : Une fois le processus de restauration terminé, j’ai vérifié que les modifications avaient été effectuées avec succès en examinant l’application et la base de données Discourse pour m’assurer que les balises “socialmedia” dupliquées avaient été supprimées.

10) Démarrage des services : J’ai redémarré les services qui avaient été arrêtés précédemment pour remettre l’application Discourse en ligne. J’ai utilisé la commande “./launcher start app” pour démarrer l’application Discourse :

./launcher start app

11) Suppression des fichiers temporaires et des sauvegardes supplémentaires : Après avoir restauré la sauvegarde avec succès, j’ai supprimé tous les fichiers temporaires et les sauvegardes supplémentaires qui avaient été créés pendant le processus pour libérer de l’espace disque. Utilisez la commande “rm” pour supprimer les fichiers :

sudo rm -r /chemin/vers/repertoire_temporaire
sudo rm /chemin/vers/copie_sauvegarde.tar.gz
3 « J'aime »

Pourquoi ?

Pourquoi n’avez-vous pas pu résoudre ce problème « en ligne » en redémarrant l’application, en entrant dans le conteneur, en entrant dans postgres, puis en traitant immédiatement la saisie des données ?

1 « J'aime »

Je ne m’attendais pas à l’erreur, j’avais donc déjà mis la nouvelle version de Discourse sur mon serveur. L’erreur de clé en double se trouvait dans la sauvegarde et non dans l’application fraîchement installée, mais je ne pouvais pas restaurer la sauvegarde car elle nécessitait que l’erreur soit corrigée au préalable.

J’ai donc dû essayer de modifier la balise à l’intérieur de la sauvegarde.

Mais vous avez vu l’erreur lors de la mise à jour ?

La prochaine fois, facilitez-vous la vie et corrigez sur place.

L’application ne fonctionnait pas et je ne pouvais pas la recharger, j’ai donc mis à jour vers une nouvelle version de Discourse dans le but de résoudre ce problème. Ce qui signifiait que je n’avais accès à la base de données nulle part ailleurs qu’à la sauvegarde.

C’est certainement un cas de niche que j’ai posté ici, la meilleure option aurait été de remarquer le problème et de le résoudre pendant que j’avais encore un accès direct à la base de données de l’application, mais je l’ai manqué et je n’ai trouvé aucune autre option.

1 « J'aime »

Pas de soucis. Au moins, vous avez montré que c’était possible, appris de nouvelles choses et donné une option supplémentaire à d’autres.

Bon travail ! :clap:

3 « J'aime »

Merci, bien que le fichier d’origine faisait 128 Mo et le nouveau 29 Mo, je pense donc que la recompression sur le serveur a peut-être tronqué le fichier en raison de sa longueur.

Ce processus semble fonctionner, mais le fichier que j’ai obtenu n’a pas pu être utilisé pour restaurer mon discourse.

1 « J'aime »

Le chemin que vous avez emprunté était plus risqué mais certainement réalisable ? Peut-être que quelqu’un pourra donner des conseils sur ce problème.

Vous pouvez sans doute recommencer à partir de la sauvegarde, donc…

1 « J'aime »

Ce problème est-il résolu ? Il semble s’agir d’un tutoriel, mais votre site semble toujours en panne.

Peut-être faites-vous quelque chose que je ne comprends pas, mais généralement, vous pouvez simplement faire un ./launcher start app pour démarrer l’ancien conteneur, y avait-il une raison pour laquelle vous ne pouviez pas le faire ?

Ensuite, vous pouvez utiliser des outils Rails ou SQL pour réparer votre base de données sur l’ancien conteneur, puis réessayer d’exécuter le bootstrap/rebuild.

Ou peut-être avez-vous migré la base de données au-delà de ce que votre ancien conteneur pouvait gérer.

J’ai déjà effectué des opérations similaires sur une sauvegarde lorsque le site en cours de restauration était vieux d’un an ou plus. Je pense que le dump de la base de données était suffisamment petit pour que je puisse l’éditer dans vim.

1 « J'aime »

Merci de votre réponse.

Il a refusé de démarrer car nous avions quelques mises à jour de retard, j’ai donc mis à jour vers la dernière version de Discourse en en créant une nouvelle et en téléchargeant notre ancienne sauvegarde, mais elle a rejeté cette sauvegarde en raison des clés en double.

Ou peut-être avez-vous migré la base de données au-delà de ce que votre ancien conteneur pouvait gérer.

Oui, probablement. C’est un peu flou maintenant exactement ce que j’ai fait, mais j’ai mis à jour quelques éléments indépendamment en suivant les conseils de dépannage trouvés ici. L’une de ces choses était d’obtenir la version la plus récente de PostgreSQL.

J’ai pu le modifier dans vim.

J’ai pu le modifier dans Nano, et tout semblait bon, mais le fichier recompressé était beaucoup trop petit, donc quelque chose s’est mal passé quelque part… peut-être que je n’ai pas pu le modifier dans Nano. Cela semblait avoir fonctionné à l’époque.

J’espérais que quelqu’un verrait une erreur et me corrigerait, afin que cela devienne un guide pratique.

Ce que je regarderais ensuite :

  • Refaire tout le dézippage. Zippez-le sans modification. Vérifiez que la taille du zip est la même qu’auparavant. Sinon, peut-être que vous ne zippez pas avec les mêmes options ?

  • Dézippez à nouveau, vérifiez la taille du fichier que vous éditez. Modifiez-le, enregistrez-le, confirmez que la taille n’a pas changé de manière significative.

1 « J'aime »

Une petite mise à jour. Quelqu’un d’autre dans mon équipe travaillait sur cela la semaine dernière mais une solution n’est pas venue, alors j’ai essayé à nouveau, cette fois en modifiant la base de données sur mon système local.

Ce que j’ai fait :

  1. téléchargé une ancienne sauvegarde que je veux restaurer
  2. décompressé les fichiers avec 7zip
  3. ouvert dump.sql avec visual studio code
  4. trouvé les tags dupliqués directement dans la base de données.
  5. trouvé ce qui semblait être la liste des tags en recherchant avec des guillemets autour du tag. Dans mon cas ‘socialmedia’. Les tags semblent être les 2ème et 3ème en partant du bas des instances trouvées.

  1. modifié l’un d’eux pour lire

132 ‘socialmedia2’:1A socialmedia2 en_GB 3

  1. Recompressé le fichier dump.sql dans 7zip
  • Ajouter à l’archive
  • Format d’archive .gzip
  1. Recompressé le fichier de sauvegarde principal
  • Ajouter à l’archive
  • Format d’archive .tar (gzip n’est pas encore disponible)
  1. Vous devriez maintenant voir un fichier de sauvegarde .tar compressé et corrigé

  2. Compresser le fichier .tar dans 7zip pour créer un fichier .tar.gz, afin de correspondre au format utilisé par Discourse

  • Ajouter à l’archive
  • Format d’archive .gzip
  1. Télécharger dans les sauvegardes et restaurer via la section administrateur

À ce stade, j’ai rencontré un message d’erreur :

Extraction du fichier de sauvegarde…
[2023-08-08 15:09:15] EXCEPTION: Aucun fichier ou répertoire de ce type @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

Quelqu’un a-t-il une idée de ce que j’ai manqué dans le processus ci-dessus ?
La seule chose à laquelle je peux penser est que le chemin qu’il recherche utilise la date d’aujourd’hui et non la date de la sauvegarde (je l’écris le 08-08-2023).

Ceci est un suivi de mon précédent message ici. Je poste à nouveau pour que ce soit plus facile à trouver pour toute autre personne faisant cela à l’avenir si cela fonctionne.

Ce que j’ai fait pour modifier la base de données sur mon ordinateur portable :

  1. téléchargé l’ancienne sauvegarde que je veux restaurer depuis la section admin
  2. décompressé les fichiers avec 7zip
  3. ouvert dump.sql avec Visual Studio Code
  4. trouvé les tags dupliqués directement dans la base de données.
  5. trouvé ce qui semblait être la liste des tags en recherchant avec des guillemets autour du tag. Dans mon cas, ‘socialmedia’. Les tags semblent être les 2ème et 3ème à partir du bas des instances trouvées.

  1. modifié l’un d’eux pour lire

132 ‘socialmedia2’:1A socialmedia2 en_GB 3

  1. Recompressé le fichier dump.sql dans 7zip
  • Ajouter à l’archive
  • Format d’archive .gzip
  1. Recompressé le fichier de sauvegarde principal
  • Ajouter à l’archive
  • Format d’archive .tar (gzip n’est pas encore disponible)
  1. Vous devriez maintenant voir un fichier de sauvegarde .tar compressé et corrigé.

  2. Compresser le fichier .tar dans 7zip pour créer un fichier .tar.gz, afin de correspondre au format utilisé par Discourse

  • Ajouter à l’archive
  • Format d’archive .gzip
  1. Télécharger dans les sauvegardes et restaurer via la section admin

À ce stade, j’ai rencontré un message d’erreur :

Extraction du fichier dump…
[2023-08-08 15:09:15] EXCEPTION: Aucun fichier ou répertoire de ce type @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

Quelqu’un a-t-il une idée de ce que j’ai manqué dans le processus ci-dessus ?
La seule chose à laquelle je peux penser est que le chemin qu’il recherche utilise la date d’aujourd’hui et non la date de la sauvegarde (je l’écris le 08-08-2023).

1 « J'aime »

Je pense que le nom exact d’un fichier de sauvegarde est important : nom du forum, date et horodatage, identifiant de version. Donc, si vous décompressez, modifiez et recompressez, je suggérerais de reconstruire sous le même nom que l’original. Mais gardez l’original en sécurité, bien sûr.

1 « J'aime »

J’ai combiné les messages du nouveau sujet dans celui-ci, car il semble que le fait de garder ce problème regroupé en un seul endroit le rendra beaucoup plus facile à suivre pour les futurs voyageurs. :+1:

1 « J'aime »

Merci @Ed_S, j’ai conservé le nom d’origine car j’avais lu ailleurs que c’était important. Ma question ci-dessus porte sur la raison pour laquelle l’outil de restauration de sauvegarde recherchait et ne trouvait pas : /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

qui est la date à laquelle j’effectuais la restauration.

1 « J'aime »

Ah, désolé. Cela semble étrange. Il se peut que le répertoire temporaire soit censé porter le nom de la date du jour, mais il n’est pas bon que le fichier de vidage sql ne soit pas trouvé.

Si vous listez le contenu du fichier tar, voyez-vous ce nom de fichier ? Dans mon cas

root@ubuntu-2gb-nbg1-1:/var/discourse/shared/standalone/backups/default# tar vtfz forumname-2023-08-03-HHMMSS-v2023mmddhhmmss.tar.gz dump.sql.gz | head
-rw-r--r-- discourse/www-data 16336925 2023-08-03 05:31 dump.sql.gz
1 « J'aime »

Merci Ed, ce fichier n’existait pas. Désolé pour le retard, j’étais hors réseau depuis un moment.

Il n’y a pas de fichier portant le bon nom ici, j’ai donc juste essayé d’en créer un vide manuellement :

sudo mkdir -p /var/www/discourse/tmp/restores/default/2023-08-22-121010/

Mais à chaque fois que j’appuie sur restaurer, il recherche un fichier légèrement différent (les 6 derniers chiffres). Je suppose qu’il recherche un dossier généré par un horodatage, donc chaque fois que j’appuie sur le bouton de restauration, le dossier qu’il recherche a changé.

Je soupçonne que quelque chose ne va pas dans votre étape 10 où vous créez le fichier tar. Pouvez-vous le voir ? Pouvez-vous utiliser file pour le décrire ? Pouvez-vous en lister le contenu avec tar tvfz ?

1 « J'aime »