Suis-je le seul supris de voir un projet avec un script de backup et absolument rien pour décrire le process de restoration des données?
Soit dit en passant GLPI est le cas typique d'une appli qui peut souffrir de quelques secondes d'arrêt chaque nuit et pour laquelle il y a peu de chance de vouloir restaurer seulement quelques lignes ou une table. Et ils semble que les volumes semblent être des bind mounts de répertoires de la machine hôte.
Du coup pourquoi ne pas faire plus simple:
1. docker-compose stop
2. snapshot des volumes et montage sur un autre point de montage sur l'hôte
3. docker-compose up
4. backup des snapshots
5. cleanup des snapshots (peut aussi être réalisé en début de point 2 si on peut supporter d'avoir l'espace utilisé et qu'on veut une copie locale de restauration pour des petites bévues)
L'avantage c'est qu'il n'y a quasi aucun scripting, que t'es absolument sûr que le volume de ta db et du reste de l'appli sont cohérents. Avec ta méthode je ne vois rien qui garantie la cohérence entre le dump mysql et les fichiers copiés. Donc à la restauration tu peux te retrouver avec des fichiers uploadés qui ne sont pas référencés en DB et avoir des trucs pas propres..
Et pour le restore ce serait aussi très simple:
- docker-compose stop
- restoration des données dans le point de montage désiré
- docker-compose up
Du reste en utilisant des vrais volumes plutôt que des bind mounts tu pourrais bénéfichier des capacités de snapshots de docker et faire des backups sur des clones.
# quid de la restauration?
Posté par Psychofox (Mastodon) . En réponse au journal Sauvegarder le contenu d’un container Docker avec BackupPC. Évalué à 4. Dernière modification le 12 novembre 2021 à 11:52.
Suis-je le seul supris de voir un projet avec un script de backup et absolument rien pour décrire le process de restoration des données?
Soit dit en passant GLPI est le cas typique d'une appli qui peut souffrir de quelques secondes d'arrêt chaque nuit et pour laquelle il y a peu de chance de vouloir restaurer seulement quelques lignes ou une table. Et ils semble que les volumes semblent être des bind mounts de répertoires de la machine hôte.
Du coup pourquoi ne pas faire plus simple:
1. docker-compose stop
2. snapshot des volumes et montage sur un autre point de montage sur l'hôte
3. docker-compose up
4. backup des snapshots
5. cleanup des snapshots (peut aussi être réalisé en début de point 2 si on peut supporter d'avoir l'espace utilisé et qu'on veut une copie locale de restauration pour des petites bévues)
L'avantage c'est qu'il n'y a quasi aucun scripting, que t'es absolument sûr que le volume de ta db et du reste de l'appli sont cohérents. Avec ta méthode je ne vois rien qui garantie la cohérence entre le dump mysql et les fichiers copiés. Donc à la restauration tu peux te retrouver avec des fichiers uploadés qui ne sont pas référencés en DB et avoir des trucs pas propres..
Et pour le restore ce serait aussi très simple:
- docker-compose stop
- restoration des données dans le point de montage désiré
- docker-compose up
Du reste en utilisant des vrais volumes plutôt que des bind mounts tu pourrais bénéfichier des capacités de snapshots de docker et faire des backups sur des clones.