Home > Docker Container Sicherungs- und Wiederherstellungslösungen

Docker Container Sicherungs- und Wiederherstellungslösungen

Die erste vollständig integrierte und automatisierte Sicherung von Docker-Volumes.

Bacula Enterprise ist die weltweit erste Sicherungs- und Wiederherstellungslösung der Enterprise-Klasse, die eine fortschrittliche, automatisierte Sicherung von Docker-Containern bietet. Sein Docker-Backup-Modul hebt die Benutzerfreundlichkeit von Containern auf eine neue Ebene. Diese weltweit führende Technologie wurde noch weiter aktualisiert und umfasst nun auch die Sicherung und Wiederherstellung von Docker-Volumes.

Dieses Modul ist über die offizielle Docker-API integriert und bedeutet, dass Benutzer schnell und einfach mehrere Docker-Container sichern können, ohne einen Agenten in jedem Container installieren zu müssen. Diese automatisierte Sicherung externer Docker-Volumes ist Teil von Baculas Fähigkeit zur vollständigen Integration der Orchestrierung. Es ist in den meisten Abonnementstufen von Bacula Enterprise für einen begrenzten Zeitraum ohne zusätzliche Kosten verfügbar.

Unabhängig davon, ob Ihre bereitgestellte Container-Umgebung für das Lift-and-Shift von monolithischen Anwendungen, das Refactoring von Legacy-Anwendungen oder die Erstellung neuer verteilter Anwendungen verwendet wird - Entwickler und Systemadministratoren können Baculas fortschrittliche Technologie mit einem besonders hohen Maß an Flexibilität nutzen - entweder über Baculas GUI oder die Kommandozeilen-Schnittstelle. Denken Sie daran, dass dieses hohe Maß an Flexibilität und Anpassungsmöglichkeiten grundlegend für den Ansatz von Bacula ist: den Benutzer zu befähigen, seine Ziele zu erreichen, indem man ihm eine breite Palette von Optionen zur Verfügung stellt.

Funktionen des Docker-Container-Backup-Moduls

  • Sicherung und Wiederherstellung der Konfiguration, der Volumes und der Images von Docker-Containern
  • Eine vollständig integrierte Lösung, die der Docker-Philosophie und -Methodik entspricht.
  • Vollständige Automatisierung für die schnelle Einführung von Container-Sicherungsstrategien
  • Vollkommen effektive Integration durch Nutzung der offiziellen Docker-API
  • Hilfe bei der Vorbereitung von neuen Docker-Images
  • Kostenlos mit Abonnements des Bronze Levels und höher (zeitlich begrenztes Angebot)
  • Speicherung von Images, Rollback von Images und Sicherung von Image-Änderungen
  • Detaillierte Kontrolle darüber, welche Container und Images gesichert oder nicht gesichert werden sollen
  • Kontrollierte Sicherung von definierten, spezifischen Docker-Images

Warum ist das Docker-Backup-Modul von Bacula einzigartig?

Die Bacula Enterprise Software ist so konzipiert, dass Unternehmen diese Docker Sicherungslösung für ihre gesamten physischen, virtuellen, Cloud- und alle hybriden Umgebungen, unabhängig von der Architektur, von einer einzigen Plattform aus bereitstellen können.

Effektive Docker-Sicherungen und -Wiederherstellungen sind besonders wichtig, denn wenn das Leben eines Containers endet, befinden sich darin möglicherweise noch benötigte Daten. Aufgrund der anspruchsvollen Eigenschaften von Docker-Umgebungen können andere Sicherungslösungen bis heute jedoch keine einfache und effiziente Sicherung von Docker-Containern durchführen - und in fast allen Fällen auch gar nicht. Bacula ist die einzige Lösung, die eine vollständig automatisierte Sicherung von Docker und seinen Datenbeständen bietet.

docker backup architecture

Sichere & effiziente Verwendung von Docker Containern

Bacula Enterprise macht die Nutzung von Docker sicherer und komfortabler. Es ist sogar möglich, nur von Docker definierte Images zu sichern, die bei Bedarf zur Erstellung neuer Container verwendet werden können. Unsere automatisierte und skalierbare Lösung wurde entwickelt, um die Workloads von IT und DevOps zu unterstützen, die Docker, SUSE, Caas oder Openshift verwenden.

Systemadministratoren und DevOps-Manager profitieren von dem hohen Maß an Steuerung und Verwaltungsflexibilität, die über die GUI oder die Weboberfläche von Bacula Enterprise bei der Durchführung von Docker-Sicherungen inkl. ihrer Datenvolumen verfügbar sind.

 

Testversion herunterladen Docker-Backup-Whitepaper

Vorsicht vor den Behauptungen anderer Anbieter

Einige Sicherungs- und Wiederherstellungsanbieter behaupten, Docker einschließlich seiner Volumes sichern zu können. Sie sind jedoch äußerst beschränkt und fügen einer containerisierten Anwendung einfach einen Container mit ihrem Client-Dienst hinzu und verwenden ihn zur Sicherung der spezifischen, benötigten Daten. Mit diesen Lösungen gibt es keinen unkomplizierten, anwendungsunabhängigen Wiederherstellungsprozess. Wie kann man also in diesem Fall Docker sichern? Der Administrator muss sich auf eine sorgfältige manuelle Konfiguration verlassen und die Beziehung der persistenten Speichereinheiten verstehen; zu welcher Anwendung sie gehören, welche Container sie nutzen und so weiter. Kurz gesagt, es ist eine Problemumgehung - keine effektive und schnelle Lösung.

Nur Bacula bietet eine voll integrierte, automatisierte und besonders schnelle Docker Sicherungs- und Wiederherstellungslösung. Mit dem fortschrittlichen Docker-Sicherungs- und Wiederherstellungsmodul von Bacula benötigen die Sicherungsteams keine Kenntnisse über Container-Interna, Anwendungen oder Speicherzuweisungen. Stattdessen werden Docker-Umgebungen durch Automatisierung effizienter und - was am wichtigsten ist - wertvolle Daten, die von einzelnen oder mehreren Containern erzeugt werden, werden gesichert.

Docker-Sicherungs- und Wiederherstellungsvorgänge

Docker-Sicherung

Die Sicherung eines einzelnen Docker-Containers besteht aus den folgenden einfachen Schritten:

  1. Speichern Sie den aktuellen Containerzustand in ein neues Image (Container-Commit - Snapshot).
  2. Führen Sie das Docker-Dienstprogramm aus und sichern Sie die Daten.
  3. Löschen Sie den gespeicherten Snapshot, um nicht benötigte Ressourcen freizugeben.

Die Sicherung eines Docker-System-Images stellt keinen Snapshot dar, da jedes System-Image eine Nur-Lese-Vorlage ist, die für die Container-Erstellung verwendet wird. Die Sicherung kann für Container in jedem Zustand (erstellt, gestartet oder gestoppt) durchgeführt werden. Das Docker-Sicherungsmodul informiert Sie über Start und Ende jeder Container- oder Image-Sicherung:


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.
...

Das Docker-Backup-Modul erstellt für jeden Container oder jedes Docker-Image, das gesichert wird, eine einzelne (.tar) Datei. In Bacula werden diese wie folgt dargestellt.

  • /@docker/container//.tar für Container-Sicherung
  • /@docker/image//.tar für Image-Sicherung.

Mehrere Dateien werden während einer Sicherung erstellt, wenn mehrere Container oder Docker-Images für die Sicherung mit einem Auftrag ausgewählt werden. Die eindeutigen Dateinamen, wie oben gezeigt, ermöglichen es, das richtige Container- oder System-Image-Archiv für die Wiederherstellung zu finden.
Um die verfügbaren Docker-Container oder System-Images aufzulisten, ist ein Auflistungsmodus verfügbar, der in Kapitel 6.1 auf Seite 12 beschrieben wird.

Docker-Wiederherstellung 

Das Docker-Sicherungsmodul bietet zwei Ziele für Wiederherstellungsvorgänge:

  • Wiederherstellung in den Docker-Dienst;
  • Wiederherstellen in ein lokales Verzeichnis als Archivdateien.

Wiederherstellen auf Docker-Dienst

Um diese Wiederherstellungsmethode zu verwenden, wird der Parameter where= oder where=/ eines Bacula Restore-Befehls verwendet.

Das Docker-Container-Archiv wird an den Docker-Dienst gesendet und als neues Image wiederhergestellt und dann als Container erstellt, wenn der Wiederherstellungsparameter container_create gesetzt ist (was der Standard ist). Wenn der Wiederherstellungsparameter container_create nicht gesetzt ist, wird jeder Container nur auf Image-Ebene wiederhergestellt und der Benutzer muss den Container manuell erstellen oder ausführen. Wenn der Wiederherstellungsparameter container_run gesetzt ist (Standard ist "no"), wird der wiederhergestellte Container sofort nach erfolgreicher Wiederherstellung gestartet.

Das Docker-Image-Archiv wird in den Docker-Dienst als das ursprüngliche Docker-Image geladen und überschreibt das bereits vorhandene. Dies ist das Standardverhalten und kann geändert werden, indem die Option "Replace" des Wiederherstellungsbefehls wie gewünscht gesetzt wird. Mit der Replace-Option des Restore-Befehls können Sie die Wiederherstellung des Docker-Images eines bereits vorhandenen Images überspringen.

Der Standard-Containername oder die Container-Image-Bezeichnung kann während einer Wiederherstellung mit den Wiederherstellungsparametern container_defaultnames oder container_imageid geändert werden (siehe Abschnitt 4.2 auf Seite 8).

Wiederherstellen auf lokales Verzeichnis

Um diesen Modus zu verwenden, wird der Bacula-Restore-Parameter where=/some/path auf einen vollständigen Pfad auf dem Server gesetzt, auf dem das Docker-Modul installiert ist. Wenn der Pfad nicht vorhanden ist, wird er vom Bacula-Docker-Modul erstellt.

Installation des Docker-Backup-Moduls

Der Bacula-Agent und sein Docker-Backup-Modul müssen auf dem Host für den Docker-Dienst installiert werden. Docker kann auf verschiedenen Betriebssystemen und Distributionen installiert sein, daher muss der Bacula Enterprise File Daemon für dieses Betriebssystem und diese Plattform verwendet werden.

Konfiguration des Docker-Backup-Moduls

Das Modul wird mit Modulparametern konfiguriert, die in einem FileSets Include-Abschnitt der Bacula Enterprise Director-Konfiguration definiert sind.

Schätzung und Docker-Sicherungsmodul-Parameter

Diese optionalen Modulparameter sind nur für Sicherungs- und Schätzungsaufträge relevant:

  • Geben Sie einen Docker-Container für die Sicherung an.
    Mehrere container=<. . . > Parameter sind erlaubt. Wenn ein Container mit <name-label> nicht gefunden werden kann, wird ein einzelner Auftragsfehler generiert und die Sicherung wird mit dem nächsten Container fortgesetzt, sofern nicht abort_on_error gesetzt ist, was zum Abbruch des gesamten Sicherungsauftrags führt. Docker-Containernamen (<name-label>) oder Container-IDs (<id>) können verwendet werden, um Container für die Sicherung auszuwählen.
  • Geben Sie ein Docker-Image an, das gesichert werden soll.
    Mehrere image=< . . . > Parameter sind erlaubt. Wenn ein Image mit <repository:tag> nicht gefunden werden kann, wird ein einzelner Auftragsfehler erzeugt und die Sicherung wird mit dem nächsten Image fortgesetzt, sofern nicht abort_on_error gesetzt ist, wodurch der gesamte Sicherungsauftrag abgebrochen wird. Docker-Image-Repository und Tag-Namen (<repository:tag>) oder Image-IDs (<id>) können verwendet werden, um das gewünschte Image für die Sicherung auszuwählen. Dieser Parameter ist optional.
  • Geben Sie eine Liste der zu sichernden Docker-Containernamen mit der Syntax eines regulären Ausdrucks an.
    Alle Container, deren Namen mit dem angegebenen regulären Ausdruck übereinstimmen, werden für die Sicherung ausgewählt. Mehrere include_container=<. . . > Parameter können angegeben werden. Wenn keine Container mit dem angegebenen Namensausdruck übereinstimmen, wird die Sicherung mit dem nächsten Parameter fortgesetzt oder erfolgreich beendet, ohne dass ein Container gesichert wird. Der Parameter "abort_on_error" bricht den Auftrag nicht ab, wenn keine Container gefunden werden, die dem Namensausdruck entsprechen.
  • Geben Sie eine Liste von Docker-Image-Repository-Namen an, die mit der Syntax eines regulären Ausdrucks gesichert werden sollen.
    Alle Images mit Repository-Namen, die mit dem angegebenen regulären Ausdruck übereinstimmen, werden für die Sicherung ausgewählt. Mehrere include_images=<. . . > können als Parameter angegeben werden. Wenn keine Images mit dem angegebenen Ausdruck für den Repository-Namen übereinstimmen, wird die Sicherung mit dem nächsten Parameter fortgesetzt oder erfolgreich beendet, ohne dass irgendwelche Images gesichert werden. Der Parameter "abort_on_error" bricht den Auftrag nicht ab, wenn keine Images über den Repository-Namensabgleich gefunden werden.
  • Geben Sie eine Liste von Docker-Containernamen an, die mithilfe eines regulären Ausdrucks von der Sicherung ausgeschlossen werden sollen.
    Alle Container, deren Namen mit dem angegebenen regulären Ausdruck übereinstimmen und die mit dem Parameter include_container=<. . .> ausgewählt wurden, werden ausgeschlossen. Dieser Parameter wirkt sich nicht auf Container aus, die für die Sicherung mit dem Parameter container=<. . .> ausgewählt wurden. Mehrere exclude_container=<. . .> Parameter können angegeben werden.
  • Geben Sie eine Liste von Docker-Image-Repository-Namen an, die mithilfe eines regulären Ausdrucks von der Sicherung ausgeschlossen werden sollen.
    Alle Images, deren Repository-Namen mit dem angegebenen regulären Ausdruck übereinstimmen und die mit dem Parameter include_image=<. . .> ausgewählt wurden, werden ausgeschlossen. Dieser Parameter wirkt sich nicht auf Images aus, die für die Sicherung mit dem Parameter image=<. . .> ausgewählt wurden. Mehrere exclude_image=<. . .> Parameter können angegeben werden.

Wiederherstellungsparameter des Docker-Sicherungsmoduls

Während einer Wiederherstellung verwendet das Docker-Sicherungsmodul dieselben optionalen Parameter, die für den Sicherungsauftrag festgelegt und im Katalog gespeichert wurden. Einige von ihnen können bei Bedarf während des Wiederherstellungsprozesses geändert werden.

container_create: <yes|no> gibt an, ob die Docker-Container-Wiederherstellung automatisch einen Container erstellen soll. Die Standardoption ist das Erstellen von Containern bei der Wiederherstellung. Wenn Container als Images wiederhergestellt werden sollen, sollte dieser Parameter auf no gesetzt werden.

container_run: <yes|no> gibt an, ob die Docker-Container-Wiederherstellung automatisch wiederhergestellte Container erstellen und ausführen soll. Die Standardoption besteht darin, wiederhergestellte Container nicht automatisch auszuführen. Wenn Container sofort nach der Wiederherstellung ausgeführt werden sollen, sollte dieser Parameter auf yes gesetzt werden.

Wenn dieser Parameter auf yes gesetzt ist, wird der Parameter container_create ignoriert.

container_imageid: <yes|no> gibt an, ob das Docker-Modul die Image-ID-Werte zum Erstellen oder Ausführen wiederhergestellter Container verwenden soll. Standardmäßig werden zu diesem Zweck Image-Repository- und Tag-Werte verwendet. Dieser Parameter wird ignoriert, wenn sowohl container_create als auch container_run auf no gesetzt sind, da kein Container-Erstellungs- oder Ausführungsvorgang durchgeführt wird.

container_defaultnames: <yes|no> gibt an, ob das Docker-Modul Containernamen basierend auf den ursprünglichen Containernamen und JobId-Werten einrichten soll, was der Standard ist. Wenn dieser Parameter auf yes gesetzt ist, legt der Docker-Dienst Standardnamen für erstellte oder ausgeführte Container fest.


Beispiele für Docker Backup FileSets

Im folgenden Beispiel werden alle Docker-Container und -Images gesichert.


FileSet {
Name = FS_DockerAll
Include {
Plugin = "docker:"
}
}

In diesem Beispiel wird ein einzelner Docker-Container mit dem Namens-Label "mcache1" gesichert.


FileSet {
Name = FS_Docker_mcache1
Include {
Plugin = "docker: container=mcache1"
}
}

Dasselbe Beispiel wie oben, aber stattdessen wird die Container-ID verwendet:


FileSet {
Name = FS_Docker_mcache1
Include {
Plugin = "docker: container=cd77eb89e59a"
}
}

Im folgenden Beispiel werden alle Docker-Container gesichert, die "ngnix" in ihrem Namen enthalten.


FileSet {
Name = FS_Docker_nginixAll
Include {
Plugin = "docker: include_container=ngnix"
}
}

In diesem letzten Beispiel werden alle Docker-Container außer denen, deren Namen mit "test" beginnen, gesichert.


FileSet {
Name = FS_Docker_AllbutTest
Include {
Plugin = "docker: include_container=.* exclude_container=^test"
}
}

Docker-Wiederherstellungsszenarien

Wiederherstellen auf einen Docker-Dienst

Um einen Container oder ein Image in einem Docker-Dienst wiederherzustellen, sollte der Administrator den Befehl restore ausführen und den Parameter where wie in diesem Beispiel angeben:


* restore where=/

und dann alle anderen erforderlichen Wiederherstellungsmodulparameter für die Wiederherstellung festlegen. Im folgenden Beispiel für eine Wiederherstellungssitzung ist die Wiederherstellungsoption des Plugins container_run auf "Yes" gesetzt:


* 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

Das Protokoll des Wiederherstellungsauftrags gibt an, welcher Container wiederhergestellt wurde und welche neue Container-ID erstellt wurde:


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

Der neue Container, der während der Wiederherstellung erstellt wurde, erhält eine neue Container-ID. Dies kann überprüft werden, indem ein Befehl wie der folgende ausgeführt wird:


# docker ps -a
CONTAINER ID IMAGE CREATED STATUS
ef48c6b5b867 mcache1/b97d4dd88063/139:restore 4 minutes ago Up 4 minutes

Wiederherstellen in ein lokales Verzeichnis

Es ist möglich, die Daten der Container-Images und Docker-Vorlagen-Images in einer Datei wiederherzustellen, ohne sie in den Docker-Dienst hochzuladen. Dazu sollte die Wiederherstellungsoption where auf das lokale Verzeichnis zeigen:


* restore where=/tmp/bacula/restores

Bitte prüfen Sie das folgende Beispiel für die Nachricht "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(...)

Das Protokoll des Wiederherstellungsauftrags zeigt, dass die Wiederherstellung in ein lokales Verzeichnis erfolgt ist. Das obige Protokoll wurde für eine bessere Übersichtlichkeit abgeschnitten.


Weitere Hilfe zur Sicherung von Docker-Containern: