Pause l'optimisation des images lors de la restauration sur une nouvelle instance du serveur

Soutien
1

J’essaie de migrer mon instance Discourse vers un nouveau serveur. Comme je suis limité en espace sur le serveur, je veux d’abord…

Comment puis-je suspendre l’optimisation des images après le téléchargement initial de la base de données et la restaurer ?

Ainsi, je pourrai vérifier si la restauration s’est bien déroulée, supprimer le fichier de sauvegarde et le supprimer.

Mon fichier de sauvegarde pèse environ 200 Go avec le paramètre non vérifié « Inclure les miniatures générées dans les sauvegardes ». La désactivation de cette option rendra les sauvegardes plus petites, mais nécessitera une nouvelle cuisson de tous les messages après une restauration.

Je vais donc manquer d’espace disque si mon instance conserve le fichier de sauvegarde et commence à optimiser les images.

2

Si vous avez besoin de plus d’espace, il vous faut plus d’espace.

Mais peut-être voulez-vous synchroniser les images avec rsync et restaurer uniquement la base de données. De cette façon, vous n’avez pas deux copies de tous les téléchargements (et vous n’avez pas à recréer les miniatures).

3

Merci d’avoir essayé d’aider.

J’ai essayé, mais je n’étais pas tout à fait sûr pourquoi ma restauration n’a pas bien fonctionné.

Mon problème principal est que mon ancienne instance est bloquée sur la version 12 de PostgreSQL, je n’ai pas trouvé le moyen de la mettre à niveau et j’ai essayé de passer à une nouvelle instance fraîche.

Savez-vous s’il est possible de restaurer uniquement la base de données sur une nouvelle installation ?

Lorsque j’ai essayé, l’instance a juste commencé à renvoyer le code d’erreur 500 et j’ai dû tout recommencer.

4

Ce que je ferais, c’est suivre le Déplacer un site Discourse vers un autre VPS avec rsync sauf que je ne copiera pas les fichiers postgres.

Ensuite, je ferais une sauvegarde uniquement de la base de données et je la restaurerais. Vous synchroniserez la sauvegarde également et la restaurerez à partir de la ligne de commande.

Est-ce une très ancienne version, je suppose ? La restauration a-t-elle semblé se dérouler avec succès ?

1 « J'aime »
5

Merci de votre aide.

Oui, mais pour une restauration simple à l’aide de l’interface graphique et de la procédure attendue, vous avez besoin de plus de 4 fois la taille de votre fichier de sauvegarde.

Voici comment faire :

  1. Téléchargez le fichier de sauvegarde (ou utilisez rsync dans /var/discourse/shared/standalone/backups/default)
  2. Une fois la restauration initialisée, le fichier de sauvegarde.gz est copié dans /var/discourse/shared/standalone/tmp/restores/
  3. Pendant la restauration, le fichier de sauvegarde dans le dossier /var/discourse/shared/standalone/tmp/restores/ est décompressé.
  4. Depuis le dossier temporaire, les téléchargements sont synchronisés vers leur emplacement d’origine et le dump SQL est inséré dans la base de données pg.

Comment j’ai réussi à restaurer avec succès.

Pendant le processus de restauration, une fois que Discourse a copié le fichier du dossier de restauration vers le dossier temporaire, j’ai supprimé le fichier de sauvegarde original téléchargé via SSH.

Une fois de plus, lorsque Discourse a terminé les insertions SQL et la synchronisation rsync des fichiers décompressés du dossier temporaire vers /var/discourse/shared/standalone/uploads/, j’ai manuellement supprimé le fichier bakupxxx.tar.gz dans le dossier temporaire via SSH sans interrompre le processus de restauration.

Une fois que mon instance était en ligne et que la synchronisation rsync était terminée, j’ai exécuté :

rm -rf /var/discourse/shared/standalone/tmp/restores/default/*

Si votre processus de restauration de sauvegarde volumineuse semble bloqué et que l’instance renvoie une erreur 500 via le web (ce qui m’est arrivé deux fois), vous pouvez vérifier le processus de restauration en entrant dans l’application :

cd /var/discourse
./launcher enter app

ps aux | grep restore

De plus, comme ma restauration de base de données était trop longue :

cd /var/discourse
./launcher enter app
watch -n 10 “sudo -u postgres psql discourse -c \“SELECT now(), state, query FROM pg_stat_activity WHERE state != ‘idle’;”\”

M’a aidé à surveiller la progression de la restauration de la base de données, pour voir si la restauration était toujours en cours.

6

C’est une sacrée solution ! Si quelqu’un d’autre trouve ça, je pense qu’une restauration de la base de données seule aurait fonctionné et aurait été un peu plus facile, mais je suis content que vous ayez trouvé une solution !

1 « J'aime »