Une seule sauvegarde par jour n’est-elle pas trop risquée ? Si quelque chose arrive au serveur et que la dernière sauvegarde date d’hier, que dois-je faire ? Les utilisateurs enregistrés entre hier et aujourd’hui ne seront-ils plus enregistrés ? Je pense qu’il vaut mieux effectuer des sauvegardes plus fréquentes, peut-être toutes les heures. Mais dans ce cas, faut-il mettre le site en lecture seule avant de faire une sauvegarde ? Merci d’avance !
3 « J'aime »
+1 pour ça, encore. Discourse est le seul système dynamique où l’on peut automatiser la sauvegarde de la base de données une seule fois par jour.
Je ne m’attends pas à ce que cela change dans le cœur de métier de sitôt. J’ai eu des conversations sur le changement de la valeur par défaut à plus d’une fois par semaine et cela n’arrive pas.
Je pense que ce qui pourrait être bien, c’est un plugin qui ajouterait un paramètre de site pour effectuer des sauvegardes uniquement de la base de données sur un certain nombre d’heures (il n’y a aucune raison de conserver une quantité astronomique de copies de téléchargements non compressibles dans toutes ces sauvegardes complètes). Si cela vous intéresse, envoyez-moi un message privé ou demandez sur la place de marché.
2 « J'aime »
Si vous avez besoin d’une meilleure reprise après sinistre, je vous recommande de suivre Exécuter Discourse avec un serveur PostgreSQL séparé et d’exécuter PostgreSQL vous-même, où vous pourrez contrôler la haute disponibilité exacte dont vous avez besoin, comme les réplicas de synchronisation en direct, la récupération à un instant T et des sauvegardes plus fréquentes.
3 « J'aime »
Puis-je connaître la raison de cette politique, est-elle technique ou plus liée à la classe ? Un intervalle de 24 heures entre les sauvegardes est un problème assez critique pour les forums à fort trafic. Ou est-ce quelque chose que vous proposez uniquement aux clients payants ?
1 « J'aime »
L’exécution de Discourse avec un serveur PostgreSQL distinct réduit-elle la vitesse en étant sur un serveur différent ?
1 « J'aime »
Bien sûr, c’est une solution. Une solution assez rare parmi les applications, cependant. Dans le monde PHP/MySQL, sauvegarder une base de données à l’aide de cron serait vraiment facile à faire, mais encore une fois - dans ce monde, chaque application peut le faire par elle-même, avec ou sans plugin.
Oui, je suis un peu plus qu’un utilisateur final moyen 
mais j’ai une compréhension très limitée du fonctionnement de docker, rails, etc. et pour moi, une situation où les tâches courantes sont presque impossibles à réaliser est vraiment difficile à comprendre. Bien sûr, c’est peut-être à cause de mes limites, mais je ne suis pas le seul à me poser cette question.
Eh bien. Nous n’obtiendrons pas facilement de sauvegardes de base de données dans un avenir proche ou moyen, j’ai compris.
1 « J'aime »
Vous pouvez également configurer des sauvegardes PostgreSQL avec cron. Rien de différent ici.
Pas de manière significative. Chaque instance de Discourse que nous hébergeons, comme celle-ci, utilise une base de données sur un serveur dédié.
2 « J'aime »
Je ne vous pose que deux questions pour mieux comprendre.
- La base de données est la seule chose dont vous avez besoin pour tout restaurer, n’est-ce pas ? La sauvegarde qui est effectuée quotidiennement via les paramètres, la sauvegarde ne concerne-t-elle que la base de données ?
- Le forum doit-il être en mode lecture seule lors de la sauvegarde de la base de données ? Ou peut-elle être effectuée sans aucun problème, à tout moment ?
Merci d’avance !
2 « J'aime »
Les paramètres résident dans la base de données.
Techniquement, vous voulez aussi sauvegarder le dossier des uploads et la définition du site app.yml. Cependant, cela est généralement géré en ayant le fichier app.yml dans un système de contrôle de version et les uploads dans un service de stockage objet.
Pas besoin de mode lecture seule.
4 « J'aime »
Donc, en supposant que j’aie la base de données sur un serveur séparé et que je fasse des sauvegardes de cette base de données toutes les heures. Si je sauvegarde également, à partir des paramètres du panneau d’administration, uniquement les fichiers, y compris le fichier app.yml et le dossier uploads, seraient inclus dans la sauvegarde, mais pas la base de données, n’est-ce pas ? @Falco
1 « J'aime »
La sauvegarde inclura la base de données et les téléchargements (s’ils ne sont pas sur S3). app.yml n’est pas dans la sauvegarde, car Discourse ne peut pas le lire.
Ce que je recommande à la plupart des gens, c’est d’avoir les sauvegardes sur S3 et app.yml quelque part où vous pouvez l’obtenir en cas d’urgence. Ensuite, vous pouvez construire un nouveau conteneur avec app.yml et le restaurer à partir de la ligne de commande. Mais si vous avez les compétences techniques pour sauvegarder/restaurer postgres avec un autre outil, et les images sur S3 (ou peut-être que vous les avez sauvegardées d’une autre manière aussi), alors vous pouvez simplement reconstruire le conteneur et vous êtes de retour.
Ou peut-être que vous voulez avoir plusieurs serveurs postgres en miroir continuellement, puis organiser un basculement automatique vers la sauvegarde si le serveur principal tombe en panne.
Il existe une infinité de façons de fournir des sauvegardes plus fréquentes que celles proposées par Discourse. Si vous avez besoin de sauvegardes plus fréquentes, vous devrez les effectuer d’une autre manière.
2 « J'aime »
Un autre point ici concerne le risque et la maintenance : si vous utilisez la solution quotidienne prête à l’emploi, elle sera probablement plus robuste et fiable en tant que solution de sauvegarde que si vous configurez la vôtre. Que se passe-t-il si quelque chose ne va pas avec votre propre solution et que vous ne le découvrez que lorsqu’il est trop tard ? Au moins, avec la solution standard, vous avez des centaines de sites qui la testent quotidiennement.
Étant donné que je n’ai eu aucune expérience de corruption sur plusieurs sites en 4 ans, le risque d’avoir réellement besoin de la sauvegarde en premier lieu est également faible…
Peut-être que d’autres peuvent mentionner des risques plus importants, mais le risque le plus important est probablement les problèmes dus au remplissage du serveur ? Alors gardez un œil sur l’espace ? Mettez en place une alerte ?
3 « J'aime »
Donc, si j’ai bien compris, la meilleure façon est de tout garder séparément.
Serveur principal pour faire tourner Discourse. Puis un serveur pour PostgreSQL et S3 (ou tout autre service de stockage d’objets) pour les téléchargements.
Le fichier app.yml ne change pas souvent, donc il suffit de le sauvegarder une fois. Ou au maximum quelques fois dans le mois.
Cela vous permet de faire des sauvegardes de vos fichiers, même de manière plus organisée.
Si c’est le cas, je trouve que leur choix de ne pas implémenter plusieurs sauvegardes quotidiennes dans le cœur du système est logique. D’un autre côté, ceux qui ont des besoins complexes feront certainement des configurations particulières comme celle-ci. Et à la fin, il suffit de refaire l’installation (avec le fichier app.yml sauvegardé quelque part), puis de le reconnecter à la base de données et au S3 pour les téléchargements de données. Les sauvegardes sont dans ces 2 serveurs séparément, donc c’est facile à gérer pour moi. Je trouve que c’est une solution très juste.
Merci à tous pour l’explication.
3 « J'aime »
Il y a un autre fil ici : Configure automatic backups for Discourse - #113 by Tris20
@pfaffman y a fait quelques recommandations avec des liens. Cela m’a conduit à la ligne de commande comme moyen de planifier des sauvegardes plus fréquentes, ce qui, pour moi, est une solution assez raisonnable :
Notez qu’avec cette solution, vous pourriez tout combiner dans un script Python pour planifier également une copie du fichier YAML, etc., en même temps.
2 « J'aime »
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.