Perché un backup NAS domestico esclude i file nascosti e i metadati delle app?
Il backup di solito esclude un percorso, non perde casualmente dati nascosti.
Su un NAS domestico, i file nascosti e i metadati delle app vengono comunemente persi perché il task ha selezionato solo la condivisione visibile, una regola di esclusione ha corrisposto al percorso, l’identità del backup non aveva accesso o i dati risiedevano in un volume container, database, symlink o filesystem montato al di fuori dell’albero scelto. La riparazione inizia localizzando l’unità di recupero mancante e testando la causa più probabile e piccola.
Mappa il Risultato Mancante al Primo Test
Inizia dal risultato del ripristino piuttosto che dallo stato di completamento verde. Diversi schemi di mancanza indicano diversi livelli del job di backup.
Se mancano tutti i file dot, ispeziona i filtri per file nascosti e pattern; se un’app restituisce file ma senza impostazioni, mappa il suo database, segreti e volumi; se manca una cartella protetta, verifica l’accesso con l’identità del backup programmato. Queste osservazioni restringono la causa prima di qualsiasi modifica alle regole di produzione.
Registra il percorso mancante, il conteggio previsto degli elementi, la posizione effettiva del ripristino e il primo test fallito. Queste evidenze diventano la base di confronto per l’esecuzione corretta.
La tabella trasforma il sintomo visibile in una prima azione a basso rischio.
| Risultato Mancante | Livello Probabile | Primo Test |
|---|---|---|
| Tutti i file dot mancanti | Filtro o regola attributo nascosto | Ispeziona l’ordine di inclusione/esclusione |
| I file dell’app esistono ma le impostazioni sono assenti | Database o volume fuori dalla condivisione | Mappa mount e percorsi di stato |
| Assenti solo le cartelle protette | Accesso account di servizio | Elenca come identità del backup |
| Sottostruttura montata vuota | Attraversamento mount o symlink | Confronta destinazione reale e ID dispositivo |
Usa una riga alla volta. Cambiare filtri, permessi e mount insieme può rendere impossibile attribuire il prossimo successo.
Controlla Ambito Sorgente e Regole di Ignoramento come Unica Decisione
Un task non può proteggere dati al di fuori delle radici selezionate, anche quando l’interfaccia NAS visualizza più dataset nidificati sotto una condivisione. Ambito sorgente e pattern di ignoramento devono quindi essere rivisti insieme.
Gli utenti di Duplicity possono escludere percorsi che iniziano con punto usando un pattern di esclusione per percorsi nascosti. Regole simili possono esistere in un template NAS, linea di comando, variabile d’ambiente, file marker o configurazione per cartella.
Esporta le impostazioni del task e confronta ogni radice selezionata con il percorso reale dell’elemento mancante. Testa il pattern sospetto su un piccolo albero di staging e restringi solo la regola che esclude contenuti critici per il recupero.
Trova lo Stato dell’App Fuori dalla Cartella Condivisa Visibile
Le app self-hosted spesso separano i file utente dallo stato dell’applicazione. Una cartella foto può contenere gli originali mentre database, miniature, dati facciali, segreti e configurazioni risiedono altrove.
Le distribuzioni container usano volumi Docker persistenti e bind mount per conservare lo stato indipendentemente dall’immagine. Fare il backup solo della condivisione media può quindi preservare i file visibili ma omettere lo stato necessario per ricostruire l’app.
Fai l’inventario completo dell’unità di recupero: file Compose, variabili d’ambiente, segreti, volumi nominati, bind mount, dump del database, configurazione applicativa e percorsi dati utente. Aggiungi le sorgenti reali o un export consapevole dell’app invece di presumere che una condivisione contenga tutto.
Testa Permessi e Attraversamento come Identità del Backup
Un amministratore può navigare un percorso che l’account backup programmato non può leggere. Una sottostruttura montata o un symlink possono apparire locali mentre lo strumento di backup rifiuta di attraversarli o seguirli.
Un caso di supporto backup ha tracciato dati NAS saltati a accesso account backup. Esegui un elenco non distruttivo come esatto account di servizio e registra ogni directory negata prima di modificare ACL.
Quindi confronta mount point, ID dispositivo, destinazioni symlink, stato cartelle criptate e mappature UID container. Se la destinazione risiede altrove, aggiungi il percorso reale come sorgente e documenta se lo strumento memorizza il link, lo segue o si ferma al confine del filesystem; la gestione reale dei symlink mostra perché questo comportamento non può essere dato per scontato.
Separa i Metadati Critici per il Recupero dai Dati Nascosti Usa e Getta
Abilitare ogni directory nascosta può aumentare il tempo di scansione e la dimensione del repository senza migliorare il recupero. La decisione corretta è se l’elemento è necessario per riprodurre i dati utente o lo stato dell’applicazione.
Chiavi, configurazioni, database, manifesti, segreti, valutazioni, album e sidecar insostituibili sono solitamente critici per il recupero. Cache miniature, socket runtime, upload temporanei, file di lock e indici facilmente rigenerabili possono essere usa e getta o a priorità inferiore.
Documenta la classificazione nel piano di backup. Un’esclusione deliberata dovrebbe indicare il metodo di ricostruzione e il ritardo di recupero accettabile; tutto ciò che non ha un percorso di ricostruzione documentato dovrebbe rimanere protetto finché un ripristino isolato non dimostri il contrario.
Dimostra che il Backup Corretto Contiene l’Intera Unità di Recupero
Esegui un nuovo backup dopo aver modificato solo la causa confermata, quindi confronta inventari sorgente e backup. Un secondo stato verde è ancora insufficiente quando il conteggio degli elementi o lo stato applicativo ripristinato rimane inferiore al previsto.
Usa la guida esistente per segnali di avviso di backup silenziosamente incompleto quando durata, conteggio byte, esclusioni, oggetti saltati o comportamento di ripristino si discostano dalla baseline.
Ripristina i file nascosti o lo stato applicativo in una cartella isolata o container di test e aprilo tramite il percorso utente previsto. Interrompi e riprogetta il metodo se l’unica copia disponibile è una copia live non sicura di un database in esecuzione.
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...
