Principale > Backup dei dati corporativo > Strumenti di backup dei dati aziendali > Backup e ripristino dei contenitori Docker

Backup e ripristino dei contenitori Docker con i volumi

Il primo backup del volume Docker completamente integrato e automatizzato.

Bacula Enterprise è la prima soluzione di backup e ripristino di classe enterprise al mondo ad offrire un backup avanzato e automatizzato dei container Docker. Il suo modulo di backup Docker porta la facilità d’uso dei container ad un nuovo livello. Questa tecnologia leader a livello mondiale è stata ulteriormente aggiornata per includere anche il backup e il ripristino dei volumi Docker.

Questo modulo è integrato tramite l’API ufficiale di Docker e significa che gli utenti possono eseguire rapidamente e facilmente il backup di più container Docker senza dover installare un agente all’interno di ciascun container. Questo backup automatico dei volumi Docker esterni fa parte della capacità di Bacula di integrare completamente l’orchestrazione. È disponibile nella maggior parte dei livelli di abbonamento di Bacula Enterprise senza costi aggiuntivi per un periodo di tempo limitato.

Sia che il suo ambiente di container sia utilizzato per il lift-and-shift di applicazioni monolitiche, sia che si tratti di refactoring di applicazioni legacy, sia che si tratti di nuove applicazioni distribuite, gli sviluppatori e gli amministratori di sistema possono utilizzare la tecnologia avanzata di Bacula con un livello di flessibilità particolarmente elevato, sia tramite l’interfaccia GUI che tramite l’interfaccia della riga di comando di Bacula. Ricordiamo che questo alto livello di flessibilità e di possibilità di personalizzazione è fondamentale per l’approccio di Bacula: responsabilizzare l’utente introducendo un’ampia gamma di opzioni per raggiungere i suoi obiettivi.

Caratteristiche del modulo di backup dei contenitori Docker

  • Backup e ripristino della configurazione del contenitore Docker, dei volumi e delle immagini
  • Soluzione completamente integrata, aderente alla filosofia e alla metodologia Docker
  • Automazione completa per un rapido roll-out delle strategie di protezione dei container
  • Integrazione completamente efficace, utilizzando l’API ufficiale di Docker
  • Aiuta la preparazione di nuove immagini Docker
  • Salvataggio dell’immagine, rollback dell’immagine e backup delle modifiche dell’immagine
  • Controllo a grana fine su quali contenitori e immagini eseguire o meno il backup
  • Backup controllato di immagini Docker definite e specifiche

Perché il modulo di backup Docker di Bacula è unico?

Il software Bacula Enterprise è stato progettato in modo che le organizzazioni possano implementare questa soluzione di backup Docker per tutti i loro ambienti fisici, virtuali, cloud e ibridi, indipendentemente dall’architettura, il tutto da un’unica piattaforma.

Un backup e un ripristino Docker efficaci sono particolarmente importanti, perché quando la vita di un container termina, è possibile che al suo interno vi siano dati necessari. Tuttavia, a causa della natura difficile degli ambienti Docker, altre soluzioni di backup non sono in grado, ad oggi, di eseguire un backup semplice ed efficiente dei container Docker – e in quasi tutti i casi, non lo fanno affatto. Bacula è l’unica soluzione che offre un backup completamente automatizzato di Docker e dei suoi volumi di dati.

docker backup architecture

Uso sicuro ed efficiente dei contenitori Docker

Bacula Enterprise rende l’uso di Docker più affidabile e conveniente. È persino possibile eseguire il backup delle sole immagini definite da Docker, che possono essere utilizzate per creare nuovi container quando necessario. La nostra soluzione automatizzata e scalabile è stata realizzata per supportare i carichi di lavoro di IT e DevOps che utilizzano Docker, SUSE, Caas o Openshift.

Gli amministratori di sistema e i manager DevOps beneficiano dell’elevato livello di controllo e della flessibilità di gestione disponibili tramite l’interfaccia GUI o web di Bacula Enterprise quando eseguono i backup di Docker, compresi i suoi volumi di dati.

 

Scarica la prova Whitepaper sul backup di Docker

Attenzione alle affermazioni di altri venditori

Alcuni fornitori di backup e ripristino affermano di essere in grado di eseguire il backup di Docker, inclusi i suoi volumi. Tuttavia, sono estremamente limitati e si limitano ad aggiungere un contenitore con il loro servizio client a un’applicazione containerizzata e a utilizzarlo per eseguire il backup dei dati specifici richiesti. Con queste soluzioni, non è disponibile un processo di ripristino diretto e indipendente dall’applicazione. Quindi come fare il backup di Docker in questo caso? L’amministratore deve però affidarsi a un’attenta configurazione manuale, oltre a comprendere la relazione tra le entità di archiviazione persistente: a quale applicazione appartengono, quali container le utilizzano e così via. In breve, si tratta di un workaround, non di una soluzione efficace e veloce.

Solo Bacula offre una soluzione di backup e ripristino Docker completamente integrata, automatizzata e particolarmente veloce. Con il modulo avanzato di backup e ripristino Docker di Bacula, i team di backup non hanno bisogno di conoscere gli interni dei container, le applicazioni o le assegnazioni di storage. Al contrario, gli ambienti Docker diventano più efficienti grazie all’automazione e – cosa più importante – salvano i dati preziosi generati da container singoli o multipli.

Operazioni di backup e ripristino di Docker

Backup di Docker

Il backup di un singolo contenitore Docker consiste nei seguenti semplici passaggi:

  1. Salvare lo stato attuale del contenitore in una nuova immagine (commit del contenitore – snapshot).
  2. Eseguire l’utilità Docker e salvare i dati.
  3. Rimuovere l’istantanea salvata per liberare le risorse non necessarie.

Il backup di un’immagine di sistema Docker non crea un’istantanea, poiché ogni immagine di sistema è un modello di sola lettura utilizzato per la creazione di container. I backup possono essere eseguiti per i container in qualsiasi stato (creati, in esecuzione o fermati). Il modulo di backup di Docker la informerà dell’inizio e della fine di ogni backup del contenitore o dell’immagine:


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.

Il modulo di backup Docker creerà un singolo file (.tar) per ogni contenitore o immagine Docker che viene salvata. All’interno di Bacula, questi sono rappresentati come segue.

  • /@docker/container//.tar per il backup del contenitore
  • /@docker/image//.tar per il backup delle immagini

Verranno creati più file durante un backup se vengono selezionati più contenitori o immagini Docker per il backup con un unico lavoro. I nomi distinti dei file, come mostrato sopra, consentono di individuare l’archivio del contenitore o dell’immagine di sistema appropriato per il ripristino.
Per elencare i contenitori Docker o le immagini di sistema disponibili, è disponibile una modalità di elencazione, descritta nel capitolo 6.1, a pagina 12.

Ripristino Docker 

Il modulo di backup di Docker fornisce due obiettivi per le operazioni di ripristino:

  • Ripristino nel servizio Docker;
  • Ripristino in una directory locale come file di archivio.

Ripristino del servizio Docker

Per utilizzare questo metodo di ripristino, viene utilizzato il parametro where= o where=/ di un comando Bacula di ripristino.

L’archivio del contenitore Docker sarà inviato al servizio Docker e ripristinato come nuova immagine e quindi creato come contenitore se il parametro container_create restore è set (che è quello predefinito). Se il parametro di ripristino container_create non è impostato, qualsiasi contenitore verrà ripristinato solo a livello di immagine e l’utente dovrà creare o eseguire il contenitore manualmente.
Se il parametro di ripristino container_run è impostato (l’impostazione predefinita è “no“), il contenitore ripristinato sarà avviato immediatamente dopo il successo del ripristino.

L’archivio dell’immagine Docker sarà caricato nel servizio Docker come immagine Docker originale, sovrascrivendo quella già esistente. Questo è il comportamento predefinito e può essere modificato impostando l’opzione ‘Replace’ del comando di ripristino come desiderato. Può saltare il ripristino dell’immagine Docker già esistente con l’opzione Replace opzione del comando restore.

Il nome predefinito del contenitore o l’etichetta dell’immagine del contenitore possono essere modificati durante un ripristino con le opzioni container_defaultnames o container_imageid (veda la sezione 4.2 a pagina 8).

Ripristino della directory locale

Per utilizzare questa modalità, il parametro where=/some/path di Bacula restorerestore è impostato su un percorso completo sul server in cui è installato il modulo Docker. Se il percorso non esiste, verrà creato dal Modulo Docker di Bacula.

Installazione del modulo di backup Docker

L’agente Bacula e il suo modulo di backup Docker devono essere installati sull’host per il servizio Docker. Docker potrebbe essere installato su diversi sistemi operativi e distribuzioni, quindi è necessario utilizzare il demone file di Bacula Enterprise per questo sistema operativo e piattaforma.

Configurazione del modulo Backup di Docker

Il modulo viene configurato utilizzando i parametri del modulo definiti in una sezione FileSets Include della configurazione di Bacula Enterprise Director.

Parametri del modulo Stima e Backup Docker

Questi parametri opzionali del modulo sono rilevanti solo per i lavori di Backup e Stima:

  • Specifica un contenitore Docker di cui eseguire il backup.
    Sono consentiti parametri multipli container=<. . >. Se non si riesce a trovare un contenitore con <nome-etichetta>, verrà generato un errore di lavoro singolo e il backup procederà al contenitore successivo, a meno che abort_on_error, che causerà l’interruzione dell’intero lavoro di backup. I nomi dei contenitori Docker (<name-label>) o gli id dei contenitori (<id>) possono essere utilizzati per selezionare i contenitori di cui eseguire il backup.
  • Specifica un’immagine Docker di cui eseguire il backup.
    Sono ammessi parametri multipli image=< . . . >. Se non è possibile trovare un’immagine con <repository:tag>, verrà generato un errore di lavoro singolo e il backup procederà all’immagine successiva, a meno che abort_on_error, che causerà l’interruzione dell’intero lavoro di backup. I nomi dei repository e dei tag delle immagini Docker (<repository:tag>) o gli id delle immagini (<id>) possono essere utilizzati per selezionare l’immagine richiesta per il backup. Questo parametro è opzionale.
  • Specifica l’elenco dei nomi dei contenitori Docker di cui eseguire il backup utilizzando la sintassi dell’espressione regolare.
    Tutti i contenitori con nomi corrispondenti all’espressione regolare fornita saranno selezionati per il backup. Multipli parametri include_container=<. . > possono essere forniti. Se nessun contenitore corrisponde all’espressione del nome fornita, il backup procederà al parametro successivo o terminerà con successo senza eseguire il backup di alcun contenitore. Il parametro abort_on_error non interromperà il lavoro quando non viene trovato alcun contenitore utilizzando la corrispondenza dei nomi.
  • Specifica un elenco di nomi di repository di immagini Docker di cui eseguire il backup utilizzando la sintassi dell’espressione regolare.
    Tutte le immagini con nome di repository corrispondente all’espressione regolare fornita saranno selezionate per il backup. Multipli parametri include_images=<. . > possono essere forniti. Se nessuna immagine corrisponde all’espressione del nome del repository fornito, il backup procederà al parametro successivo o terminerà con successo senza eseguire il backup di alcuna immagine. Il parametro abort_on_error non interromperà il lavoro quando non viene trovata alcuna immagine utilizzando la corrispondenza del nome del repository.
  • Specifica un elenco di nomi di contenitori Docker che saranno esclusi dal backup utilizzando un’espressione regolare.
    Tutti i contenitori con nomi che corrispondono all’espressione regolare fornita e che sono stati selezionati per il backup include_container=<. .> saranno esclusi. Questo parametro non influisce sui contenitori selezionati per il backup con il parametro container=<. .>. Multipli parametri exclude_container=<. .> possono essere forniti.
  • Specifica un elenco di nomi di repository di immagini Docker che saranno esclusi dal backup utilizzando un’espressione regolare.
    Tutte le immagini con nomi di repository che corrispondono all’espressione regolare fornita e che sono state selezionate per il backup utilizzando l’opzione include_image=<. .> saranno escluse. Questo parametro non influisce sulle immagini selezionate per il backup utilizzando image=<. .>. Multipli parametri exclude_image=<. .> possono essere forniti.

Parametri di ripristino del modulo di backup di Docker

Durante un ripristino, il modulo di backup di Docker utilizzerà gli stessi parametri opzionali impostati per il lavoro di backup e salvati nel catalogo. Alcuni di essi possono essere modificati durante il processo di ripristino, se necessario.

container_create: <yes|no> specifica se il ripristino del contenitore Docker deve creare automaticamente un contenitore. L’opzione predefinita è di creare i contenitori al momento del ripristino. Se i contenitori devono essere ripristinati come immagini, questo parametro deve essere impostato su no.

container_run: <yes|no> specifica se il ripristino dei contenitori Docker deve creare ed eseguire automaticamente i contenitori ripristinati. L’opzione predefinita è di non eseguire automaticamente i contenitori ripristinati. Se i contenitori devono essere eseguiti immediatamente dopo il ripristino, questo parametro deve essere impostato su yes.

Se questo parametro è impostato su yes, allora il parametro container_create verrà ignorato.

container_imageid: <yes|no> specifica se il Modulo Docker deve utilizzare i valori dell’id dell’immagine per creare o eseguire i contenitori ripristinati. L’impostazione predefinita è di utilizzare i valori del repository e del tag dell’immagine per questo scopo. Questo parametro sarà ignorato quando sia container_create e container_run sono impostati su no, in quanto non verrà eseguita alcuna operazione di creazione o esecuzione del contenitore.

container_defaultnames: <yes|no> specifica se il Modulo Docker deve impostare i nomi dei contenitori in base al nome del contenitore originale e ai valori JobId, che è l’impostazione predefinita. Se questo parametro è impostato su yes, il servizio Docker imposterà dei nomi predefiniti per i contenitori creati o eseguiti.

Esempi di Docker Backup FileSet

Nell’esempio seguente, verrà eseguito il backup di tutti i contenitori e le immagini Docker.


FileSet {
Name = FS_DockerAll
Include {
Plugin = “docker:”
}
}

In questo esempio, verrà eseguito il backup di un singolo contenitore Docker con nome-etichetta “mcache1”.


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

Lo stesso esempio di cui sopra, ma utilizzando invece l’id del contenitore:


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

Nell’esempio seguente, verrà eseguito il backup di tutti i contenitori Docker che contengono “ngnix” nel loro nome.


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

In questo esempio finale, verrà eseguito il backup di tutti i contenitori Docker tranne quelli il cui nome inizia con “test”.


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

Scenari di ripristino del docker

Ripristino di un servizio Docker

Per ripristinare un contenitore o un’immagine in un servizio Docker, l’amministratore deve eseguire il comando restore e specificare il parametro where come in questo esempio:


* restore where=/

e quindi impostare qualsiasi altro parametro del modulo di ripristino richiesto per il ripristino. Nel seguente esempio di sessione di ripristino, l’opzione di ripristino del plugin container_run l’opzione di ripristino del plugin è impostata su “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

Il registro del lavoro di ripristino indicherà quale contenitore è stato ripristinato e quale nuovo id di contenitore è stato creato:


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

Il nuovo contenitore creato durante il ripristino otterrà un nuovo id contenitore. Questo può essere verificato eseguendo un comando come:


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

Ripristino della directory locale

È possibile ripristinare le immagini dei contenitori e i dati delle immagini dei modelli Docker in un file senza caricarli sul servizio Docker. Per farlo, l’opzione where l’opzione di ripristino deve puntare alla directory locale:


* restore where=/tmp/bacula/restores

Verifichi il seguente esempio per il messaggio “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(…)

Il registro del lavoro di ripristino mostrerà che il ripristino è stato eseguito in una directory locale. Il registro di cui sopra è stato troncato per una visione chiara.

Ulteriore aiuto sul backup dei container Docker: