Come spostare i dati dei container su un pool SSD senza modificare i percorsi di montaggio

Sposta la sorgente dei dati sul lato host sull’SSD, mantenendo invariato il percorso di destinazione all’interno di ogni container.

Una migrazione sicura tratta la mappa dei mount attuale come un contratto d’interfaccia. I container, i database e le app multimediali si aspettano percorsi come /config, /data o /media, indipendentemente dal disco che li fornisce. Il flusso di lavoro deve interrompere le scritture, montare l’SSD in modo prevedibile, copiare proprietà e metadati, aggiornare solo la sorgente sull’host, verificare il nuovo mount prima dell’avvio e conservare i dati originali finché non supera un test completo di ripristino.

Inventaria tutte le sorgenti attuali e le destinazioni dei container

Esporta il file Compose o i dati dell’ispezione dei container ed elenca ogni bind mount, volume denominato, mount tmpfs, directory del database, cache, percorso di transcodifica e posizione dei contenuti multimediali. Registra separatamente la sorgente sull’host e la destinazione nel container.

Una guida pratica alla migrazione dei volumi inizia individuando i dati attuali e arrestando i container prima di copiarli in una nuova posizione sul disco. Questo inventario impedisce che i dati di configurazione rimangano sul disco di sistema.

Indica quali percorsi contengono lo stato autorevole, la cache ricostruibile e i file multimediali di grandi dimensioni. Non presumere che una cartella chiamata data contenga tutto lo stato persistente dell’applicazione.

Monta il pool SSD in modo prevedibile prima dell’avvio di Docker

Crea il filesystem o il pool SSD, identificalo tramite un UUID stabile o il nome del pool e montalo nel percorso finale sull’host. Dopo un riavvio, verifica lo spazio libero, le funzionalità previste del filesystem e l’accesso in scrittura.

Spostare i dati Docker su uno storage esterno può causare errori quando il disco è assente o viene montato in un percorso diverso durante l’avvio. Un recente caso relativo a un SSD esterno evidenzia come il trasferimento dello storage Docker modifichi la dipendenza dal percorso di mount di destinazione.

Configura l’ordine di avvio dei servizi o il comportamento di automount, in modo che Docker non crei mai una directory di fallback vuota sul disco di sistema. Interrompi la procedura se l’SSD non è montato esattamente nel percorso previsto.

Arresta i processi di scrittura e copia i dati preservando i metadati

Arresta l’applicazione e ogni dipendenza che può scrivere nei suoi dati, inclusi database, indicizzatori, downloader e processi in background. Per i database, esegui un dump coerente con l’applicazione oppure un arresto pulito prima di copiare i file grezzi.

Una discussione sui container Synology consiglia di spostare un volume gestito da Docker in un bind mount solo dopo aver individuato i dati del volume e averne preservato il contenuto nella nuova sorgente del bind mount.

Copia ricorsivamente preservando proprietà, autorizzazioni, timestamp, collegamenti, ACL e attributi estesi, ove supportati. Esegui un confronto a secco o un controllo a campione tramite checksum dopo la copia e prima di modificare Compose.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Modifica solo il percorso della sorgente sull’host

Mantieni identica la destinazione nel container. Ad esempio, modifica /oldpool/app:/config in /ssdpool/app:/config invece di insegnare all’applicazione un nuovo percorso interno.

I bind mount espongono una posizione esatta dell’host in un percorso stabile all’interno del container. Una panoramica dello storage spiega che questa mappatura diretta è utile quando gli amministratori hanno bisogno del controllo del percorso sul lato host.

Preservare la destinazione evita di compromettere i database dell’applicazione, i riferimenti alle librerie, gli script, le autorizzazioni e i valori di configurazione che memorizzano il percorso all’interno del container.

Ripristina proprietà, etichette e coerenza del database

Confronta i valori numerici di UID e GID previsti dall’immagine con le proprietà sull’SSD. Ripristina inoltre ACL, etichette SELinux, autorizzazioni AppArmor e opzioni di mount necessarie per il locking o per i file mappati in memoria.

Una guida alla migrazione dello storage Docker su macOS osserva che lo spostamento dei dati Docker richiede la copia dell’immagine completa dello storage e la successiva verifica che il runtime utilizzi la nuova posizione di archiviazione. Sui sistemi NAS Linux, il controllo equivalente consiste nel verificare che ogni sorgente configurata punti al mount SSD.

Avvia solo il database e controlla i log di ripristino prima di avviare le app dipendenti. Se segnala corruzione o file mancanti, interrompi la procedura e torna alla copia originale invece di consentire alle applicazioni di inizializzare un database vuoto.

Esegui il passaggio con una procedura di rollback e un test completo del flusso di lavoro

Avvia lo stack nell’ordine delle dipendenze e verifica configurazione, record del database, autorizzazioni, librerie multimediali, caricamenti, download, aggiornamenti e ricreazione dei container. Controlla che le nuove scritture vengano eseguite sull’SSD e che il disco di sistema non continui a riempirsi.

L’articolo di ZimaSpace su un bind mount Docker che diventa improvvisamente di sola lettura illustra la diagnosi successiva nel caso in cui il percorso migrato venga montato ma rifiuti le scritture.

Mantieni i vecchi dati offline e invariati finché non sono stati completati i backup e una seconda ricreazione del container dall’SSD. Rimuovi la vecchia sorgente solo dopo che una prova di rollback ha dimostrato la possibilità di ripristinare il file Compose, i mount, i database e lo stato dell’applicazione.