Checklist per il recupero dei metadati Btrfs per un home server quasi pieno

L'approccio sicuro consiste nel trattare la stabilizzazione delle scritture, il recupero dello spazio di lavoro, l'esecuzione del solo bilanciamento filtrato e la verifica dei dati prima del ripristino del servizio normale come una sequenza di verifiche osservabili, non come un singolo comando.

Su un filesystem Btrfs quasi pieno di un home server, il rischio concreto è che Btrfs segnali ENOSPC o diventi di sola lettura quando lo spazio per i metadati è esaurito. Registra l'identità attuale e il punto di ripristino, inizia con il discriminante meno invasivo, interpreta i risultati positivi e negativi prima di modificare un'altra variabile e fermati quando lo storage diventa instabile o l'unica copia recuperabile verrebbe esposta. Il flusso di lavoro seguente termina solo dopo che il carico originale ha funzionato o le evidenze hanno raggiunto una soglia di escalation.

Stabilizza il filesystem prima di tentare la riparazione

Arresta container, download, snapshot e processi che generano molti log e scrivono sul filesystem interessato. Salva gli errori del kernel e l'output di btrfs device stats in un'altra posizione. Se il filesystem è stato rimontato in sola lettura o segnala errori di checksum, parent transid o I/O, mantienilo in sola lettura finché non avrai una copia recuperabile.

Non iniziare con btrfs check --repair, un bilanciamento completo, la deframmentazione o l'eliminazione massiva. La domanda immediata è se lo stato valido del filesystem non disponga di spazio di lavoro per le allocazioni oppure se gli errori di storage stiano danneggiando i metadati; intervenire prima con la riparazione può rendere più difficile distinguere i due casi e consumare lo spazio rimanente.

La verifica di sicurezza è superata quando i servizi che eseguono molte scritture sono arrestati, i dati importanti dispongono di un'altra copia e sai quale dispositivo a blocchi e quale punto di montaggio stai esaminando. Passa all'acquisizione di un'immagine di recupero se il dispositivo si reimposta, scompare o accumula errori di lettura.

Leggi l'allocazione invece del dato principale sullo spazio libero

Esegui btrfs filesystem usage -T /mount, btrfs filesystem df /mount, btrfs device usage /mount e controlla i messaggi recenti del kernel. Confronta lo spazio dei metadati allocato e utilizzato con lo spazio non allocato disponibile su ogni dispositivo; il solo comando df ordinario non può mostrare se Btrfs è in grado di allocare un altro chunk di metadati.

Un bilanciamento mirato richiede spazio di lavoro completamente inutilizzato. Una guida al bilanciamento mirato di Btrfs dettagliata spiega che un bilanciamento non filtrato riscrive tutti i gruppi di blocchi idonei e che l'obiettivo è mantenere spazio non allocato a livello di dispositivo, non semplicemente eliminare un file di grandi dimensioni e presumere che i metadati possano crescere.

Se l'utilizzo dei metadati è elevato ma rimane spazio non allocato, un piccolo bilanciamento filtrato può recuperare chunk vuoti o utilizzati solo in parte. Se nessun dispositivo dispone di spazio di lavoro, rimuovi prima dati o snapshot eliminabili in sicurezza e in piccoli gruppi, oppure aggiungi un dispositivo temporaneo adatto al profilo del filesystem; non avviare una rilocazione che non può terminare.

Recupera spazio di lavoro con l'azione meno invasiva

Inizia eliminando i file non necessari che non sono conservati dagli snapshot, poi elimina solo gli snapshot di cui hai confermato l'inutilità. Esegui la sincronizzazione e ricontrolla l'utilizzo dopo ogni modifica di piccole dimensioni. Se un bilanciamento è giustificato, inizia con btrfs balance start -dusage=0 -musage=0 /mount o con un altro filtro ristretto scelto in base all'allocazione osservata, non con un bilanciamento completo.

La descrizione del manuale Linux del comportamento del bilanciamento filtrato osserva che i filtri limitano la rilocazione e che può verificarsi ENOSPC quando il bilanciamento stesso non dispone di spazio di lavoro. Controlla btrfs balance status e i log del kernel. Se la rilocazione aumenta gli errori, si blocca a causa di problemi del dispositivo o consuma l'ultimo margine di sicurezza, annullala e torna al recupero in sola lettura.

Non combinare filtri ed eliminazioni senza effettuare misurazioni tra un passaggio e l'altro. Il ramo di recupero ha esito positivo quando i metadati dispongono di margine, esiste spazio non allocato sui dispositivi necessari e una piccola scrittura viene completata senza un nuovo evento ENOSPC o il passaggio forzato alla sola lettura.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifica i dati e previeni una ricaduta immediata

Riavvia un solo servizio a basso rischio e riproduci il carico di lavoro che inizialmente aveva riempito i metadati, ad esempio la creazione di snapshot o numerose modifiche a file di piccole dimensioni. Ricontrolla l'utilizzo e i log del kernel dopo il carico di lavoro e dopo un riavvio. Un mount che funziona una volta ma torna in sola lettura durante l'attività normale non è recuperato.

Usa il metodo ZimaSpace per distinguere se lo spazio NAS è utilizzato da snapshot o file attivi prima di modificare la conservazione. Gli extent mantenuti dagli snapshot possono far sembrare inefficace un'eliminazione, mentre l'attività continua su molti file piccoli può mantenere elevata la pressione sui metadati; la politica corretta dipende dallo stato dimostrato dalle misurazioni.

Riprendi il servizio normale solo dopo che il filesystem è rimasto scrivibile, le statistiche del dispositivo hanno smesso di aumentare, un file rappresentativo è stato ripristinato o sottoposto correttamente a hashing e il monitoraggio segnala l'allarme prima che lo stesso margine scompaia. Inoltra gli errori strutturali persistenti a uno specialista del recupero Btrfs e lavora da un clone invece di ripetere i comandi di riparazione sull'unica copia.