Je veux m’assurer d’avoir une bonne stratégie de sauvegarde lorsque mon site sera mis en ligne. Voici les étapes que j’ai mises en place. Qu’est-ce qui me manque ?
Sauvegardes de la base de données
Discourse effectue une sauvegarde quotidienne de la base de données.
Une sauvegarde supplémentaire de la base de données via cron est effectuée quotidiennement. (+12 heures par rapport à la sauvegarde basée sur l’interface utilisateur)
Les sauvegardes sont stockées dans un bucket S3 (centre de données différent)
Fichiers principaux
Les éléments suivants sont sauvegardés deux fois par jour dans un bucket S3 (centre de données différent)
discourse/containers/app.yml
discourse/shared/standalone/uploads/
discourse/shared/standalone/backups/
discourse/shared/standalone/ssl/
discourse/shared/standalone/letsencrypt/
Les sauvegardes de fichiers ont lieu deux fois par jour, 30 minutes après les sauvegardes de la base de données.
S3 : Téléversements
La sauvegarde quotidienne des téléversements est stockée dans un bucket S3 dans un centre de données différent.
Sauvegardes du serveur
Sauvegardes hebdomadaires de l’ensemble du serveur - 4 sauvegardes hebdomadaires conservées
Stockage annuel d’une sauvegarde hebdomadaire comme sauvegarde principale dans un emplacement distant.
Cela devrait fournir toutes les données et tous les paramètres nécessaires pour restaurer un serveur sur place ou sur un nouveau serveur.
C’est la méthode suggérée. Si vous sauvegardez votre base de données une fois par jour, vous risquez un maximum de 24 heures de ce qui s’est passé sur ce forum.
On m’a dit au moins deux fois que ce n’était pas un problème, mais personne n’a jamais expliqué pourquoi. Je sauvegarde donc ma base de données toutes les 6 heures — mon forum n’est pas très fréquenté, donc je peux prendre ce risque. À titre de comparaison, mon site de commerce électronique effectue une sauvegarde toutes les 4 minutes.
Comment avez-vous configuré votre base de données pour des sauvegardes plus fréquentes ? Je préférerais deux fois par jour, mais la fonctionnalité de l’interface utilisateur ne permet qu’une fois par jour.
Vous pouvez avoir un cron job (sur votre serveur, pas dans le conteneur) qui exécute
docker exec app bash -c "discourse backup"
Si les données sont vraiment critiques, vous pouvez alors mettre en place un serveur de réplication postgres et avoir chaque commit sur un second serveur.
C’est la propre commande CLI de Discourse pour la sauvegarde, et on m’a dit que docker exec app l’exécute en dehors du conteneur (app du nom du conteneur, bien sûr.
Et parce que j’ai configuré S3 qui saute dans le même bucket où se trouvent aussi les sauvegardes “normales”.
Il y a un petit problème… bientôt il y aura une tonne de sauvegardes. Je ne sais pas si je devrais faire différemment le sql-dump, le déplacer en utilisant aws-cli, puis supprimer tout ce qui est plus ancien qu’un certain délai. Ou faire la même chose sur le VPS.
Mais c’est le moyen le plus simple d’obtenir un sql-dump.
Je suppose que cela active la routine de sauvegarde interne du discours, de sorte que toutes les notifications restent en place.
Désactivez-vous la planification de la sauvegarde dans l’interface utilisateur et gérez-vous tout via cron ? ou bien, faites-vous une sauvegarde dans l’interface utilisateur et les sauvegardes supplémentaires via cron ?
Non. Je fais les deux. Je n’ai pas autant confiance dans le système que je n’en ai en moi-même. C’est assez rarement la quantité de sauvegardes qui pose problème, mais plutôt la pénurie.
Merci @Jagster et @pfaffman pour votre aide dans la configuration d’une base de données supplémentaire via cron. Cela réduit la perte de données de mon système à un maximum de 12 heures dans le pire des cas.