Puoi ripristinare un solo container senza sostituire l’intero stack dell’applicazione?
Sì, è possibile ripristinare un singolo container in modo indipendente quando la sua configurazione, i dati persistenti e i confini delle dipendenze sono chiaramente separati dal resto dello stack.
Su un NAS domestico, il container visibile è solitamente ricreabile, ma lo stato dell’app può essere distribuito tra bind mount, volumi denominati, un database separato, segreti, route proxy e reti condivise. Un ripristino sicuro di un singolo servizio, quindi, non consiste nel ricopiare un ID container, ma nel bloccare il servizio interessato, ripristinare solo lo stato di sua proprietà, ricrearlo a partire da una definizione nota e verificare che le dipendenze condivise e i container vicini integri non siano stati modificati.
Definisci l’unità di ripristino prima di arrestare qualsiasi cosa
Identifica il servizio esatto che ha subito il guasto ed elenca ogni oggetto di sua proprietà: nome del servizio Compose, tag o digest dell’immagine, file di ambiente, segreti, bind mount, volumi denominati, porte pubblicate, alias di rete, processi pianificati ed etichette del reverse proxy.
Le guide al ripristino dei volumi Docker separano il runtime del container dall’archiviazione persistente, perché il volume dei dati può essere sottoposto a backup e ripristinato indipendentemente. Una guida pratica illustra un ripristino separato del container e del volume, invece di considerare il container in esecuzione come l’unico oggetto da recuperare.
Se l’app scrive in un database o volume condiviso, l’unità di ripristino include anche quella dipendenza condivisa e potrebbe non essere più isolabile in sicurezza. Non sovrascrivere nulla finché la proprietà dei dati non è inequivocabile.
Acquisisci lo stato dello stack integro e del servizio guasto
Esporta o salva il file Compose corrente, l’ambiente risolto, i digest delle immagini, l’elenco dei mount, l’appartenenza alle reti, lo stato di salute e i log recenti. Registra quali servizi vicini sono integri, così il ripristino avrà un confine di non interferenza ben definito.
Un’operazione Compose a livello di servizio può indirizzare un singolo servizio nominato invece di riavviare tutto. Il flusso di lavoro per un singolo servizio di Linux Handbook distingue un servizio Compose dalle azioni sull’intero stack, ma specifica anche che le modifiche alla configurazione richiedono una ricreazione, non un semplice riavvio.
Disabilita gli aggiornamenti automatici e i cicli di riavvio solo per il servizio guasto. Mantieni in esecuzione i database e l’infrastruttura condivisa, a meno che la loro coerenza non richieda un arresto coordinato.
Ripristina prima i dati in una posizione isolata
Ripristina il backup selezionato in una directory temporanea o in un nuovo volume, anziché direttamente sul percorso attivo. Confronta il numero di file, la proprietà, i timestamp, i metadati del dump del database e la versione dell’applicazione con lo stato danneggiato.
Un progetto per il backup dei volumi documenta l’uso di un container temporaneo eseguito una sola volta per montare e ripopolare un volume di destinazione, creando un percorso di ripristino isolato del volume prima che il servizio di produzione vi scriva.
Per i database, quando disponibile, usa un metodo di dump o ripristino consapevole dell’applicazione. Una copia del filesystem di un database in esecuzione può garantire al massimo la coerenza dopo un arresto anomalo e può non funzionare dopo la rimozione del vecchio container.
Verifica la copia isolata prima di cambiare i mount. Se il backup non è leggibile o il suo schema non corrisponde all’immagine prevista, conserva lo stato corrente e scegli un altro punto di ripristino.
Ricrea solo il servizio guasto mantenendo la sua identità originale
Ricrea il servizio nominato a partire dalla definizione Compose salvata, mantenendo lo stesso nome del progetto, le reti esterne, gli alias del servizio, le porte, i segreti, la mappatura UID/GID e i percorsi persistenti verificati.
L’accesso ai mount può comunque non funzionare dopo un corretto ripristino dei dati quando la proprietà o le etichette di sicurezza non corrispondono più all’utente di runtime. Un caso relativo a un container Rocky Linux ha risolto l’accesso mancante al volume verificando proprietà e contesto di sicurezza, invece di copiare nuovamente i dati.
Avvia il servizio senza eliminare i volumi né eseguire comandi prune sull’intero stack. Controlla i mount effettivi prima di consentire a migrazioni, scansioni o processi in background di modificare i dati ripristinati.
Ricollega le dipendenze senza ripristinarle
Verifica la risoluzione DNS e l’accesso TCP dal container ripristinato al database, alla cache, al provider di identità, all’archivio di oggetti e alla rete del proxy. Usa gli stessi nomi dei servizi e le credenziali definite nella configurazione recuperata.
Se una dipendenza condivisa è rimasta integra, non ripristinarla né sostituirla solo perché l’applicazione non riesce a connettersi. Un alias di rete mancante, un segreto modificato, una mancata corrispondenza dello schema o un nome di database errato possono far sembrare non disponibile una dipendenza funzionante.
Esegui le migrazioni solo quando la versione dell’app ripristinata e il backup del database lo richiedono. Esegui il backup della dipendenza prima di qualsiasi migrazione irreversibile e interrompi l’operazione se l’app tenta di inizializzare un database vuoto.
Convalida il confine del singolo servizio prima di ripristinare il traffico
Verifica l’accesso, le letture, le scritture, i caricamenti, i processi pianificati, le chiamate API, l’accesso tramite proxy e un riavvio controllato. Confronta il numero di riavvii, i log, le porte e i checksum dei dati dei container vicini con quelli acquisiti prima del ripristino.
La guida di ZimaSpace su come mappare lo stato persistente del container illustra lo stesso principio di recupero: ripristina il proprietario dello stato, non un guscio di container presunto.
Il ripristino è completo solo quando il servizio recuperato utilizza i dati e le dipendenze previsti, i membri integri dello stack sono rimasti intatti e un’ulteriore ricreazione produce lo stesso risultato. Se lo stato condiviso non può essere isolato, passa a un ripristino coordinato dell’intero stack invece di forzare un rollback parziale.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
