Comment sauvegarder et restaurer tout le dossier d'application /var/discourse ?

Comment sauvegarder et restaurer l’intégralité du dossier /var/discourse ?

En raison de problèmes avec le processus habituel de sauvegarde et de restauration, je me demandais s’il était possible de sauvegarder l’intégralité du dossier /var/discourse et de le réutiliser sur un autre serveur. Voici ce que j’ai fait…

Sur le serveur de production :

rsync_opts="\
   --recursive \
   --links \
   --hard-links \
   --safe-links \
   --owner \
   --group \
   --perms \
   --times \
   --delete \
   --sparse \
   --compress \
   --partial \
   --rsh=ssh
"
dir=/var/discourse
rsync  $rsync_opts "$dir/" root@xx.xx.xx.xx:"/var/production-backup/$dir"

Sur le serveur de préproduction :

Installer Docker.

rsync --recursive --links --hard-links --safe-links --owner --group --perms --times --delete --sparse --compress --partial /var/production-backup/var/discourse/ /var/discourse

Mais je reçois une erreur 502 Bad Gateway.

Je tente d’en investiguer la cause.

cd /var/discourse

./launcher start app

root@whonix-app:/var/www/discourse# service postgresql status
12/main (port 5432) : arrêté
root@whonix-app:/var/www/discourse# service postgresql start
[....] Démarrage du serveur de base de données PostgreSQL 12 : main[....] Erreur : Le cluster est détenu par l'identifiant de groupe 116 qui n'existe pas ... échec !
 échec !

Je suppose qu’il faut appliquer quelques correctifs :

chown -R postgres.postgres /etc/postgresql
chown -R postgres.postgres /shared/postgres_*
chown -R postgres.postgres /var/lib/postgresql
chown -R postgres.postgres /var/log/postgresql
chown -R redis.redis /etc/redis/redis.conf
chown -R redis.redis /shared/redis_data
chown -R redis.redis /var/run/redis
chown -R redis.redis /var/lib/redis
chown -R redis.redis /var/log/redis
chgrp -R ssl-cert /etc/ssl/private

Mais cela n’a pas aidé.

root@whonix-app:/var/www/discourse# service postgresql start
[....] Démarrage du serveur de base de données PostgreSQL 12 : main[....] Erreur : /usr/lib/postgresql/12/bin/pg_ctl /usr/lib/postgresql/12/bin/pg_ctl start -D /shared/postgres_data -l /var/log/postgresql/postgresql-12-main.log -s -o -c config_file="/etc/postgresql/12/main/postgresql.conf" s'est terminé avec le statut 1 : 2020-05-25 10:20:10.501 UTC [603] FATAL : les fichiers de la base de données sont incompatibles avec le serveur 2020-05-25 10:20:10.501 UTC [603] DETAIL : Le répertoire de données a été initialisé avec la version 10 de PostgreSQL, qui n'est pas compatible avec cette version 12.2 (Debian 12.2-2.pgdg100+1). pg_ctl : impossible de démarrer le serveur. Examinez le lo[FAILput. ... échec !
 échec !

Pourquoi ces problèmes de permissions de fichiers sont-ils apparus ?

Pourquoi PostgreSQL passe-t-il de la version 10 à la version 12 simplement en copiant l’intégralité du dossier d’un serveur à un autre ? Je dois faire quelque chose de mal.

Pourriez-vous s’il vous plaît partager des instructions sur la façon de sauvegarder l’application Discourse complète sur un serveur et de la déplacer vers un autre serveur ?

Discourse n’utilise pas Phabricator ?

Faute de frappe. Je voulais dire Discourse. La faute de frappe est corrigée. La question d’origine reste inchangée.

Cela ne déplace pas l’ensemble du dossier /var/discourse. Je suis conscient de ces instructions, mais elles ne fonctionnent pas pour moi. C’est pourquoi je souhaitais une méthode de sauvegarde plus « complète », une copie « intégrale » 1 à 1.

Vous pouvez arrêter le conteneur et copier l’ensemble vers un nouveau serveur, en excluant les répertoires tmp, backup et cache (et je crois qu’il y en a un autre ?). Cela devrait fonctionner. Je l’ai fait récemment, je pense pour une raison similaire.

Mais vous devez vraiment résoudre le problème de l’index corrompu.

Je pense que la version de Docker introduit des différences. (Ce qui conduit ensuite à un échec.)

Serveur original
docker-engine 17.05.0~ce-0~debian-stretch

vs serveur plus récent (stage)
docker-engine 17.05.0~ce-0~debian-stretch

Cela se traduit par le fait que le serveur original a la version 10 de PostgreSQL, tandis que le serveur plus récent (stage) a déjà PostgreSQL 12.

Est-ce obligatoire ? Y a-t-il un moyen plus simple ? Pourquoi serait-il nécessaire de ne pas tout copier tel quel et de restaurer ?

Cela entraîne des problèmes de permissions que je ne peux pas expliquer. Il devrait être possible de copier sans altérer les permissions. De plus, je ne suis pas certain d’avoir entièrement résolu tous les problèmes de permissions.

Oui, mais je pense qu’il serait beaucoup plus sûr de ne procéder à cela que lorsque je pourrai au moins reproduire ce qui fonctionne encore actuellement.

Vous ne pouvez pas simplement « archiver avec tar » le répertoire /var/discourse, le déplacer vers une autre machine, le décompresser et lancer l’application Discourse.

L’une des principales raisons est que, lorsque vous construisez / amorcez Discourse, le lanceur (le launcher, si ma mémoire est bonne) vérifie si un conteneur de base Discourse (une image) existe. S’il n’existe pas, il télécharge l’image Docker de base de Discourse et démarre cette image dans un conteneur.

Après ce git pull de base, le processus de construction crée une autre image Docker (l’application).

Ces deux images Docker (l’image de base et l’image de l’application) n’existent pas à l’intérieur de /var/discourse. Ainsi, archiver /var/discourse ne constitue qu’une « solution » partielle (en utilisant ce terme avec réserve).

Ces images Docker de Discourse sont construites en tant qu’images Docker et font partie de l’écosystème Docker ; elles ne « résident » pas dans /var/discourse mais y sont construites, puis déplacées vers Docker sous forme d’images.

Il est peut-être possible de modifier votre fichier YAML de conteneur et de reconstruire tout depuis zéro, mais la méthode la plus courante consiste simplement à sauvegarder :

  • vos fichier(s) YAML de conteneur,
  • votre sauvegarde complète incluant les pièces jointes.

Ensuite, modifiez votre fichier YAML de conteneur, clonez le dépôt discourse-docker et reconstruisez.

Ensuite, restaurez votre sauvegarde complète, y compris les pièces jointes (via la ligne de commande dans le conteneur).

Utiliser GitHub comme dépôt est une solution plus propre que l’ancienne méthode « à l’ancienne façon Unix » consistant à « archiver tout le bazar » et à « déplacer tout le bazar » vers un autre serveur. Cependant, même avec cette « vieille méthode Unix », cette approche n’offre souvent pas une solution complète, car il existe souvent des bibliothèques partagées dans le système, des répertoires d’utilisateurs de bibliothèques partagées, et plus encore, qui ne font pas partie du répertoire de distribution, ainsi que des fichiers dans /etc qui ne se trouvent pas dans le répertoire racine de la distribution, etc.

Ainsi, même sur la plupart des systèmes Linux modernes, nous utilisons apt (sur Ubuntu, par exemple) pour récupérer le dépôt. Dans le cas de Discourse Docker, vous récupérez (et construisez) discourse-docker pour configurer le conteneur de base, et un autre dépôt Discourse pour construire l’application. Donc, /var/discourse est un « lieu de construction » (des images) et un « lieu de partage » (des données, des sauvegardes, des fichiers statiques publics, etc.).

J’espère que ce résumé vous a été utile, ne serait-ce que légèrement.

Bien sûr, vous pouvez tout copier avec rsync -rav.

Vous aurez peut-être plus de chances si vous modifiez votre application pour utiliser le modèle PostgreSQL 10. Mais il semble que la solution la plus simple soit peut-être de simplement réparer votre base de données sur place.

Vous pouvez déplacer le dossier, cela fonctionne bien. Ce n’est tout simplement pas la méthode préférée, car cela contourne discourse-setup ainsi que tous les réglages et tests qu’il exécute en cours de route.

Cela n’a pas fonctionné dans mon cas car la mise à niveau de Docker a entraîné une version plus récente de PostgreSQL à l’intérieur du conteneur Docker, ce qui a rendu le forum inutilisable en raison de problèmes de migration PostgreSQL. J’ai dû passer de Postres au modèle PostgreSQL 10.

How to backup and restore a whole /var/discourse app folder? - #8 by neounix explique bien les détails.

Je pense que je devrais également sauvegarder et restaurer le dossier /var/docker. Mais même cela risque d’échouer à cause de ceci :

Vous partez dans une impasse.
Si j’étais vous, je me concentrerais sur la résolution de votre problème initial concernant la sauvegarde et la restauration.

Peut-être même un trou de :rat: :rat: :rat:.

D’accord… tout à fait…

@adrelanos

Il n’y a aucun « problème » avec le processus de sauvegarde-restauration. Voyez cet « éloge » que votre humble serviteur @neounix a rédigé il y a quelques mois sur ce sujet :

Cher @adrelanos,

Pour revenir à votre question initiale dans le message #1 ci-dessus, étant naturellement curieux, je n’étais pas vraiment satisfait de ma réponse précédente et j’ai effectué quelques tests aujourd’hui.

En bref, j’ai confirmé que nous pouvons utiliser docker save (pour les conteneurs de base et d’application) et tar pour le répertoire /var/discourse, permettant ainsi de sauvegarder, transférer (sauvegarde) et restaurer complètement l’application de cette manière.

Je suis presque certain (à 99,99 %) que cette méthode n’est pas officiellement prise en charge, mais vous méritez une réponse, alors je l’ai testée pour vous :

Voici essentiellement les étapes, en résumé :

  1. Sauvegardez vos conteneurs avec docker save.

Par exemple, si vous exécutez une application autonome, vous pouvez sauvegarder les conteneurs de base et d’application, comme ceci (selon votre configuration) :

docker save -o /tmp/my.discourse.docker.app.tar  discourse/base:2.0.20200512-1735

et aussi :

docker save -o /tmp/my.discourse.docker.app.tar local_discourse/app:latest  
  1. Vous pouvez également archiver le répertoire /var/discourse, comme vous l’avez mentionné :
cd /var/
tar -cvzf /tmp/my.var.discourse.tar.gz discourse

Ensuite, compressez vos fichiers tar Docker si vous le souhaitez et archivez-les :

gzip /tmp/my.discourse.docker*.tar
  1. … et vous pouvez déplacer ces fichiers vers un autre serveur, les archiver sur le même serveur, faire ce que vous voulez, inverser les étapes et démarrer l’application Discourse sans problème.

Je l’ai confirmé en « le faisant », en supprimant toutes les images de conteneurs et le répertoire /var/discourse. En gros, j’ai tout effacé et redémarré (pas besoin de reconstruire puisque le domaine n’a pas changé, etc.) à partir des sauvegardes.

Par exemple, pour restaurer, vous pouvez prendre les images Docker sauvegardées ci-dessus et les charger, par exemple :

gzip -d /tmp/my.discourse.docker.app.tar.gz
docker load -i /tmp/my.discourse.docker.app.tar

gzip -d /tmp/my.discourse.docker.base.tar.gz
docker load -i /tmp/my.discourse.docker.base.tar
  1. Ensuite, décompressez votre répertoire original /var/discourse :
cd /var
tar -xvzf /tmp/my.var.discourse.tar.gz
  1. Ensuite, vous devez vérifier vos images pour vous assurer qu’elles sont correctement étiquetées :
docker images
  1. Et si les images ne sont pas correctement étiquetées, assurez-vous de les taguer correctement, par exemple pour votre image d’application :
docker tag 58ffc74989af local_discourse/app:latest
  1. Ensuite, faites simplement ceci :
cd /var/discourse
./launcher start app

et tout fonctionne parfaitement. Je l’ai testé (deux fois).

J’espère que cela vous aidera.

Pour information : J’ai essayé cette méthode de deux manières différentes, en effectuant la méthode de sauvegarde ci-dessus, en supprimant tous les conteneurs Docker, les images et le répertoire /var/discourse (en détruisant tout, à chaque fois).

Dans chaque cas, j’ai pu charger mes images Docker sauvegardées, décompresser le répertoire /var/discourse, exécuter ./launcher start app et Discourse a démarré sans faille. Pour le prouver, j’ai pu effectuer une sauvegarde normale depuis l’interface utilisateur, prouvant que tout était en ordre.

Je ne sais pas si cela répond à votre question (et je n’ai pas participé à la mise à niveau ou aux discussions de Postgres 10 vers 12) ; mais concernant votre question de simplement archiver l’application comme sauvegarde et la restaurer, la réponse est oui, mais vous devez non seulement archiver le répertoire /var/discourse, mais aussi docker save vos images.

Le principal « piège » est de garder le nom du référentiel d’images et les balises corrects, et vous devriez être bon.

J’espère que cela répond, d’une certaine manière, à votre question sur :

Comment sauvegarder et restaurer tout le dossier d’application /var/discourse ?

La réponse est que vous devez archiver à la fois votre dossier et vos images Docker (comme dans l’exemple ci-dessus) en utilisant docker save pour les images (pour la sauvegarde) et docker load pour la restauration.

Gardez à l’esprit que cette méthode n’est pas officiellement prise en charge ; mais par curiosité, je voulais voir comment le faire du point de vue de l’administrateur système, et j’ai découvert que c’était plus facile que ce que mes réponses précédentes indiquaient.

Note 1 :

Vous voudrez peut-être déplacer toutes les sauvegardes de votre répertoire backups/default (hors de l’arborescence) avant d’archiver tout dans /var/discourse/ et de conserver ces sauvegardes (séparément), car ces fichiers sont si volumineux…

Note 2 :

Ce type de sauvegarde n’est pas pris en charge et n’est donc pas recommandé pour la plupart des administrateurs système Discourse. Je recommande aux utilisateurs de suivre la méthode de sauvegarde et de récupération Discourse recommandée (et officiellement prise en charge).

Restez curieux !

Prenez soin de vous.


Pour plus de détails, y compris des captures d’écran, veuillez consulter mon message complet ici :

C’est une excellente approche ! Merci !

Un problème sur le serveur de restauration.

./launcher logs app

2020-06-18 13:33:56.434 UTC [127] FATAL: le répertoire de données “/shared/postgres_data” a un propriétaire incorrect
2020-06-18 13:33:56.434 UTC [127] HINT: Le serveur doit être démarré par l’utilisateur qui possède le répertoire de données.
./run: 3: echo: echo: Erreur E/S
2020-06-18 13:33:57.448 GMT [128] LOG: fichier de configuration manquant ignoré “/shared/postgres_data/postgresql.auto.conf”


Cela pourrait être dû à l’absence de certaines options tar ? J’ai ajouté -p et -s lors de l’extraction, mais cela n’a pas aidé.

Serveur d’origine (hors docker) :

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 4096 May 25 13:16 base

Serveur d’origine (dans docker (./launcher enter app)) :

ls -la /var/lib/postgresql/10/main/

drwx------ 5 root postgres 4096 May 25 23:28 base


Serveur de restauration hors docker :

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 71 May 25 11:16 base

Serveur de restauration dans docker :

drwx------ 5 root postgres 41 May 25 23:28 base


./launcher rebuild app pourrait régler le problème, mais ce n’est pas l’objectif ici.

Une idée ?

Je pense que vous vouliez dire docker save -o /tmp/my.discourse.docker.base.tar discourse/base:2.0.20200512-1735, en fonction de votre processus de restauration. En tout cas, excellente explication !

Cependant, comme vous l’avez dit, je ne pense pas que ce soit une approche officiellement prise en charge (mais je ne pense pas non plus qu’il y ait autre chose qui puisse causer des erreurs, sauf si l’équipe de Discourse commence à utiliser plus d’une image de base dans le processus de reconstruction).

Il semble que le même problème se soit produit ici :

https://meta.discourse.org/t/postgresql-12-update/151236/298?u=lucasbasquerotto

Il n’y a pas de réponse à ce problème spécifique dans les FAQ, mais l’équipe Discourse pourrait ajouter une solution, étant donné que plus d’une personne y a été confrontée. Il existe une FAQ sur Le cluster source n’a pas été arrêté proprement, qui pourrait être liée à votre problème.

Une méthode que j’ai utilisée et qui n’implique ni docker save ni un tar+untar complet de /var/discourse :