Sauvegarde et restauration de conteneurs Docker
Bacula Enterprise est la première solution de sauvegarde et de restauration au monde à offrir une sauvegarde avancée et automatisée des conteneurs Docker. Son module de sauvegarde Docker porte la facilité d’utilisation des conteneurs à un nouveau niveau. Cette technologie de pointe a été mise à jour pour inclure la sauvegarde et la restauration des volumes Docker.
Ce module est intégré via l’API officielle de Docker et permet aux utilisateurs de sauvegarder rapidement et facilement plusieurs conteneurs Docker sans avoir à installer un agent dans chaque conteneur. Cette sauvegarde automatisée des volumes Docker externes fait partie de la capacité de Bacula à s’intégrer complètement à l’orchestration. Elle est disponible à la plupart des niveaux d’abonnement de Bacula Enterprise sans coût supplémentaire pour une période limitée.
Que votre environnement de conteneurs déployé soit utilisé pour le « lift-and-shift » d’applications monolithiques, la refonte d’applications existantes ou la création de nouvelles applications distribuées, les développeurs et les administrateurs système peuvent utiliser la technologie avancée de Bacula avec un niveau de flexibilité particulièrement élevé – via l’interface graphique ou la ligne de commande de Bacula. Rappelez-vous, ce haut niveau de flexibilité et de possibilités de personnalisation est fondamental dans l’approche de Bacula : donner à l’utilisateur les moyens d’atteindre ses objectifs en lui offrant un large éventail d’options.
Caractéristiques du module de sauvegarde des conteneurs Docker
- Sauvegarde et restauration de la configuration, des volumes et des images des conteneurs Docker.
- Solution entièrement intégrée, adhérant à la philosophie et à la méthodologie de Docker
- Automatisation complète pour un déploiement rapide des stratégies de protection des conteneurs
- Intégration entièrement efficace, utilisant l’API officielle de Docker
- Aide à la préparation de nouvelles images Docker
- Gratuit avec les abonnements de niveau bronze et plus (offre à durée limitée)
- Sauvegarde des images, retour en arrière et sauvegarde des modifications apportées aux images
- Contrôle fin des conteneurs et des images à sauvegarder ou non.
- Sauvegarde contrôlée d’images Docker spécifiques et définies.
Pourquoi le module de sauvegarde Docker de Bacula est-il unique ?
Le logiciel Bacula Enterprise est conçu pour que les entreprises puissent déployer cette solution de sauvegarde Docker pour l’ensemble de leurs environnements physiques, virtuels, cloud et tous les environnements hybrides, quelle que soit l’architecture, le tout à partir d’une seule plateforme.
Une sauvegarde et une restauration Docker efficaces sont particulièrement importantes car, lorsque la vie d’un conteneur prend fin, il peut contenir des données dont on a besoin. Cependant, en raison de la nature difficile des environnements Docker, les autres solutions de sauvegarde ne peuvent pas, à ce jour, effectuer une sauvegarde simple et efficace des conteneurs Docker – et dans presque tous les cas, pas du tout. Bacula est la seule solution à fournir une sauvegarde entièrement automatisée de Docker et de ses volumes de données.
Utilisation sûre et efficace des conteneurs Docker
Bacula Enterprise rend l’utilisation de Docker plus fiable et plus pratique. Il est même possible de sauvegarder uniquement les images définies par Docker, qui peuvent être utilisées pour créer de nouveaux conteneurs si nécessaire. Notre solution automatisée et évolutive a été conçue pour supporter les charges de travail des équipes informatiques et DevOps qui utilisent Docker, SUSE, Caas ou Openshift.
Les administrateurs systèmes et les responsables DevOps bénéficient du haut niveau de contrôle et de la flexibilité de gestion disponibles via l’interface graphique ou l’interface web de Bacula Enterprise lorsqu’ils effectuent des sauvegardes de Docker, y compris de ses volumes de données.
Télécharger une version d’essai Whitebook sur la sauvegarde de Docker
Méfiez-vous des affirmations d’autres vendeurs
Certains fournisseurs de solutions de sauvegarde et de restauration prétendent être en mesure de sauvegarder Docker et ses volumes. Ils sont toutefois extrêmement limités et se contentent d’ajouter un conteneur avec leur service client à une application conteneurisée et de l’utiliser pour sauvegarder les données spécifiques requises. Avec ces solutions, il n’existe pas de processus de restauration simple et indépendant de l’application. Alors comment sauvegarder Docker dans ce cas ? L’administrateur doit cependant s’appuyer sur une configuration manuelle minutieuse et comprendre la relation entre les entités de stockage persistant : à quelle application elles appartiennent, quels conteneurs les utilisent, etc. En bref, il s’agit d’une solution de contournement, et non d’une solution efficace et rapide.
Seul Bacula offre une solution de sauvegarde et de restauration Docker entièrement intégrée, automatisée et particulièrement rapide. Avec le module avancé de sauvegarde et de restauration Docker de Bacula, les équipes de sauvegarde n’ont pas besoin de connaître les internes des conteneurs, les applications ou les affectations de stockage. Au lieu de cela, les environnements Docker deviennent plus efficaces grâce à l’automatisation et – plus important encore – sauvegardent les précieuses données générées par un ou plusieurs conteneurs.
Opérations de sauvegarde et de restauration Docker
Sauvegarde de Docker
La sauvegarde d’un seul conteneur Docker se compose des étapes simples suivantes :
- Sauvegarder l’état actuel du conteneur dans une nouvelle image (container commit – snapshot).
- Exécuter l’utilitaire Docker et sauvegarder les données.
- Supprimer l’instantané sauvegardé pour libérer les ressources inutiles.
La sauvegarde d’une image système Docker ne crée pas d’instantané car chaque image système est un modèle en lecture seule utilisé pour la création du conteneur. Les sauvegardes peuvent être effectuées pour un conteneur dans n’importe quel état (créé, en cours d’exécution ou arrêté). Le module de sauvegarde Docker vous informera du début et de la fin de chaque sauvegarde de conteneur ou d’image :
JobId 127: docker: Start Backup docker Container: myubuntu (4d0a4fadb50d)
JobId 127: dkcommctx: Commit created: myubuntu/4d0a4fadb50d/127:backup
JobId 127: dkcommctx: Commit removed: myubuntu/4d0a4fadb50d/127:backup
JobId 127: docker: Backup of docker Container: myubuntu (4d0a4fadb50d) OK.
…
Le module de sauvegarde Docker créera un seul fichier (.tar) pour tout conteneur ou image Docker qui est sauvegardé. Dans Bacula, ces fichiers sont représentés comme suit.
- /@docker/container//.tar for container backup
- /@docker/image//.tar for image backup
Plusieurs fichiers seront créés pendant une sauvegarde si plusieurs conteneurs ou images Docker sont sélectionnés pour être sauvegardés avec une seule tâche. Les noms de fichiers distincts, comme indiqué ci-dessus, permettent de localiser le conteneur ou l’image système approprié pour la restauration.
Restauration de Docker
Le module de sauvegarde Docker fournit deux cibles pour les opérations de restauration :
- Restaurer vers le service Docker ;
- Restaurer vers un répertoire local en tant que fichiers d’archive.
Restauration vers un Service Docker
Pour utiliser cette méthode de restauration, le paramètre where= ou where=/ d’une commande de restauration Bacula est utilisé.
L’archive du conteneur Docker sera envoyée au service Docker et restaurée comme une nouvelle image puis créée comme conteneur si le paramètre de restauration container_create est défini (ce qui est le cas par défaut). Si le paramètre de restauration container_create n’est pas défini, tout conteneur sera restauré au niveau de l’image uniquement et l’utilisateur devra créer ou exécuter le conteneur manuellement. Si le paramètre de restauration container_run est défini (la valeur par défaut est « no »), le conteneur restauré sera démarré immédiatement après une restauration réussie.
L’archive de l’image Docker sera chargée dans le service Docker en tant qu’image Docker originale, écrasant celle qui existe déjà. Il s’agit du comportement par défaut et il peut être modifié en définissant l’option « Replace » de la commande de restauration comme vous le souhaitez. Vous pouvez ignorer la restauration d’une image Docker déjà existante avec l’option « Replace » ou la commande ‘’Restore’’.
Le nom de conteneur ou le label d’image de conteneur par défaut peut être modifié pendant une restauration avec les paramètres de restauration container_defaultnames ou container_imageid (voir section 4.2 à la page 8).
Restauration vers un répertoire local
Pour utiliser ce mode, le paramètre where=/some/path de ‘’Restore’’ Bacula est défini comme un chemin complet sur le serveur où le module Docker est installé. Si le chemin n’existe pas, il sera créé par le module Docker de Bacula.
Installation du module de sauvegarde Docker
L’agent Bacula et son module de sauvegarde Docker doivent être installés sur l’hôte du service Docker. Docker pouvant être installé sur différents systèmes d’exploitation et distributions, il convient d’utiliser le Bacula Enterprise File Daemon correspondant à ce système d’exploitation et à cette plate-forme.
Configuration du module de sauvegarde Docker
Le module est configuré à l’aide des paramètres du module définis dans une section FileSets Include de la configuration du Bacula Enterprise Director.
Paramètres d’estimation et du module Docker Backup
Ces paramètres de module facultatifs ne sont pertinents que pour les tâches de sauvegarde et d’estimation :
- Spécifiez un conteneur Docker à sauvegarder.
Multiple container=<. . . > sont autorisés. Si un conteneur avec <nom-label> ne peut être trouvé, alors une erreur de travail unique sera générée et la sauvegarde passera au conteneur suivant, à moins que abort_on_error ne soit défini, ce qui entraînera l’abandon du travail de sauvegarde complet. Les noms de conteneurs Docker (<name-label>) ou les ids de conteneurs (<id>) peuvent être utilisés pour sélectionner les conteneurs à sauvegarder.
- Spécifiez une image Docker à sauvegarder.
Plusieurs paramètres image=< . . . > sont autorisés. Si une image avec <repository:tag> ne peut être trouvée, une erreur de travail unique sera générée et la sauvegarde passera à l’image suivante, à moins que abort_on_error ne soit défini, ce qui entraînera l’abandon du travail de sauvegarde complet. Les noms du dépôt d’images Docker et des étiquettes (<repository:tag>) ou les identifiants d’images (<id>) peuvent être utilisés pour sélectionner l’image requise pour la sauvegarde. Ce paramètre est facultatif.
- Spécifier une liste de noms de conteneurs Docker à sauvegarder en utilisant la syntaxe d’expression régulière.
Tous les conteneurs dont les noms correspondent à l’expression régulière fournie seront sélectionnés pour la sauvegarde. Plusieurs include_container=<. . . > peuvent être fournis. Si aucun conteneur ne correspond à l’expression de nom fournie, la sauvegarde passera au paramètre suivant ou se terminera avec succès sans sauvegarder aucun conteneur. Le paramètre abort_on_error n’interrompra pas le travail si aucun conteneur n’est trouvé en utilisant la correspondance des noms.
- Spécifiez une liste de noms de référentiels d’images Docker à sauvegarder en utilisant la syntaxe des expressions régulières.
Toutes les images dont le nom de référentiel correspond à l’expression régulière fournie seront sélectionnées pour la sauvegarde. Plusieurs include_images=<. . . > peuvent être fournis. Si aucune image ne correspond à l’expression de nom de référentiel fournie, la sauvegarde passera au paramètre suivant ou se terminera avec succès sans sauvegarder aucune image. Le paramètre abort_on_error n’interrompra pas le travail si aucune image n’est trouvée en utilisant la correspondance du nom du dépôt.
- Spécifiez une liste de noms de conteneurs Docker qui seront exclus de la sauvegarde à l’aide de la correspondance par expression régulière.
Tous les conteneurs dont les noms correspondent à l’expression régulière fournie, et sélectionnés pour la sauvegarde à l’aide du paramètre include_container=<. . .> seront exclus. Ce paramètre n’affecte pas les conteneurs sélectionnés pour être sauvegardés en utilisant le paramètre container=<. . .>. Plusieurs paramètres exclude_container=<. . .> peuvent être fournis. - Spécifiez une liste de noms de référentiels d’images Docker qui seront exclus de la sauvegarde à l’aide d’une correspondance par expression régulière.
Toutes les images dont les noms de référentiel correspondent à l’expression régulière fournie et qui sont sélectionnées pour la sauvegarde à l’aide du paramètre include_image=<. . .> seront exclues. Ce paramètre n’affecte pas les images sélectionnées pour être sauvegardées en utilisant le paramètre image=<. . .>. Plusieurs paramètres exclude_image=<. . .> peuvent être fournis.
Paramètres de restauration du module de sauvegarde Docker
Lors d’une restauration, le module de sauvegarde Docker utilisera les mêmes paramètres facultatifs qui ont été définis pour la tâche de sauvegarde et enregistrés dans le catalogue. Certains d’entre eux peuvent être modifiés pendant le processus de restauration si nécessaire.
container_create : <yes|no> spécifie si la restauration de conteneur Docker doit créer automatiquement un conteneur. L’option par défaut consiste à créer les conteneurs lors de la restauration. Si les conteneurs doivent être restaurés en tant qu’images, ce paramètre doit être défini sur no.
container_run : <yes|no> spécifie si Docker container restore doit automatiquement créer et exécuter les conteneurs restaurés. L’option par défaut consiste à ne pas exécuter automatiquement les conteneurs restaurés. Si les conteneurs sont censés être exécutés immédiatement après avoir été restaurés, ce paramètre doit être défini sur yes.
Si ce paramètre a la valeur yes, le paramètre container_create sera ignoré.
container_imageid : <yes|no> spécifie si le module Docker doit utiliser les valeurs d’id d’image pour créer ou exécuter les conteneurs restaurés. Par défaut, les valeurs de dépôt d’images et de tags sont utilisées à cette fin. Ce paramètre sera ignoré lorsque container_create et container_run sont tous deux définis sur no car aucune opération de création ou d’exécution de conteneur ne sera effectuée.
container_defaultnames : <yes|no> spécifie si le module Docker doit configurer les noms de conteneurs en fonction du nom de conteneur original et des valeurs JobId, ce qui est la valeur par défaut. Si ce paramètre est défini à yes, le service Docker configurera les noms par défaut pour les conteneurs créés ou exécutés.
Exemples d’ensembles de fichiers de sauvegarde Docker
Dans l’exemple ci-dessous, tous les conteneurs et images Docker seront sauvegardés.
FileSet {
Name = FS_DockerAll
Include {
Plugin = « docker: »
}
}
Dans cet exemple, un seul conteneur Docker avec le nom-label de « mcache1 » sera sauvegardé.
FileSet {
Name = FS_Docker_mcache1
Include {
Plugin = « docker: container=mcache1 »
}
}
Le même exemple que ci-dessus, mais en utilisant l’id du conteneur à la place :
FileSet {
Name = FS_Docker_mcache1
Include {
Plugin = « docker: container=cd77eb89e59a »
}
}
Dans l’exemple suivant, tous les conteneurs Docker qui contiennent « ngnix » dans leur nom seront sauvegardés.
FileSet {
Name = FS_Docker_nginixAll
Include {
Plugin = « docker: include_container=ngnix »
}
}
Dans ce dernier exemple, tous les conteneurs Docker, sauf ceux dont le nom commence par « test », seront sauvegardés.
FileSet {
Name = FS_Docker_AllbutTest
Include {
Plugin = « docker: include_container=.* exclude_container=^test »
}
}
Scénarios de restauration Docker
Restauration vers un service Docker
Pour restaurer un conteneur ou une image vers un service Docker, l’administrateur doit exécuter la commande restore et spécifier le paramètre where comme dans cet exemple :
* restore where=/
puis définissez tous les autres paramètres du module de restauration requis pour la restauration. Dans l’exemple de session de restauration suivant, l’option de restauration du plugin container_run est définie sur « Yes » :
* restore where=/
…
Run Restore job
JobName: RestoreFiles
Bootstrap: /opt/bacula/working/docker-test-dir.restore.1.bsr
Where: /
Replace: Always
FileSet: Full Set
Backup Client: docker-test-fd
Restore Client: docker-test-fd
Storage: File1
When: 2018-09-28 14:09:30
Catalog: MyCatalog
Priority: 10
Plugin Options: *None*
OK to run? (yes/mod/no): mod
Parameters to modify:
1: Level
2: Storage
3: Job
4: FileSet
5: Restore Client
6: When
7: Priority
8: Bootstrap
9: Where
10: File Relocation
11: Replace
12: JobId
13: Plugin Options
Select parameter to modify (1-13): 13
Automatically selected : docker: container=mcache1 abort_on_error
Plugin Restore Options
container_create: *None* (*Yes*)
container_run: *None* (*No*)
container_imageid: *None* (*No*)
container_defaultnames: *None* (*No*)
Use above plugin configuration? (yes/mod/no): mod
You have the following choices:
1: container_create (Create container on restore)
2: container_run (Run container on restore)
3: container_imageid (Use Image Id for container creation/start)
4: container_defaultnames (Use default docker Names on container creation)
Select parameter to modify (1-4): 2
Please enter a value for container_run: yes
Plugin Restore Options
container_create: *None* (*Yes*)
container_run: yes (*No*)
container_imageid: *None* (*No*)
container_defaultnames: *None* (*No*)
Use above plugin configuration? (yes/mod/no): yes
Le journal du travail de restauration indiquera quel conteneur a été restauré et quel nouvel identifiant de conteneur a été créé :
JobId 139: Start Restore Job RestoreFiles.2018-09-28_14.13.31_03
JobId 139: Using Device « FileChgr1-Dev1 » to read.
JobId 139: Ready to read from volume « vol001 » on File device « FileChgr1-Dev1 » (/opt/bacula/archive).
JobId 139: Forward spacing Volume « vol001 » to addr=225
JobId 139: docker: docker Container restore: mcache1/b97d4dd88063
JobId 139: End of Volume « vol001 » at addr=62177197 on device « FileChgr1-Dev1 » (/opt/bacula/archive).
JobId 139: dkcommctx: Successfully run container as: ef48c6b5b867
Le nouveau conteneur créé lors de la restauration obtiendra un nouvel identifiant de conteneur. Ceci peut être vérifié en exécutant une commande telle que :
# docker ps -a
CONTAINER ID IMAGE CREATED STATUS
ef48c6b5b867 mcache1/b97d4dd88063/139:restore 4 minutes ago Up 4 minutes
Restauration vers un répertoire local
Il est possible de restaurer les données des images de conteneurs et des images de modèles Docker dans un fichier sans les charger dans le service Docker. Pour ce faire, l’option where restore doit pointer vers le répertoire local :
* restore where=/tmp/bacula/restores
Veuillez consulter l’exemple suivant pour le message « Docker local restore » :
JobId 141: Start Restore Job RestoreFiles.2018-09-28_14.26.34_03
JobId 141: Using Device « FileChgr1-Dev1 » to read.
JobId 141: Ready to read from volume « vol001 » on File device « FileChgr1-Dev1 » (/opt/bacula/archive).
JobId 141: docker: docker local restore: container/mcache1/b97d4dd8806(…)
Le journal du travail de restauration montrera que la restauration a été effectuée dans un répertoire local. Le journal ci-dessus a été tronqué pour une vue plus claire.
Vous pouvez également être intéressé par :
