Ce n’est pas mon problème, mais cela signifie-t-il qu’il n’y a rien d’autre ?
1 « J'aime »
Peut-être pas intentionnellement, mais il pourrait être utile d’auditer le contenu de l’hôte pour détecter les processus de minage de cryptomonnaies, etc.
3 « J'aime »
Étape 1 : corriger le problème de performance déjà identifié lié à l’utilisation du pilote vfs
7 « J'aime »
Concernant ce passage à (idéalement) overlay2, je devrai effacer mon installation actuelle et tout réinstaller. C’est parce que l’hôte sur lequel je suis actuellement ne prend en charge que fuse-overlayfs ou le vfs, qui ne sont ni l’un ni l’autre recommandés.
Cependant, ils activeront bientôt les KVM qui prennent en charge overlay2.
Mon intention serait donc de l’utiliser, plutôt que le fuse-overlayfs qui n’est pas non plus suggéré.
Maintenant, dans l’application Discourse elle-même, je peux faire des sauvegardes. Que sauvegardent-elles précisément ?
Perdrais-je quoi que ce soit du forum Discourse actuel (je veux dire des messages, des discussions, des paramètres, des utilisateurs, des images téléchargées, etc.) si je faisais une sauvegarde, réinstallais un Discourse neuf sur un serveur neuf, puis après la configuration initiale de Discourse, le remplaçais par la sauvegarde ?
Est-ce que cela fonctionnerait ?
Oui, cela fonctionnerait.
La seule chose que vous n’avez pas mentionnée est de vous assurer que vous avez les mêmes plugins sur le nouveau Discourse que sur celui actuel. Si vous réutilisez votre app.yml, vous seriez également tranquille.
3 « J'aime »
D’accord, merci de l’avoir signalé, je parie que je serais tombé pile dedans.
Ok alors…
- Faire une sauvegarde dans la zone d’administration de Discourse
- Juste pour la sécurité, bien sûr, faire une sauvegarde du serveur
- Prendre une copie du fichier yaml
- Dumper le serveur
- Configurer un nouveau serveur avec une technologie prise en charge
- Installer Docker avec le bon pilote de stockage
- Reconstruire une instance Discourse entièrement neuve en utilisant le fichier yaml sauvegardé
- Restaurer Discourse à partir de la sauvegarde
Un peu surpris que la sauvegarde ne fasse que 19,2 Mo.
Nous avons déjà plusieurs images, etc. téléchargées… mais je suppose que tout ce que je peux faire, c’est essayer.
Je vais essayer ça ce week-end et je vous dirai si le changement de pilote de stockage a fonctionné.
1 « J'aime »
Vérifiez que ceci est défini :
1 « J'aime »
Veuillez noter que ce paramètre spécifique ne s’applique qu’aux sauvegardes planifiées, et non aux sauvegardes manuelles. Avec les sauvegardes manuelles, vous avez toujours un choix explicite.
Un autre paramètre à activer est inclure les miniatures dans les sauvegardes
@smileBeda Je reporterais le #4 jusqu’à ce que tout fonctionne correctement.
3 « J'aime »
Il est bien coché, mais Inclure les miniatures générées dans les sauvegardes. Désactiver cette option réduira la taille des sauvegardes, mais nécessitera une nouvelle génération de toutes les publications après une restauration. ne l’était pas.
@RGJ … d’accord, bonne idée, cela prendra plus d’étapes car je devrai créer un serveur sous une nouvelle entité, mais c’est mineur par rapport au risque.
Je laisserai la sauvegarde automatisée se déclencher pour obtenir toutes les données, car je comprends que la sauvegarde manuelle n’inclurait pas les images, etc.
Merci…
C’est une supposition incorrecte.
Lorsque vous créez une sauvegarde manuellement, vous avez le choix dans une fenêtre contextuelle si vous souhaitez sauvegarder uniquement la base de données ou inclure les téléchargements.
Lors de la création de sauvegardes planifiées, le paramètre sauvegarde avec téléchargements en décide.
4 « J'aime »
Ok, j’ai mal compris votre précédent « Veuillez noter que ce paramètre spécifique ne s’applique qu’aux sauvegardes planifiées, pas aux sauvegardes manuelles. »
Merci…
2 « J'aime »
Salut, je réutilise ce sujet car il est toujours ouvert et nous rencontrons le même problème après la migration vers un nouveau serveur virtuel. Comme tout le monde le dit, cela ne m’a jamais pris plus de 20 minutes pour reconstruire notre Discourse, mais sur ce nouveau serveur, cela prend des heures, et il a deux fois plus de ressources que le précédent. 
J’ai consulté d’autres sujets concernant les mises à niveau qui durent des heures sur Meta, mais je n’arrive pas à identifier le problème avec le nôtre :
Serveur : 4 Go de RAM, 2 CPU, 50 Go de disque.
Swap :
/$ free
total used free shared buff/cache available
Mem: 3911740 507208 2318476 268 1384032 3404532
Swap: 4095976 45472 4050504
Docker :
/$ sudo docker info
Client:
Version: 26.1.3
Context: default
Debug Mode: false
Server:
Containers: 3
Running: 0
Paused: 0
Stopped: 3
Images: 3
Server Version: 26.1.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version:
runc version:
init version:
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.8.0-31-generic
Operating System: Ubuntu 24.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.731GiB
Name: podkasts
ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Cela me semble normal, mais peut-être que je rate quelque chose. Où d’autre pouvons-nous chercher ?
Peut-être qu’un voisin bruyant rend votre nouvelle VM plus lente que l’ancienne parce qu’il utilise tout le CPU que vous n’obtenez pas ?
1 « J'aime »
Oui, merci, c’est rassurant qu’un administrateur expérimenté comme vous ne voie rien d’évident dans les informations ci-dessus. Et oui, nous commençons à examiner le serveur physique et notre voisinage virtuel. Au moins, le forum fonctionne sans problèmes perceptibles par les utilisateurs. Nous ne rencontrons ce grave problème de performance qu’avec les reconstructions. Hier, il nous a fallu 4 heures pour reconstruire. 
1 « J'aime »
Si j’avais ce problème, j’aurais deux ou trois fenêtres de terminal ouvertes. Une pour exécuter la reconstruction, une pour prendre des notes sur le temps écoulé et pour noter où se produisent les longs retards entre les mises à jour des journaux, et la dernière pour conserver un enregistrement de l’activité de la machine : probablement en exécutant vmstat 5
Lorsque vous atteignez un point où le journal ne se met pas à jour pendant un temps suspectement long, prenez note de l’activité signalée par vmstat.
Publiez ici des extraits appropriés du journal avec vos notes et la sortie vmstat correspondante.
Il semble très probable que ce soient des parties spécifiques de la reconstruction qui prennent du temps : il faut découvrir quelles parties, et voir ce que fait la machine à ces moments-là.
Je prendrais probablement aussi un instantané de l’activité de la machine avec ps auxf pendant les pauses également.
4 « J'aime »
Merci, ce sont de très bons conseils. La prochaine fois que nous devrons reconstruire, nous le ferons de cette façon.
2 « J'aime »