Le mardi 5 mars 2019 à 10:08:39 UTC+1, Benoit Garcia <benoit.garcia@gmail.com> a écrit :

Si il n'y a pas besoin d'accéder aux données depuis l'extérieur de ton container (et ça devrait être le cas pour une base de données), je partirais sur des container volumes.

Mais ce n'est que théorique, les seuls MySQL que je fais tourner dans du Docker sont pour des tests (restauration de backups, exécution de migration de données, etc).

ah tu m'intéresses, tu backup ta base comment ? Tu sauvegardes le volume ? Tu fait un dump ta base en dehors de ton volume ? Tu intégres un client de backup dans ton container ?quid des performances ?

Je ne pense pas que la sauvegarde du volume MySQL (ou de son contenu) ne puisse garantir la consistance de la base de données (pb des transactions en cours, etc). Donc pour moi c'est à éviter.

Si je devais réaliser les sauvegardes de MySQL dockerisé, je ne changerais pas des masses par rapport à ce que je fais aujourd'hui sur un serveur(/vm) dédié:
Je lancerais ma sauvegarde via un outils qui pourrait se connecter à mon instance, que ce soit un outil genre Commvault ou des plus simples genre Mysqldump ou Xtrabackup.
Éventuellement j’exécuterais ça dans un conteneur éphémère qui irait créer le jeu de sauvegarde sur un volume externe. J'archiverais ensuite le contenu de ce volume (bande, s3, glacier, whatever).
Reste à voir comment se feraient les restauration de données...

Et si la sauvegarde plombe vraiment les performances, il resterait la possibilité de rajouter un conteneur avec un slave et de faire la sauvegarde sur celui-ci.