Sauvegarde générée par l'interface utilisateur et restauration du site

Bonjour Discourse,

La nuit dernière, j’ai tenté de mettre à jour Discourse et de reconstruire l’application, ce qui a entraîné une série d’erreurs Postgres. J’ai réalisé que cela était dû à la récente mise à niveau, mais j’ai continué à rencontrer des erreurs de permission refusée, entre autres (et oui, j’ai bien exécuté chown sur tous les fichiers avec les permissions 700, donc ce n’était pas accessible globalement). J’ai donc déplacé mon répertoire /var/discourse original vers un emplacement censé être temporaire et réinstallé une instance fraîche de Discourse pour essayer, au moins, de mettre à jour Postgres.

C’est là que ça devient intéressant. J’avais une sauvegarde du site (base de données uniquement, les fichiers uploadés sont stockés sur un volume différent) générée via l’interface utilisateur il y a trois jours. Ou du moins, c’est ce que je croyais. Ce que j’ai maintenant, c’est un fichier nommé wacky-writers-forum-2021-04-06-033906-v20210328233843.sql.gz, et il semble que j’ai appris qu’il ne s’agit pas, en réalité, du fichier tar.gz dans lequel la sauvegarde réelle devrait se trouver.

Actuellement, j’ai redirigé tout le monde vers une page d’atterrissage, et j’espère que quelqu’un pourra me confirmer qu’il est toujours possible de récupérer le vrai fichier .tar.gz depuis le serveur d’il y a trois jours, et m’expliquer exactement comment procéder.

Mes sauvegardes et uploads sont stockés sur le stockage par blocs de Digital Ocean, et j’ai toujours le dossier discourse de mon ancienne installation fonctionnelle. Cependant, le déplacer ou le copier à nouveau vers /var/discourse fait tout casser à nouveau, y compris des erreurs Postgres. Je travaille sur ce problème depuis neuf heures d’affilée et je suis à bout de souffle. Quelqu’un peut-il m’aider, ou du moins m’orienter dans la bonne direction ? :pray: Nous venons d’atteindre le cap des 1 000 utilisateurs, et j’aimerais vraiment éviter de tout perdre.

Édité pour préciser ma configuration d’upload.

Si vous avez votre configuration S3 dans app.yml, vous pouvez simplement effectuer une restauration en ligne de commande et elle récupérera la sauvegarde depuis S3.

Puisque vos assets sont stockés sur S3, la sauvegarde ne contient que la base de données.

Vous devriez pouvoir cloner un nouveau /var/discourse, copier votre fichier yml, reconstruire et effectuer la restauration en ligne de commande.

Utiliser un stockage objet pour les uploads (S3 et clones)

Restaurer une sauvegarde depuis la ligne de commande

Je suppose que j’utilise le mauvais terme pour décrire la configuration de mes sauvegardes/téléversements. J’ai utilisé cette méthode : Move Uploads and Backups to DigitalOcean Block Storage

Je vais donc préciser que mes téléversements et sauvegardes ne sont pas stockés localement dans le dossier principal de Discourse (c’est en partie ce qui a déclenché tout cela, je travaillais sur la migration vers DigitalOcean Spaces). Donc, non, malheureusement, je n’ai aucune configuration S3 en place, car je sauvegardais simplement sur un stockage monté.

Les sauvegardes étaient enregistrées dans mnt/my_storage/shared/standalone, mais lorsque j’essaie de les consulter à cet endroit, je ne trouve que le fichier wacky-writers-forum-2021-04-06-033906-v20210328233843.sql.gz. J’ai effectivement tenté de restaurer à partir de ce fichier par défaut d’une meilleure idée (ce qui était probablement une erreur), mais j’ai reçu une erreur de « permission refusée ». Je suis sûr que cela est lié à la façon dont ces sauvegardes sont réellement générées.

Vos uploads sont-ils toujours sur le stockage de blocs DO ?

Oui, tous les téléchargements sont intacts.

Ok, c’est noté.

Dans ce cas, vous devriez pouvoir restaurer le fichier SQL, puis réattacher le volume de stockage en bloc pour récupérer vos fichiers uploadés.

Il existe deux types de sauvegardes : sql.gz, qui n’inclut pas les uploads, et tar.gz, qui les inclut. Vous aviez donc le mauvais type de sauvegarde, mais le fait que vos uploads soient sur un volume externe vous a sauvé la mise.

2 « J'aime »

Donc j’entre dans l’application et je restaure ce fichier sql.gz, mais j’obtiens une erreur de « permission denied ». Avez-vous une idée de la raison ?

Vous parlez ! :slight_smile:

(En supposant que vous parliez de chmod). Si les fichiers ont le mauvais propriétaire, ils ne sont pas modifiables.

Je pense que cela a provoqué l’erreur « permission refusée ».

Quelle est l’erreur exacte ?

Oui, merci, je suis réveillé toute la nuit et un peu vidé.

EXCEPTION : lib/discourse.rb:93:in `exec' : Échec de la copie de l'archive vers le répertoire tmp.
cp : impossible d'ouvrir '/var/www/discourse/public/backups/default/wacky-writers-forum-2021-04-06-033906-v20210328233843.sql.gz' en lecture : Permission refusée

Essayez chmod 644 /var/www/discourse/public/backups/default/*

2 « J'aime »

D’accord, je suis en train d’avancer là-dessus, je reviens vers vous sous peu. Merci d’avoir pris le temps de m’aider.

Cela a fonctionné pour lancer la restauration, MERCI. :pray:

Il ne me reste plus qu’à comprendre pourquoi le site ne se charge toujours pas. :grimacing:

La reconstruction est actuellement en cours avec le fichier app.yml sauvegardé avant que tout ne se casse.

1 « J'aime »

Existe-t-il une commande pour déplacer directement cette sauvegarde dans l’application ? La restauration ne la trouve pas et je ne me souviens plus comment je l’ai chargée auparavant.

Vous pouvez le télécharger depuis S3 et le placer dans

/var/discourse/shared/standalone/backups/default

Vous devriez pouvoir effectuer une restauration en ligne de commande.

Cependant, après cela, vous devez configurer votre paramétrage S3 comme décrit dans le lien ci-dessus ; cela facilite les choses.

2 « J'aime »

Merci, Jay. Et oui, c’est absolument mon plan.

1 « J'aime »

Bon, voici où j’en suis maintenant.

  • La restauration depuis ce fichier .sql.gz a réussi. (hourra ! Merci encore, Richard.)
  • J’ai vérifié que app.yml était configuré exactement comme avant la panne.
  • ./launcher rebuild app
  • La reconstruction s’est déroulée avec succès sous Postgres 13 (enfin !)

Cependant, le site lui-même est toujours inaccessible. J’utilise Cloudflare, mais j’ai activé le mode Développement pour l’instant et vidé le cache DNS. Tout pointe vers l’endroit où il devrait. Le modèle Cloudflare est bien présent dans app.yml.

La résolution DNS fonctionne correctement, les noms d’hôte sont à jour, l’installation de Discourse a été faite avec l’URL appropriée, et je commence à manquer d’idées.

https://forum.wackywriters.com est l’URL, mais je reçois uniquement des erreurs de type « serveur indisponible ». J’ai l’impression de tourner en rond (désolé), mais avez-vous des suggestions ?

Édit : Lorsque j’exécute ./discourse-doctor, je constate qu’il y a deux instances de l’application en cours d’exécution dans Docker :

Est-ce normal ? (Ça ne devrait pas l’être, mais tout ce que je croyais savoir sur Discourse a été remis en question au cours des 24 dernières heures :sweat_smile:)

Édit2 : J’ai repoussé cette option jusqu’au dernier moment, mais je vais essayer de configurer un tout nouveau serveur avec une installation propre de Discourse. Je crains que quelque chose ne soit complètement cassé à force de bricoler, et je n’arrive pas à identifier le problème. Heureusement, j’ai toujours la sauvegarde et tous les fichiers uploadés sur le stockage en blocs. Si j’ai de la chance, je devrais pouvoir les connecter à un nouveau droplet et tout transférer depuis là. Si quelqu’un a d’autres suggestions ou conseils, je serais ravi de bénéficier de votre expertise, bien plus expérimentée que la mienne.

Édit3 : Même avec un nouveau serveur et une propagation de l’adresse IP (nslookup et ping semblent corrects, whatsmydns.net aussi), le forum ne se charge toujours pas. Je reçois toujours des erreurs de connexion. On dirait que l’adresse IP n’est pas associée à l’instance Discourse et qu’au lieu de cela, il tente de charger une page statique, qui, bien sûr, n’existe pas dans ce cas.

Alors, après près de 24 heures de combat, j’ai compris pourquoi le site refusait de se charger une fois la restauration lancée.
:point_down:

À force de réinitialisations, de réinstallations et d’autres choses encore, j’ai atteint la limite de débit. J’ai donc temporairement commenté les modèles SSL et je les réactiverai dans une semaine.

Le site « fonctionne » pendant que je régénère tous les messages pour corriger les images cassées, mais j’apprécie vraiment l’aide de Jay et Richard aujourd’hui ; vous m’avez aidé à surmonter les parties que je n’arrivais vraiment pas à comprendre.

Maintenant, il faut télécharger une vraie sauvegarde pour que je puisse configurer S3 cette semaine sans avoir à m’en faire à nouveau. :sweat_smile:

1 « J'aime »

Si vous recherchez, il existe un moyen d’ajouter un deuxième domaine afin qu’il soit considéré comme une demande distincte pour Let’s Encrypt. Mais attendre est plus simple.

Je vous recommande de mettre Cloudflare en mode nuage gris, sans les accélérations.

1 « J'aime »

@pfaffman Ne confondez-vous pas le stockage objet avec le stockage par blocs ? Le stockage objet, c’est S3, mais TS indique qu’ils ont utilisé le stockage par blocs, qui est simplement un disque monté dans leur répertoire d’uploads :

1 « J'aime »

Oh. :man_facepalming:

Oui. Donc tout ce que j’ai dit n’a aucun sens.

Merci de l’avoir remarqué, Richard.

2 « J'aime »

Eh bien, la plupart des choses que tu as dites avaient du sens, mais tu m’as un peu confondu ici :slight_smile:

2 « J'aime »