Je ne sais pas s’il faut répondre ici ou créer un nouveau post : Demande de fonctionnalité - calendriers séparés pour « inclure les pièces jointes » et « ne pas inclure les pièces jointes ».
J’aimerais vraiment avoir de petites sauvegardes quotidiennes, voire plusieurs fois par jour, étant donné que la base de données est petite. Je ne serais pas dévasté si je perdais une semaine de pièces jointes, car elles sont beaucoup plus limitées et les gens peuvent généralement retrouver leur source. Cela pourrait augmenter le facteur de sécurité sans submerger le stockage.
Je n’ai pas regardé le code source, mais ce serait probablement une refonte car les restaurations devraient être des entités séparées, ou du moins la possibilité d’avoir différents points de restauration pour les 2 sources.
L’action suggérée pour cette demande est généralement de faire les autres sauvegardes de base de données à l’aide d’un outil externe.
Si vous déplacez les téléchargements vers S3, vous pouvez effectuer des sauvegardes uniquement de la base de données et ne pas vous soucier des téléchargements.
Assez raisonnable. Dès que je commence à envisager des outils externes, je pense à des « moyens externes de tout gâcher » car ils sont généralement capables de causer plus de ravages que la console d’administration intégrée, qui est à l’épreuve des idiots (ou presque).
La dernière fois, moi et d’autres avons posé la même question, les réponses étaient les mêmes qu’auparavant :
une sauvegarde quotidienne suffit
utiliser des outils externes, comme des scripts et cron
Eh bien, une seule sauvegarde quotidienne de la base de données n’est pas suffisante, une sauvegarde horaire pourrait l’être.
N’importe quel outil externe peut faire le travail, c’est vrai. Mais toutes les autres applications offrent une sauvegarde décente nativement, sauf Discourse.
J’aimerais vraiment savoir si la raison est :
“nous ne voulons tout simplement pas, c’est pourquoi personne d’autre n’en a besoin”
c’est techniquement très difficile et/ou coûteux
Eh bien, et il y a toujours une troisième option : Marketplace
Si vous voulez beaucoup de sauvegardes avec WordPress (une plateforme web populaire), vous devez utiliser un plugin de sauvegarde qui coûte de l’argent, donc peut-être que toutes les autres applications ne le font pas nativement. Du moins, c’est ce que je fais, bien que cela fasse longtemps que j’ai pris cette décision, donc peut-être que c’était une mauvaise décision.
La raison est qu’avoir beaucoup de sauvegardes est un moyen de remplir votre disque, ce qui est l’une des raisons les plus courantes pour lesquelles un site auto-hébergé tombe en panne (ce qui, je pense, le classe dans la catégorie “coûteux”). L’idée est donc que si vous avez suffisamment de compétences pour gérer une multitude de sauvegardes et gérer votre espace disque, vous pouvez probablement résoudre ce problème de plusieurs façons. Et si vous voulez des sauvegardes horaires, vous devez faire en sorte qu’il s’agisse de sauvegardes de base de données uniquement plutôt que de dizaines ou de centaines de copies de vos téléchargements.
Donc, les sauvegardes horaires n’ont de sens que si vous avez des téléchargements sur S3 afin de pouvoir ensuite faire des sauvegardes de base de données uniquement, et probablement les pousser vers S3 afin de ne pas vous soucier de votre disque local. Et alors, c’est un très petit nombre de sites auto-hébergés qui veulent cela.
Si vous avez tout cela en place, alors un plugin qui ferait des sauvegardes horaires de base de données uniquement ne prendrait pas plus d’une heure ou deux de travail, ou peut-être 2 à 10 si vous ne savez pas comment créer un plugin et que vous devez trouver comment créer une tâche horaire.
C’est vrai. WordPress lui-même ne peut pas faire grand-chose. C’est pourquoi il existe autant de plugins — bons et mauvais.
Ce n’est pas vrai. Seuls les extras coûtent cher, pas la sauvegarde elle-même.
Bien sûr, il est inutile de sauvegarder les fichiers, ou le système lui-même, si souvent. La base de données elle-même est un tout autre jeu. Elle devrait être faite au moins toutes les 15 minutes s’il y a plus de trafic.
La question est très simple : quelle quantité de contenu pouvez-vous perdre.
Si la perte de données maximale que vous pouvez tolérer est aussi faible, vous pourriez envisager d’utiliser une solution de réplication Postgres au lieu de faire des sauvegardes aussi fréquemment.
Y a-t-il d’autres données dont j’ignore l’existence ? Ou utilisez-vous le terme données dans un sens plus large incluant tous les fichiers ; système, Docker/Discourse/etc, téléchargés ?
Ces fichiers peuvent être récupérés facilement ou à faible coût — eh bien, sauf ceux téléchargés, mais c’est pour cela que nous avons S3 .
Alors il est plutôt petit, mais c’est le plus grand si l’on considère le forum lui-même. Mais pour une raison quelconque, nous en revenons à ceci :
J’aimerais vraiment savoir si le problème principal est d’ordre technique ou psychologique. Ou est-ce que cela fait partie du modèle économique et si la sauvegarde est facile et fonctionne, l’hébergement perdra un argument de vente — et je ne sais pas s’il existe de tels arguments de vente. J’essaie juste de comprendre pourquoi une meilleure sauvegarde est une question si importante, même si elle a déjà été demandée.
Il n’est pas nécessaire de soupçonner qu’il y ait une stratégie ou un plan maléfique derrière cela. Je ne pense pas qu’il y ait beaucoup d’intérêt pour des sauvegardes plus fréquentes. S’il y en avait, quelqu’un aurait écrit un plugin pour cela. Ce serait quelques heures de travail. Je ne vois pas le Marketplace inondé de demandes à ce sujet.
Je pense que cela se résume à :
pour les petits forums, vous ne perdrez pas beaucoup de données de toute façon car il n’y a pas grand-chose de nouveau en une journée, donc des sauvegardes plus fréquentes ne valent pas vraiment l’effort
pour les plus grands forums, des sauvegardes plus fréquentes consommeront des performances et du stockage
pour les très grands forums, vous voudrez examiner différentes solutions (comme la réplication vers un serveur de base de données de secours à chaud)
N’oubliez pas que les chances d’avoir réellement besoin d’une sauvegarde sont également très faibles. Dans l’histoire de Communiteq (plus de 8 ans), nous n’avons eu besoin de restaurer une sauvegarde qu’une seule fois* et ce n’était que parce que nous étions impatients et ne voulions pas attendre quelques heures pour une récupération du système de fichiers.
*) (à l’exclusion des restaurations à la demande du client où il voulait simplement annuler des modifications, principalement sur des forums non-production, et à l’exclusion de notre test de restauration mensuel)
Donc, si je cherche ici, je ne trouve aucun sujet où Discourse a planté pour une raison quelconque et la seule solution était de restaurer à partir d’une sauvegarde ?
Mais c’est bien de savoir que Discourse est si solide qu’il n’a pas besoin de sauvegarde à jour. Eh bien, nous savons que ce n’est pas totalement vrai.
Donc le cercle est fermé et nous en sommes revenus au point de départ :
Et la troisième option. Tant que je fais de facto des tests pour Discourse, ici et par moi-même, je ne suis pas disposé à payer pour une fonctionnalité aussi basique.
Eh bien, nous parlons ici sans aucun commentaire de l’équipe. Encore :rofl :
C’est la bonne approche. Suivez Exécuter Discourse avec un serveur PostgreSQL séparé pour exécuter votre propre instance PostgreSQL et gérer la sauvegarde et la haute disponibilité comme bon vous semble si la sauvegarde quotidienne ne suffit pas à votre cas d’utilisation.
Je pense entre 250 et 500 $, en fonction de la configurabilité et de la quantité de travail nécessaire pour le front-end. Je n’ai pas encore vraiment regardé ce que cela impliquerait. @RGJ pourrait le faire pour moins cher ; il m’a souvent surpris par la rapidité avec laquelle il peut faire les choses.
EDIT : OH, ce sujet est clos. Si vous êtes intéressé, vous pouvez me contacter ou poster dans Marketplace.
.