Perché il ripristino di un volume Docker ricrea il contenuto dei file, ma elimina gli attributi estesi?

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.

Why Does a Docker Volume Restore Recreate File Contents but Drop Extended Attributes? - Zima Store Online

Il ripristino di un volume Docker può ricreare ogni byte dei file, ma perdere gli attributi estesi quando il formato del backup, le opzioni, i privilegi o la destinazione non consentono di conservarli.

Gli attributi estesi sono coppie di metadati nome-valore archiviate al di fuori del contenuto ordinario dei file, della proprietà, dei bit dei permessi e dei timestamp. Possono contenere dati ACL, etichette SELinux, funzionalità Linux, indicatori dell’applicazione o metadati Samba. Un semplice backup di un volume basato su tar può ripristinare una directory apparentemente completa, mentre le applicazioni si comportano in modo diverso perché l’archivio non ha registrato gli xattr oppure il processo di ripristino non ha potuto scrivere in uno spazio dei nomi protetto.

Inventaria gli attributi della sorgente prima di ripetere il ripristino

Seleziona file rappresentativi e registra i relativi hash, proprietario, permessi, ACL e ogni nome e valore degli attributi estesi. Includi i file che, dopo il ripristino, causano errori nell’applicazione.

Il modello xattr di Linux separa gli spazi dei nomi user, system, security e trusted, ciascuno con requisiti diversi in termini di accesso e privilegi.

Se la sorgente non contiene xattr, il ripristino non li ha persi. Se scompare un solo spazio dei nomi, concentrati sui privilegi, sui criteri di sicurezza o sul supporto della destinazione, anziché sul livello dei contenuti dei file dell’archivio.

Controlla cosa ha effettivamente archiviato il comando di backup Docker

Salva l’immagine esatta, il comando, la directory di lavoro, il formato dell’archivio, l’utente, la sorgente montata e la destinazione del backup montata utilizzati dal container di backup.

L’esempio di backup dei volumi Docker utilizza tar all’interno di un container di supporto, ma la conservazione dei metadati dipende comunque dall’implementazione di tar e dalle opzioni selezionate.

Un file di archivio creato correttamente dimostra che le voci delle directory e i dati sono stati letti, non che siano stati inclusi tutti gli spazi dei nomi xattr. Ispeziona l’archivio con lo stesso strumento usato per crearlo.

Abilita gli attributi estesi durante la creazione e l’estrazione dell’archivio

Confronta le opzioni tar utilizzate per il backup e il ripristino. Verifica che gli xattr siano stati abilitati in entrambe le direzioni e che i criteri di inclusione o esclusione non abbiano rimosso gli spazi dei nomi necessari.

GNU tar specifica che --xattrs memorizza e ripristina gli attributi estesi.

Aggiungere l’opzione solo durante l’estrazione non può recuperare attributi che non sono mai stati memorizzati. Crea un nuovo archivio di piccole dimensioni da un file sorgente con un xattr di test noto e ispezionalo prima di modificare i backup di produzione.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Usa le opzioni corrette di Rsync per i metadati nei backup basati su file

Se il backup del volume utilizza Rsync, controlla le opzioni relative ad archivio, ACL, xattr, ID numerici, fake-super e privilegi sia sul mittente sia sul destinatario.

Il manuale ufficiale di Rsync documenta -X per la conservazione degli attributi estesi e descrive la memorizzazione fake-super quando i metadati privilegiati non possono essere applicati direttamente.

La comune opzione di archivio -a non include automaticamente tutti i requisiti relativi ad ACL e xattr. Testa il comando esatto sui filesystem reali della sorgente e della destinazione.

Verifica il supporto del filesystem e del montaggio nella destinazione

Crea un file temporaneo direttamente sul volume ripristinato e prova a impostare, elencare e rimuovere un xattr user. Ripeti l’operazione tramite l’host e tramite il container di backup.

Usa un’utilità per elencare gli attributi sia nell’host sia nel container di ripristino, così da dimostrare che la destinazione accetta e restituisce gli xattr indipendentemente dall’archivio di backup.

Se la creazione diretta di un xattr non riesce, controlla il tipo di filesystem, le opzioni di montaggio, il protocollo di rete, il driver del volume e il supporto dell’appliance di archiviazione. Nessuna opzione dell’archivio può ripristinare metadati che la destinazione non è in grado di rappresentare.

Controlla i privilegi per gli spazi dei nomi security e trusted

Registra l’utente del container di ripristino, le capability, lo spazio dei nomi utente, la modalità rootless, i criteri SELinux e verifica se il percorso del volume è montato tramite bind dall’host.

Red Hat documenta che le etichette SELinux potrebbero dover essere ripristinate in modo conforme ai criteri dopo la copia o la ricreazione dei file.

Non concedere in modo permanente ampi privilegi sull’host a un container di backup. Usa un ambiente di ripristino controllato oppure ripristina prima i dati ordinari e riapplica le etichette gestite dai criteri con gli strumenti supportati.

Separa ACL, capability e xattr specifici delle applicazioni

Confronta separatamente le voci ACL POSIX, le capability dei file Linux, le etichette SELinux, gli xattr user e i metadati Samba o macOS. Possono non essere conservati per motivi diversi.

Il modulo xattr_tdb di Samba può memorizzare separatamente gli xattr rispetto al filesystem sottostante.

Un archivio del volume a livello di file può quindi conservare l’albero dei file visibile, ma non un database separato dei metadati Samba. Includi ogni archivio di metadati dipendente oppure ricrealo tramite la procedura supportata dall’applicazione.

Ripristina un file di test e convalida l’applicazione

Crea un file sorgente noto con hash del contenuto, ACL, xattr user e tutti i metadati applicativi necessari. Esegui il backup e ripristinalo in un volume temporaneo.

L’articolo di ZimaSpace sulle modifiche ai permessi e ai metadati NAS tratta il comportamento generale delle migrazioni; questo articolo si concentra sul backup e sul ripristino dei volumi Docker.

Il problema è risolto quando gli hash del contenuto, i nomi e i valori degli xattr necessari, le ACL, le etichette di sicurezza e il comportamento dell’applicazione coincidono dopo un secondo backup e ripristino controllato.

Domande frequenti

Gli attributi estesi sono la stessa cosa delle ACL?

No. Su alcuni filesystem le ACL possono essere implementate utilizzando xattr di sistema, ma gli xattr possono anche contenere etichette di sicurezza, capability, metadati utente e valori specifici delle applicazioni.

tar conserva gli attributi estesi per impostazione predefinita?

Non darlo per scontato. GNU tar offre opzioni xattr esplicite e l’archivio deve memorizzare gli attributi durante la creazione, prima che l’estrazione possa ripristinarli.

Un ripristino può perdere gli xattr anche se viene eseguito come root?

Sì. L’archivio potrebbe non contenerli, la destinazione potrebbe non supportarli, un criterio di sicurezza potrebbe rifiutarli oppure i metadati potrebbero trovarsi in un database applicativo separato.