Quale metodo di backup mantiene coerente un contenitore di database in esecuzione su un NAS domestico?

Per la maggior parte degli utenti di NAS domestici e server self-hosted, il default più sicuro è un backup logico nativo del database creato mentre il database è in esecuzione, seguito da un backup normale di quel dump insieme alla configurazione del contenitore e ai file dell'applicazione. Usa una copia a contenitore fermo breve quando il downtime è accettabile, e usa uno snapshot coordinato del filesystem solo quando il database è svuotato, bloccato, checkpointed o altrimenti preparato per lo snapshot. Una semplice copia di un volume di database attivo non è un metodo di backup coerente.

Definisci “Coerente” come un Ripristino Accettato dal Database

Un backup coerente non è solo un albero di cartelle completo. Dopo il ripristino, il motore del database deve avviarsi, recuperare correttamente le transazioni, superare i controlli di integrità e presentare uno stato puntuale che l'applicazione può usare. Su un server domestico che esegue Immich, Nextcloud, Paperless-ngx, Home Assistant o un'altra app self-hosted, ciò significa che database, upload, configurazione e segreti devono essere coerenti tra loro.

La persistenza del contenitore spiega solo dove risiedono i file. Non rende sicura la copia di un database in esecuzione. Un database può avere transazioni attive, pagine in cache, log di scrittura anticipata, file temporanei o metadati che cambiano mentre il software di backup NAS legge il volume.

Metodo 1: Usa un Dump Logico Nativo del Database come Predefinito per il NAS di Casa

Un dump logico chiede al motore del database di esportare una rappresentazione coerente di schemi e record. Per un contenitore PostgreSQL o MariaDB modesto su un NAS familiare, questo è solitamente il metodo più semplice da programmare, ispezionare, copiare offsite e ripristinare in un contenitore sostitutivo pulito. Una guida attuale al backup Docker dimostra questo schema eseguendo dump nativi del database da un contenitore di backup programmato.

Scrivi il dump in una directory di backup dedicata al di fuori del volume dati attivo. Poi lascia che il lavoro di backup NAS protegga il dump, il file Compose, il modello di ambiente, la configurazione dell'applicazione e i dati caricati. Non esporre password di produzione nel nome del file dump o in log non protetti.

Metodo 2: Interrompere brevemente il database prima di copiare il suo volume

Una copia del container fermo è semplice e fisicamente completa. Ferma prima gli scrittori dell'applicazione, arresta il database in modo pulito, conferma che il processo è terminato, copia l'intero volume persistente o la directory del database montata tramite bind, quindi riavvia lo stack. Una guida Docker e MariaDB descrive le copie di volumi fisici come veloci ma dipendenti dalla versione e normalmente legate ai tempi di inattività.

Questo metodo funziona bene per un piccolo NAS domestico dove sono accettabili pochi minuti di manutenzione e il ripristino utilizzerà una versione compatibile del database. È meno portabile di un dump logico e può estendere i tempi di inattività quando il volume è grande. Conserva il tag dell'immagine del database e la struttura di archiviazione con il backup per non ripristinare file fisici in una versione del motore incompatibile.

Metodo 3: Coordinare uno Snapshot Veloce con il Database

I sistemi di snapshot ZFS, Btrfs, LVM e NAS possono catturare rapidamente un grande volume di database, ma lo snapshot deve essere coordinato con il database. Per MariaDB o MySQL, ciò può significare una breve finestra di blocco o flush; per PostgreSQL, può significare il processo di backup o checkpoint supportato dal database; per un database gestito dall'applicazione, può significare un hook pre-snapshot.

Una discussione sugli snapshot del database spiega che una copia live su disco può essere internamente incoerente a meno che il database non sia congelato o lo snapshot non venga eseguito in modo atomico. L'intervallo di blocco o quiescenza dovrebbe essere breve: preparare il database, creare lo snapshot, rilasciare le scritture e copiare lo snapshot in seguito.

Questo metodo è utile quando il database è troppo grande per dump logici frequenti o quando è necessario un intervallo di punto di recupero più basso. Richiede uno scripting più attento e test di ripristino rispetto a un semplice flusso di lavoro di dump per server domestico.

Non considerare l'immagine Docker o l'esportazione del container come backup del database

L'immagine del container contiene il runtime dell'applicazione, non necessariamente i dati persistenti attivi. L'esportazione o il commit del container possono omettere i volumi nominati e non richiedono al database di creare un punto di recupero coerente. Un account di backup di un container PostgreSQL conclude che Docker save e commit non sostituiscono le tecniche di backup specifiche per PostgreSQL.

Per un server domestico ZimaOS o Docker, mantieni separate la definizione di deployment e il piano di protezione dei dati: conserva i file Compose e i tag delle immagini per poter ricostruire il servizio, e conserva il database tramite un metodo coerente con il database per poter ripristinare il suo stato.

Non copiare mai semplicemente un volume di database attivamente scritto

Il software di backup NAS può leggere file di database diversi in momenti diversi. L'archivio risultante può contenere un file dati da uno stato di transazione, un log da un altro e metadati da un terzo. Una panoramica dei metodi di backup SQL open-source avverte che un database in movimento può essere catturato in un momento incoerente mentre uno stato importante è ancora in memoria.

Il recupero da crash può riparare alcuni snapshot acquisiti in modo atomico, ma una copia ricorsiva ordinaria non è atomica. Se l'app non può tollerare downtime, usa un dump logico, uno strumento di backup fisico supportato o uno snapshot coordinato.

Gestisci i contenitori SQLite come database, non come file ordinari

Molte app per server domestici usano SQLite perché è compatto e facile da distribuire. Il rischio è che gli amministratori vedano un file .db e presumano che possa essere copiato mentre l'app scrive. In modalità WAL, le modifiche recenti confermate possono essere ancora fuori dal file principale. Un articolo pratico sul recupero SQLite raccomanda di usare il meccanismo di backup online o una copia chiusa pulita invece di copiare un file di database attivo.

Usa il backup integrato dell'applicazione se disponibile. Altrimenti usa la funzione di backup online di SQLite o arresta l'applicazione in modo pulito prima di copiare l'intera directory del database. Non copiare solo il file principale del database lasciando indietro il suo journal o stato WAL.

Scegli il metodo in base a downtime, dimensione del database e portabilità del ripristino

Esegui il Backup dell'Intera Applicazione Self-Hosted, Non Solo del Database

Un pacchetto di recupero utilizzabile dovrebbe includere il backup del database, il file Docker Compose, le versioni delle immagini, le variabili d'ambiente o un pacchetto di segreti recuperabile, le impostazioni del reverse-proxy, la configurazione dell'applicazione, i file caricati e eventuali chiavi di crittografia. Eseguire il backup solo del dump SQL può ripristinare i record ma lasciare l'app incapace di trovare foto, documenti, miniature, certificati o percorsi di storage.

Per la pianificazione del recupero del server domestico, la guida ZimaSpace su bind mounts e volumi nominati spiega perché i percorsi di storage visibili aiutano il recupero ma non sostituiscono un backup del database coerente con l'applicazione.

Verifica il Metodo Ripristinando in un Nuovo Container

Crea uno stack di test isolato con un nuovo nome progetto, porte host diverse e una directory dati temporanea. Ripristina il dump o lo snapshot, avvia il database, esegui i controlli di integrità o coerenza, quindi connetti una copia di test dell'applicazione. Conferma che utenti, record, allegati e transazioni recenti siano presenti.

Misura sia il recovery point che il recovery time. Se un dump logico è consistente ma richiede troppo tempo per il ripristino, mantienilo come livello di recupero portatile e aggiungi uno snapshot coordinato più veloce. Se una copia del volume fermo si ripristina rapidamente ma solo alla stessa versione del database, conserva un dump logico come fallback per la migrazione.

FAQ

Mettere in pausa un container database è sufficiente prima di copiare il volume?

Non come regola generale. Mettere in pausa congela il processo ma non dimostra che il database abbia scaricato lo stato corretto per un backup portatile. Usa un dump nativo del database, uno spegnimento pulito o una procedura documentata di quiescenza e snapshot.

Uno snapshot NAS da solo è sufficiente per PostgreSQL o MariaDB?

Solo quando lo snapshot è atomico e coordinato con il processo di coerenza supportato dal database. Uno snapshot non coordinato può essere solo crash-consistente, e una copia di file non atomica può essere peggiore.

Cosa dovrei eseguire il backup per un'app home-server basata su SQLite?

Usa l'esportazione dell'app o il backup online di SQLite quando disponibile. Conserva anche la configurazione dell'app, il file Compose, i segreti, gli allegati e la directory che contiene il database invece di presumere il file principale .db il file è l'intera applicazione.

Raccomandazione Finale

Usa dump logici programmati come impostazione predefinita per la maggior parte dei container PostgreSQL e MariaDB su un NAS domestico. Usa una copia pulita del volume fermo quando è accettabile un breve downtime, e usa snapshot coordinati o strumenti fisici nativi del database quando il database è grande o la finestra di recovery-point è stretta. Qualunque metodo tu scelga, ripristinalo in un nuovo container prima di fidarti.