Nous avons configuré des sauvegardes automatiques. Pour autant que je sache, elles fonctionnent sans problème, mais nous aimerions les surveiller avec un service simple, tel que https://healthchecks.io, pour en être sûrs.
Existe-t-il un moyen de configurer un simple appel à leur API pour confirmer qu’une sauvegarde est terminée ? Quelque chose comme ceci :
Vous pouvez faire de l’ingénierie inverse de l’API Discourse pour obtenir une liste de sauvegardes, puis vous devrez faire quelque chose pour voir quelle était la dernière et combien de temps elle est là.
Vous recevrez une notification si une sauvegarde échoue.
Le seul problème que j’ai jamais eu, c’est lorsque les sauvegardes étaient planifiées en même temps que les redémarrages des systèmes de marketing personnalisé automatisés.
D’après ce que je vois, cela fonctionne lorsqu’il y a un calendrier de sauvegarde de base de données en coulisses (car une fois par jour n’est pas suffisant, n’est-ce pas ?) et que le système d’alerte intégré prend du retard, au maximum 24 heures. Mais cela fonctionnerait comme un système d’alerte précoce si Discourse tombait en panne à cause d’une défaillance de la base de données, mais comme la mise en cache empêche les utilisateurs de le voir immédiatement.
Merci. S’il n’y a aucun moyen de définir un « hook » une fois la sauvegarde terminée, alors je pense que l’idée de faire de l’ingénierie inverse de l’API Discourse pour trouver la sauvegarde la plus récente est probablement la voie à suivre, et nous aurons alors le contrôle total sur ce qu’il faut faire si une sauvegarde n’a pas fonctionné… mais si un hook (commande web ou shell) pouvait être ajouté après la sauvegarde, ce serait idéal.
Si vous voulez appeler un hook après la sauvegarde, je pense qu’il faudrait créer un plugin.
Suggérez-vous vraiment qu’une sauvegarde échouée est la façon dont vous voulez savoir si Discourse est en panne ?
/srv/status vous donne une assez bonne idée, bien que Discourse puisse tomber en panne de manières qui ne s’y reflètent pas. Cela indiquera si la base de données est défaillante.
Je ne suggère rien d’autre que de sauvegarder la base de données plus souvent qu’une fois par jour. Je pensais juste qu’un e-mail en cas d’erreur de sauvegarde servirait aussi de sonnette d’alarme.
