Restaurer une sauvegarde depuis la ligne de commande

[Discourse]

Ce guide explique comment restaurer une sauvegarde Discourse depuis la ligne de commande sans utiliser l’interface utilisateur web de Discourse.
Niveau d’utilisateur requis : Administrateur
Accès à la console requis

Voici comment restaurer une sauvegarde Discourse depuis la ligne de commande, sans jamais démarrer l’interface utilisateur web de Discourse. Ceci est utile lorsque vous déplacez des serveurs.

Prérequis

Avant de commencer, assurez-vous d’avoir effectué les étapes suivantes :

1. Téléchargez le dernier fichier de sauvegarde depuis l’instance Discourse source.
2. Initialisez l’instance Discourse de destination en exécutant ./discourse-setup ou en copiant votre app.yml existant.
3. Assurez-vous que l’instance Discourse de destination est à jour. Mettez-la à jour si nécessaire.

Transférer la sauvegarde

1. Connectez-vous en SSH au serveur de destination, ou créez le dossier de sauvegarde là-bas de toute autre manière :

mkdir -p /var/discourse/shared/standalone/backups/default

2. Téléchargez votre fichier de sauvegarde sur le serveur de destination.

scp /chemin/vers/sauvegarde/backup.tar.gz root@192.168.1.1:/var/discourse/shared/standalone/backups/default

Assurez-vous de remplacer les chemins, les noms de fichiers et les noms de serveurs par ceux que vous utilisez – mais vous voulez que le fichier de sauvegarde se termine dans :

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

Vous pouvez également télécharger votre fichier de sauvegarde Discourse depuis des sites de stockage web populaires tels que Google Drive, Dropbox, OneDrive, etc. – vous devrez consulter les instructions spécifiques de la ligne de commande en fonction de votre fournisseur de stockage web préféré.

NE CHANGEZ PAS LE NOM DU FICHIER DE SAUVEGARDE ! Discourse traite le nom du fichier de sauvegarde comme des métadonnées, donc si vous modifiez le nom du fichier, la restauration ne fonctionnera pas. Conservez le nom de fichier original.

Remplacez /chemin/vers/sauvegarde/discourse-xyz.tar.gz par le chemin local de votre fichier de sauvegarde, et remplacez \u003cserver_ip_address\u003e par l’adresse IP du serveur de destination.

Si Nginx est utilisé comme proxy inverse (Running other websites on the same machine as Discourse) assurez-vous que tous les chemins d’accès à la sauvegarde sont lisibles par le conteneur et que Nginx peut lire le fichier .sock.

Restaurer la sauvegarde

1. Accédez à votre serveur de destination et naviguez jusqu’au dossier Discourse :

cd /var/discourse

2. Entrez dans le conteneur de l’application Docker Discourse :

./launcher enter app

3. Activez la fonctionnalité de restauration :

discourse enable_restore

4. Restaurez le fichier de sauvegarde :

discourse restore sitename-2019-02-03-042252-v20190130013015.tar.gz

Astuce : Si vous exécutez discourse restore sans nom de fichier, il listera tous les fichiers de sauvegarde disponibles.

Si le paramètre backup_location de votre site est configuré pour utiliser S3, mais que vous avez téléchargé manuellement le fichier de sauvegarde sur le système de fichiers local, vous devez spécifier --location local :

discourse restore --location local sitename-2019-02-03-042252-v20190130013015.tar.gz

De même, utilisez --location s3 pour restaurer directement à partir d’une sauvegarde S3 sans la télécharger au préalable.

5. Quittez le conteneur de l’application Docker Discourse :

exit

Reconstruire

Après avoir restauré la sauvegarde, vous pouvez choisir de reconstruire l’instance de destination pour vous assurer que tous les paramètres et configurations sont appliqués correctement.

C’est le bon moment pour mettre à jour /var/discourse/containers/app.yml avec le HTTPS complet, les plugins supplémentaires ou la configuration CDN. Comparez la configuration app.yml des deux instances pour en être sûr !

cd /var/discourse
./launcher rebuild app

Activer l’e-mail

Lorsqu’une sauvegarde est restaurée, l’envoi d’e-mails pour les non-membres du personnel est désactivé. Vous ne voulez pas que votre serveur de test, nouveau serveur, ou serveur sur lequel vous venez de restaurer une sauvegarde pour une autre raison commence à envoyer des e-mails à vos utilisateurs ! Modifiez le paramètre de site disable_emails à “no” pour réactiver l’envoi d’e-mails.

Voilà. Votre serveur Discourse est restauré avec succès.

[gregcaporaso]

Ces instructions ont fonctionné pour nous permettre de restaurer à partir d’une sauvegarde, mais nous avons dû modifier la commande discourse restore pour :

discourse restore --location local sitename-2019-02-03-042252-v20190130013015.tar.gz

(mon exemple utilise le nom de fichier de l’exemple ci-dessus) afin que la restauration trouve les sauvegardes que nous avions placées dans le répertoire /var/discourse/shared/standalone/backups/default (par opposition aux sauvegardes stockées sur s3).

[Isambard]

La reconstruction après restauration est-elle nécessaire ?

De plus, j’ai restauré sur un nouveau serveur où il y a un proxy inverse NGINX qui transmet ensuite à Discourse en amont. J’ai donc désactivé le SSL sur Discourse, mais j’ai remarqué pendant la restauration :

Remapping 'https://example.com' to 'http://example.com'

Est-ce que cela remappe tous les liens internes ? Est-il aussi simple de défaire cela que discourse remap http://example.com https://example.com ?

[pfaffman (Jay Pfaffman)]

@Isambard

La reconstruction après restauration est-elle nécessaire ?

Non.

@Isambard

Est-ce que cela remappe tous les liens internes ?

Il semble que oui. Oui, vous pouvez les remapper.

Vous devriez définir la variable force_https.

[pinder99 (Pushpender Singh)]

si la sauvegarde fait 15 Go, combien d’espace est nécessaire pour la restaurer ?

[pfaffman (Jay Pfaffman)]

Est-ce juste la base de données ou les téléchargements aussi ?

Probablement 3 à 5 fois plus.

[pinder99 (Pushpender Singh)]

c’est base de données+téléchargement 15 Go, j’ai 20 Go d’espace sur un disque dur de 60 Go mais la restauration échoue à chaque fois, j’ai besoin d’au moins 50-60 Go d’espace pour restaurer ?

[pfaffman (Jay Pfaffman)]

Vous avez besoin de suffisamment d’espace pour la sauvegarde, les téléversements et la base de données non compressée.

Vous pourriez essayer de restaurer d’abord une sauvegarde de base de données uniquement, puis copier les téléversements à la main avec rsync.

[Ethsim2 (Ethan)]

J’ai vérifié mon compte administrateur sur l’auto-hébergement et j’ai téléchargé une sauvegarde .sql.gz, pas une .tar.gz.

La restauration dans l’interface utilisateur n’est pas fructueuse, j’ai donc effectué la restauration depuis la ligne de commande en utilisant « Restaurer la sauvegarde », avec un résultat [FAILED] à la fin du processus discourse restore. Le fichier d’entrée provenant d’un hébergement officiel étant .tar.gz pourrait-il être la cause de l’échec du processus ?

Mon hébergement officiel date de quelques jours, et mon auto-hébergement a commencé à fonctionner correctement aujourd’hui après avoir modifié les valeurs SMTP dans container.yml.

[pfaffman (Jay Pfaffman)]

Vous devrez inclure l’erreur que vous avez reçue. Le nom du fichier contient des informations de version, donc si vous avez renommé le fichier, vous devrez probablement le renommer à nouveau, en modifiant uniquement les mots au début du nom du fichier.

[helmi]

Existe-t-il une documentation pour discourse restore quelque part ? car il semble y avoir un commutateur --location local, je suppose qu’il y en aurait aussi un pour S3 ?

Je cherche à restaurer à partir de sauvegardes situées sur S3 et éviter de devoir les télécharger manuellement au préalable.

EDIT : tant pis. Je viens de découvrir que discourse restore --location s3 $filename semble fonctionner tout à fait bien.

[Jagster (Jakke Flemming)]

Parce que j’ai activé S3 dans app.yml, une simple commande discourse restore <nom_de_fichier> a fonctionné parfaitement.

Je pense que si vous recherchez backup restore s3, vous trouverez le bon article.

[Ethsim2 (Ethan)]

Salut, j’ai terminé ce processus en utilisant s3(-cli) comme mon scp et un changement de fournisseur de messagerie sortante de MailGun à Brevo

Depuis la restauration, je ne trouve aucun moyen de supprimer la bannière ?

[Moin]

@Discourse

Le processus de restauration définit automatiquement le paramètre disable emails sur « non-staff », de sorte que les e-mails ne sont pas envoyés aux utilisateurs de votre site tant que vous n’êtes pas prêt.

Le moyen le plus simple de supprimer la bannière est d’activer les e-mails dans les paramètres du site

[pfaffman (Jay Pfaffman)]

@Moin

La façon la plus simple de supprimer la bannière est d’activer les e-mails dans les paramètres du site.

C’est vrai. Vous pourriez aussi la masquer avec du CSS !

[Moin]

Vrai. J’étais un peu prudent en recommandant cela car j’ai dû penser à Air theme hides "outgoing email disabled" warning

[pfaffman (Jay Pfaffman)]

@Moin

J’étais un peu prudent en recommandant cela car j’ai dû penser à le thème Air masque l’avertissement « e-mail sortant désactivé »

Chaque fois que vous restaurez une sauvegarde, l’e-mail est automatiquement désactivé pour les non-membres du personnel. J’imagine que cela a été ajouté au code juste quelques fois après qu’une restauration a été effectuée sur un serveur de test qui a commencé à inonder ses utilisateurs de notifications pour un serveur dont ils n’étaient pas censés avoir connaissance.

J’ai mis à jour l’OP en conséquence :

@Discourse

Activer l’e-mail

Lorsqu’une sauvegarde est restaurée, les e-mails sortants pour les non-membres du personnel sont désactivés. Vous ne voulez pas que votre serveur de test, votre nouveau serveur ou un serveur pour lequel vous venez de restaurer une sauvegarde pour une autre raison commence à envoyer des e-mails à vos utilisateurs ! Changez le paramètre du site « disable_emails » pour réactiver l’e-mail.

[thoka (Thomas Kalka)]

Note pour le guide pratique :

Si vous restaurez régulièrement des sauvegardes à des fins de test et que votre serveur de test est correctement configuré pour envoyer des e-mails à un service d’e-mails de débogage (comme GitHub - maildev/maildev: 📫 SMTP Server + Web Interface for viewing and testing emails during development.), vous pourriez vouloir activer les e-mails via un script :

docker exec -it app /bin/bash --login \
-c "rails runner 'SiteSetting.disable_emails=\"no\";'"

[pfaffman (Jay Pfaffman)]

Dans ce cas, vous voudrez peut-être définir DISCOURSE_DISABLE_EMAILS sur non dans votre app.yml. (et aussi DISCOURSE_ENABLE_RESTORE pour faciliter la restauration)