## page was renamed from emanuc/ripararebtrfs #format wiki #LANGUAGE it <
> <> <> = Introduzione = In questa guida sono descritte le procedure su come gestire la corruzione del filesystem Btrfs. Nonostante Btrfs sia progettato con solide caratteristiche per rilevare e correggere la corruzione dei dati, ci sono ancora casi in cui il filesystem può subire danni a causa di problemi hardware. Ad esempio: *'''Guasti del controller o del firmware del disco''': Un controller o firmware difettoso può inviare dati corrotti al filesystem senza segnalarlo correttamente, rendendo inefficaci i meccanismi di protezione di Btrfs. In alcuni casi, l'hardware può corrompere i dati a livello di interfaccia, aggirando i meccanismi di checksum. * '''Problemi nella memoria RAM''': si pensi alla corruzione dei dati dovuta a bit errati; Btrfs non può fare molto per rilevare tali errori prima che i dati vengano scritti su disco. Ad esempio, se un errore di memoria altera i dati prima che vengano scritti su Btrfs, i checksum verranno calcolati sui dati già corrotti, quindi Btrfs non riuscirà a rilevare l'errore. {{{#!wiki note Nella guida viene preso come esempio il nome del dispositivo `/dev/sda2`; sostituirlo con il nome del dispositivo della partizione Btrfs (consultare [[Hardware/DispositiviPartizioni/Partizioni|questa guida]] per identificarlo). }}} = Salvare i dati = In caso di corruzione, Btrfs passa automaticamente alla modalità di sola lettura per non far propagare la corruzione. In questo scenario è possibile salvare i dati, che è la l'azione raccomandata prima di provare a riparare il filesystem. 0. Nel caso in cui il filesystem non sia montabile, provare a montarlo in sola lettura nella modalità “rescue”. Abilitare quindi tutte le opzioni di recupero supportate (btrfs-progs 5.9):{{{ sudo mount -o ro,rescue=all /dev/sda2 /mnt }}} 0. Qualora l'azione precedente non sia andata buon fine, provare a utilizzare gli slot root di backup all'interno del super blocco (btrfs-progs 5.9):{{{ sudo mount -o ro,rescue=usebackuproot /dev/sda2 /mnt }}} 0. Infine salvare tutti i dati e procedere alla riparazione del filesystem. {{{#!wiki important Potrebbe capitare che il filesystem non venga montato con le opzioni di salvataggio. Ad esempio questo avviene in caso di errore simile al seguente: `[ 4007.489730] BTRFS error (device vdb): parent transid verify failed on 30736384 wanted 10 found 8`. L'errore `parent transiid verify` indica un errore critico. Si consiglia quindi di passare direttamente al paragrafo [[#recuperodati|Recupero dati]] per cercare di recuperare più dati possibili. Per ulteriori dettagli consultare [[https://btrfs.readthedocs.io/en/latest/trouble-index.html#troubleshooting-pages|questo link]]. }}} == Perché si verificano errori transid? == Linux utilizza '''[[https://en.wikipedia.org/wiki/Disk_buffer#Cache_control_from_the_host|Flush/FUA]]''' (precedentemente noto come '''barriers''') per garantire che nessun dato aggiuntivo venga scritto su disco prima che Flush/FUA sia completato. Questo è essenziale poiché i dispositivi di archiviazione possono riordinare le scritture nella loro cache per ottimizzare le prestazioni. Quindi Flush/FUA assicura che i dati su disco siano in un ordine coerente, anche in caso di interruzione dell'alimentazione. Quando si verifica un errore `Parent Transid Verify Failed` spesso significa che il dispositivo di archiviazione non ha rispettato correttamente Flush/FUA. In alcuni casi potrebbe esserci stato un problema con un bus o con un ripristino del dispositivo, causando la perdita di dati in transito, o nella cache del disco, portando a un filesystem incoerente. Altre situazioni che possono portare a errori `` sono: * '''Bug logici''': le strutture del filesystem non sono state aggiornate o memorizzate correttamente. * '''Scritture errate''': il dispositivo di archiviazione non ha memorizzato i dati all'indirizzo corretto, sovrascrivendo altri dati. * '''Il dispositivo di archiviazione a blocchi''' (hardware o emulato) non è affidabile e perde dati tra le transazioni, causando confusione nel filesystem. * '''Scritture perse senza una corretta gestione degli errori''': la scrittura sembra essere riuscita a livello del filesystem, ma a livelli inferiori si sono verificati problemi non propagati correttamente. * '''Modalità di sospensione''': a volte può confondere il kernel o la cache dell'unità, causando perdite di dati e gli stessi tipi di errori. = Controllo hardware = Prima di procedere al tentativo di riparazione è importante escludere problemi hardware, poiché un tentativo di riparazione su un hardware difettoso non fa altro che peggiorare la corruzione del filesystem. == Informazioni preliminari == * Qualora il dispositivo "menta" sulla sua capacità di supportare '''barriers''', Linux non ha modo di sapere se i dati siano effettivamente sul drive. È quindi molto difficile mitigare completamente questo rischio. * Se il dispositivo è in un alloggiamento USB, provare a passarlo in un altro alloggiamento o direttamente sul bus SATA. È abbastanza comune che i bridge USB-SATA utilizzati negli alloggiamenti non implementino tutte le funzionalità ATA, non avendo una buona gestione degli errori, o che semplicemente forniscano informazioni accurate sulle capacità del dispositivo. Sono stati segnalati casi di adattatori USB che non implementavano correttamente il protocollo ''USB attached SCSI (UAS)'' e che perdevano scritture durante carichi pesanti (in questo caso può essere utile disabilitare il modulo del kernel UAS). * La disabilitazione della cache di scrittura è una possibile mitigazione del problema suindicato. Riduce leggermente le prestazioni, ma dovrebbe impedire il riordino della cache di scrittura. Usare '''hdparm''' per disabilitare la cache di scrittura. == Test sull'hardware == 0. '''Test del drive:''' consultare [[Hardware/DispositiviPartizioni/VerificaDiscoFisso#Controllo_per_difetti_fisici|questo paragrafo]]. 0. '''Test della Ram:''' utilizzare la funzione '''!MemTest''' disponibile in una qualsiasi [[Installazione/InstallareUbuntu#Creazione_del_supporto_di_installazione|live]] di Ubuntu o derivata (o anche altra distribuzione). Memtest86 eseguirà molti test diversi sulla RAM (alcuni dei quali possono richiedere più di 30 minuti). 0. '''Stabilità alimentatore:''' verificare il corretto funzionamento dell'alimentazione. 0. '''Controllo dei cavi SATA''': verificare che i siano ben collegati e funzionanti. = Controllo del filesystem = La soluzione più sicura e attendibile per procedere al controllo del filesystem è eseguirlo con quest'ultimo smontato. Se è una partizione di sistema, si raccomanda di utilizzare una live che includa l’ultima versione stabile di '''btrfs-progs''' (per controllare l'ultima versione consultare il tag release dal [[https://github.com/kdave/btrfs-progs/tags|progetto upstream]]). * Controllo senza opzioni:{{{ sudo btrfs check /dev/sda2 }}} * Controllo in modalità ''lowmem'' (potrebbe restituire risultati più dettagliati rispetto alla modalità precedente, in più utilizza meno memoria RAM):{{{ sudo btrfs check --mode=lowmem /dev/sda2 }}} * Verifica checksum dei dati (è essenzialmente uno scrub offline, ma senza riparare i dati dalle copie, se presenti):{{{ sudo btrfs check --check-data-csum /dev/sda2 }}} = Riparazione = * È possibile determinare se è necessario cancellare l'albero dei [[AmministrazioneSistema/LogDiSistema|log]] in base al backtrace del kernel. Se gli errori sono simili ai seguenti, le parole chiave da cercare sono `open_ctree` (che dice che l'errore è durante il montaggio) e i nomi delle funzioni che contengono replay, ripristino o log_tree:{{{ ? replay_one_dir_item+0xb5/0xb5 [btrfs] ? walk_log_tree+0x9c/0x19d [btrfs] ? btrfs_read_fs_root_no_radix+0x169/0x1a1 [btrfs] ? btrfs_recover_log_trees+0x195/0x29c [btrfs] ? replay_one_dir_item+0xb5/0xb5 [btrfs] ? btree_read_extent_buffer_pages+0x76/0xbc [btrfs] ? open_ctree+0xff6/0x132c [btrfs] }}} * Cancella l'albero dei log:{{{ sudo btrfs rescue zero-log /dev/sda2 }}} * Tenta di recuperare i metadati corrotti relativi ai `chunk` (i blocchi di dati):{{{ sudo btrfs rescue chunk-recover /dev/sda2 }}} * Correggere le dimensioni del dispositivo e i valori dei byte totali del superblocco che non corrispondono. A partire dal Kernel 4.11, le dimensioni del dispositivo vengono controllate in modo più rigoroso e questo potrebbe causare un disallineamento del valore memorizzato dei byte totali. Vedere il messaggio di errore esatto qui sotto. Il kernel più recente si rifiuterà di montare il file system se i valori non corrispondono. Questo errore non è fatale e può essere risolto. Questo comando correggerà i valori dimensionali del dispositivo, quando possibile:{{{ BTRFS error (device sdb): super_total_bytes 92017859088384 mismatch with fs_devices total_rw_bytes 92017859094528 WARNING: CPU: 3 PID: 439 at fs/btrfs/ctree.h:1559 btrfs_update_device+0x1c5/0x1d0 [btrfs] }}} * Correggere le dimensioni del dispositivo e i valori dei byte totali del superblocco che non corrispondono:{{{ sudo btrfs rescue fix-device-size /dev/sda2 }}} {{{#!wiki important La modalità riparazione potrebbe peggiorare la corruzione del filesystem. Avviare questa modalità solo dopo aver copiato i dati nell backup e se le altre operazioni di recupero non hanno funzionato. È presente un avviso e un ritardo di 10 secondi quando questa opzione viene eseguita senza "--force". }}} * Avvia la modalità riparazione e tenta di risolvere i problemi, ove possibile:{{{ sudo btrfs check --repair /dev/sda2 }}} * Se la riparazione è andata a buon fine e il filesystem è di nuovo in modalità RW, è raccomandato eseguire uno '''scrub''' per verificare l'integrità dei dati. La verifica deve essere eseguita con il filesystem montato:{{{ sudo btrfs scrub start -B /mountpoint }}} <> = Recupero dati = Il recupero dei dati va eseguito se il filesystem non viene montato neanche in modalità '''rescue'''. Il comando '''btrfs restore''' viene utilizzato per recuperare file da un filesystem Btrfs danneggiato senza montarlo. Questo comando è utile quando il filesystem non può essere montato normalmente a causa di corruzione o di altri errori gravi. Invece di tentare di riparare il filesystem, btrfs restore cerca di copiare i dati leggibili in un'altra posizione. 0. Preparare un dispositivo per poter copiare i dati, di dimensione uguale o maggiore alla quantità di dati presenti sul filesystem. 0. [[Hardware/DispositiviPartizioni/MontarePartizioni|Montare]] il dispositivo (verrà preso come esempio il percorso: `/mnt/recupero`; modificarlo in base alla posizione di mount del disco di recupero). 0. Eseguire uno dei seguenti comandi in base all'azione desiderata: * Elencare i file recuperabili senza copiarli:{{{ sudo btrfs restore -l /dev/sda2 }}} * Recuperare tutti i file :{{{ sudo btrfs restore /dev/sda2 /mnt/recupero }}} * Ignorare i file corrotti:{{{ sudo btrfs restore -i /dev/sda2 /mnt/recupero }}} * Recuperare solo un file specifico:{{{ sudo btrfs restore -o /percorso/del/file /dev/sda2 /mnt/recupero }}} = Recupero dei dati cancellati accidentalmente = Grazie alla sua struttura interna e alle sue caratteristiche avanzate di gestione dei dati, su Btrfs è possibile recuperare file cancellati in determinate circostanze. Sebbene non offra direttamente un "livello di backup" come farebbe un sistema di backup tradizionale, alcune funzionalità del filesystem facilitano il recupero dei dati cancellati: * '''Struttura a copy-on-write (CoW)''': Btrfs utilizza un modello [[https://it.wikipedia.org/wiki/Copy-on-write|copy-on-write (CoW)]], il che significa che quando i dati vengono modificati, il filesystem crea nuovi blocchi per memorizzare i dati modificati, invece di sovrascrivere i blocchi esistenti. Questo lascia intatti i vecchi blocchi fino a quando non sono esplicitamente liberati.<
>Quando un file viene cancellato, i metadati vengono aggiornati per riflettere la cancellazione, ma i dati fisici sul disco non vengono immediatamente sovrascritti. Pertanto è possibile il recupero dei dati fino a quando quei blocchi non vengono sovrascritti da nuovi dati. * '''Strumenti di recupero''': è possibile esplorare e recuperare i file tramite lo stesso '''btrfs restore''', ma esistono script di terze parti creati da utenti della comunità possono fungere per lo stesso scopo. Consultare la documentazione specifica dei singoli progetti per informazioni sull'utilizzo. * [[https://github.com/danthem/undelete-btrfs|undelete-btrfs]] * [[https://gist.github.com/Changaco/45f8d171027ea2655d74|btrfs-undelete]] = Ulteriori risorse = * [[https://btrfs.readthedocs.io/en/latest/btrfs-check.html|btrfs-check]] * [[https://btrfs.readthedocs.io/en/latest/btrfs-rescue.html|btrfs-rescue]] * [[https://btrfs.readthedocs.io/en/latest/btrfs-restore.html|btrfs-restore]] * [[https://btrfs.readthedocs.io/en/latest/btrfs-find-root.html|btrfs-find-root]] * [[https://btrfs.readthedocs.io/en/latest/btrfs-scrub.html|btrfs-scrub]] * [[https://wiki.tnonline.net/w/Btrfs/Parent_Transid_Verify_Failed#Why_does_transid_errors_happen?|Btrfs/Parent Transid Verify Failed]] * [[https://en.opensuse.org/SDB:BTRFS#How_to_repair_a_broken.2Funmountable_btrfs_filesystem| How to repair a broken/unmountable btrfs filesystem (Wiki OpenSUSE)]] ---- CategoryAmministrazione CategoryHardware