Cosa dovrebbe includere un backup Docker oltre alla libreria multimediale?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

What Should a Docker Backup Include Besides the Media Library?

Un backup Docker deve preservare la definizione del deployment, lo stato dell’applicazione, i database, le credenziali e la procedura di ripristino, non solo i file multimediali sostituibili.

Film, musica e foto possono costituire il dataset più grande, ma perdere i file Compose, i database delle app, i metadati, gli account utente, i certificati, le chiavi di crittografia o le mappature dei mount può rendere inutilizzabile la libreria o costringere a settimane di ricostruzione. Un backup affidabile parte dalla domanda «Cosa deve esistere per ricreare il servizio su un host vuoto?» e protegge ogni livello necessario con un metodo coerente con l’applicazione.

Esegui il backup della definizione del deployment

Conserva ogni file Compose, file di override, Dockerfile, contesto di build, nome dello stack, tag dell’immagine, comando, mappatura delle porte, rete, dichiarazione dei volumi, controllo dello stato, criterio di riavvio e limite delle risorse necessari per ricreare i container.

Una discussione sul self-hosting descrive come conservare insieme i file Compose e quelli dell’ambiente di ciascuna applicazione, così da poter ridistribuire lo stack in modo prevedibile. In questo modo la configurazione del deployment diventa una risorsa di backup di primo livello, invece di affidarsi a un container in esecuzione come documentazione.

Registra le versioni esatte delle immagini invece di usare solo tag mobili come latest. Quando appropriato, archivia la configurazione in un sistema di controllo versione, ma mantieni i segreti fuori dai repository pubblici e includi un inventario protetto delle dipendenze esterne necessarie.

Proteggi ogni bind mount persistente e ogni volume denominato

Elenca i mount collegati a ciascun servizio e classificali come cache sostituibile, configurazione dell’applicazione, metadati, database, contenuti caricati, miniature generate o stato critico. Esegui il backup di tutti i percorsi non sostituibili.

Una discussione su OpenMediaVault afferma che l’insieme importante per il ripristino è costituito dalla definizione Compose e dai dati persistenti, mentre le immagini dei container possono solitamente essere scaricate di nuovo. Questo distingue lo stato durevole dalle immagini dei container sostituibili.

Includi le directory nascoste delle applicazioni e i piccoli volumi di metadati, non solo il grande mount della libreria. Verifica che i percorsi sorgente dei bind mount siano inclusi nel backup dell’host e che i volumi denominati vengano esportati con un metodo che preservi proprietari e permessi.

Crea backup coerenti con i database

Identifica PostgreSQL, MariaDB, MySQL, MongoDB, SQLite, la persistenza di Redis e i database integrati. Usa il processo di dump, snapshot o backup a database quiescente supportato dal database, invece di copiare i file mentre le transazioni li stanno modificando.

Una discussione su Stack Overflow relativa al backup dei volumi Docker mostra come montare un volume in un container temporaneo per creare un archivio, ma i file dei database richiedono comunque attenzione alla coerenza. Un archivio grezzo del volume non è automaticamente un backup transazionale valido del database.

Registra la versione del motore, i nomi dei database, gli utenti, le estensioni e l’ordine di ripristino. Testa un dump logico separatamente dal backup del filesystem, così un metodo potrà consentire il ripristino quando l’altro è incompleto.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

Conserva segreti, certificati e identità

Esegui copie protette dei segreti dell’ambiente, dei token API, delle password dei database, delle credenziali dei client OAuth, dei certificati TLS, delle chiavi private, delle chiavi SSH, delle chiavi di crittografia e dei codici di recupero delle applicazioni.

I segreti devono essere conservati separatamente dai normali file Compose e crittografati con un metodo di recupero che non dipenda dall’host Docker guasto. Il backup deve includere un contesto sufficiente per sapere a quale servizio e variabile associare ciascun segreto durante il ripristino.

Non omettere le chiavi di crittografia dei database o dello storage crittografati. Una copia perfetta dei dati crittografati è irrecuperabile se vengono persi la chiave, la passphrase o la configurazione della gestione delle chiavi.

Includi reverse proxy, DNS, job e presupposti dell’host

Conserva le route del reverse proxy, i middleware, i controlli di accesso, i record DNS, la configurazione DDNS, i job pianificati, i criteri di aggiornamento, le regole del firewall, le mappature dei dispositivi GPU, le assegnazioni UID e GID e le unità di mount dello storage.

Una panoramica di un prodotto per il backup sottolinea che una protezione affidabile dei volumi richiede anche pianificazione, conservazione, crittografia, controllo della destinazione e cronologia visibile delle esecuzioni. Questi dettagli operativi trasformano un archivio occasionale in un flusso di lavoro di backup ripetibile.

Documenta quali directory dell’host, reti, funzionalità del kernel e dispositivi devono esistere prima dell’avvio di Compose. Senza questi presupposti, i container ripristinati potrebbero creare directory di fallback vuote, usare permessi errati o avviarsi senza accelerazione hardware.

Dimostra l’efficacia del backup con un ripristino su un host vuoto

Ripristina il backup su un host di test isolato o su una macchina virtuale, usando esclusivamente il backup e le istruzioni scritte. Ricrea i percorsi di storage, i segreti, i database, le route del proxy e i container nell’ordine documentato.

La guida ZimaSpace al ripristino sicuro di una singola cartella condivisa applica lo stesso principio: un backup è affidabile solo dopo che un ripristino controllato ne ha dimostrato la portata.

Convalida l’accesso, i permessi, l’integrità del database, i metadati, le miniature, la riproduzione, i caricamenti, i job pianificati, TLS e un secondo riavvio. Registra il tempo di ripristino e aggiorna la checklist del backup ogni volta che il ripristino rivela una dipendenza mancante.