Olá fórum.
Procurei bastante no fórum e no StackOverFlow SuperUser e no StackOverFlow Ubuntu e em geral na internet, mas não consigo entender parte dos comando e se estou fazendo certo.
Meu HD ele tem alguns badblocks, eu cheguei a usar ele com o driver BRTFS no Windows, acho que tentei copiar algo para ele e caiu a luz elétrica no meio da cópia, quando reiniciei o Windows já não reconhecia mais a partição, dizendo que ela esta no formato Raw.
Primeiro um resposta no Superuser - StackOverflow sugere os seguintes comandos:
btrfs rescue super-recover -v /dev/sdc3
RETORNO:
All Devices:
Device: id = 1, name = /dev/sdc3
Before Recovering:
[All good supers]:
device name = /dev/sdc3
superblock bytenr = 65536
device name = /dev/sdc3
superblock bytenr = 67108864
device name = /dev/sdc3
superblock bytenr = 274877906944
[All bad supers]:
All supers are valid, no need to recover
Aparentemente não precisa de reparo no superblock.
Quando tento montar olha o que aparece:
mount /dev/sdc3 /home/zorin/X/
RETORNO:
mount: /home/zorin/X: tipo de sistema de arquivos incorreto, opção inválida, superbloco inválido em /dev/sdc3, página de código ou programa auxiliar faltando ou outro erro.
O comando assseguir mostra erros, mas como faço para recuperar:
btrfs check /dev/sdc3
RETORNO:
Opening filesystem to check...
checksum verify failed on 498614272 found 000000CE wanted 00000000
checksum verify failed on 498614272 found 000000FF wanted 0000006B
checksum verify failed on 498614272 found 000000CE wanted 00000000
bad tree block 498614272, bytenr mismatch, want=498614272, have=353805839351056712
Couldn't read tree root
ERROR: cannot open file system
Me parece que ele nem sabe que o sistema de arquivos é BRTFS.
Essa é a grande vantagem do SSD, por não conter partes mecânicas ele não sofre danos físicos em queda de energia.
2 curtidas
É pessoal a situação ta critica, ainda mais por que eu estava usando um driver experimental para Windows.
Pesquisando encontrei esse app pago “Hetman RAID Recovery” aparentemente ele recupera dados de partições BTRFS em sistemas raid. Vou tentar com esse para ver se pelo menos ele encontra alguns projetos de programação de alguns clientes meu.
Chegando um pouco atrasado, mas o que eu faria?
Abra uma janela com o o log do sistema para monitorar a saída. journalctl -f
Numa segunda janela, tente montar o sistema de arquivos como somente leitura:
mount -t btrfs -o ro /dev/sdc3 /home/zorin/X/
Se conseguir montar, salve seus arquivos em outro disco e tente criar novo sistema de arquivos nele (formatar).
Se não conseguir, veja a saída no log do sistema dos erros apresentados.
1 curtida
Uma ideia, se você quer ter certeza de que não vai “ferrar” nada (se montar em modo leitura apenas, como o @Deleterium apontou, não resolver), o ideal seria fazer uma imagem desse HDD e trabalhar na imagem, se você tiver espaço lógico. Que dai você vai poder tentar de tudo mesmo, até métodos bem perigosos como repair.
Depois de alguns meses muito ocupado, hoje parai par analizr novamente o disco, qui o log do journalctl:
set 21 00:49:05 DEV sudo[3610]: lrissa : TTY=pts/0 ; PWD=/home/utherbone ; USER=root ; COMMAND=/usr/bin/mount -t btrfs -o ro /dev/sda3 /home/utherbone/X/
set 21 00:49:06 DEV kernel: BTRFS info (device sda3): flagging fs with big metadata feature
set 21 00:49:06 DEV kernel: BTRFS info (device sda3): disk space caching is enabled
set 21 00:49:06 DEV kernel: BTRFS info (device sda3): has skinny extents
set 21 00:49:06 DEV kernel: BTRFS error (device sda3): bad tree block start, want 498614272 have 353805839351056712
set 21 00:49:06 DEV kernel: BTRFS error (device sda3): bad tree block start, want 498614272 have 0
set 21 00:49:06 DEV kernel: BTRFS warning (device sda3): couldn't read tree root
set 21 00:49:06 DEV kernel: BTRFS error (device sda3): open_ctree failed
@romulopb, eu não tenho espaço suficiente, olha como t as partições do disco:
tive a má sorte de ter uma ma sorte de travar durante uma cópia dos arquivos, provavelmente tava tentando gravar em um badblock, esperei por horas afio, tive que rezetr o PC i depois disso não consegui mais montar.
Acho que vou ter que recorer a algum programa que recupera raid em btrfs, mas inda tenho esperança.
Eu daria uma olhada nos dados SMART dos seus discos. Que tipo de RAID você montou? 1, 0? (realmente espero que tenha feito um RAID 1)
sudo smartctl -a /dev/sda
sudo smartctl -a /dev/sdc
...
Dependendo do resultado e o tipo de RAID, eu não teria muita fé em recuperar mais do que uma parte dos dados, um HD danificado vira uma caixa preta sem chave…
Espero que esse guia lhe ajude a entender seu caso:
2 curtidas
Não usei RAID, é que existem alguns softwares que conseguem recuperar discos de servidores em BTRFS, no caso seria como um disco RAID 1.
Tem um projeto em Laravel que eu não fiz backup das ultimas duas mudanças. por isso tenho interesse em recuperar, sim, o disco possuí alguns badblocks. pode ser por isso que ele se recusa a montar, mesmo os superblocos estarem bons.
O ponto é que quando falam em ferramentas que recuperam RAID, geralmente é pelo fato de RAID facilita a recuperação. Essas ferramentas recorrem exatamente ao RAID que é quem fornece a redundância necessária para resolver o problema de corrupção. Não sei se funcionaria no seu caso já que você não tem RAID de redundância.
Infelizmente isso é uma coisa que eu acho que as pessoas não frisam o suficiente (ou não sabem, são leigos apresentando BTRFS para leigos) quando apresentar o BTRFS para o mercado de usuários comuns…
O poder de prevenção de corrupção de BTRFS, ZFS e similares é, 99%, graças a RAID de redundância (no caso do BTRFS, 1 e 10, que são os únicos aconselháveis até o momento). Sem isso, em termos de corrupção, você está praticamente no mesmo barco que todo o resto.
Agora é uma questão do seu HD cooperar… tente:
mount -o ro,rescue=all /dev/sdc3 /home/zorin/X/
E se conseguir montar, te aconselho a apenas tentar copiar o que realmente você não tem backup e importa, pois provavelmente se você tentar ler a parte defeituosa, novamente, vai trancar.
Pela situação imagino que houve:
- Um bloco defeituoso onde estava uma parte muito importante do sistema (raiz da árvore do BTRFS).
- HD detecta o badblock defeituoso e tenta recuperar os dados, possivelmente recuperando apenas parte da informação.
- HD reloca o bloco defeituoso, como se tivesse sido recuperado com sucesso
- Agora o sistema tenta ler os dados, o bloco daquela região está bom (não há erro de I/O), porém o conteúdo foi perdido.
Imagino isso justamente por ter “have 0”, o que indica que houve perda de dados e o conteúdo completado com zeros.
man btrfs-check
Tem algumas opções interessantes para tentar verificar os superblocos pelo backup. Eu tentaria:
- btrfs-check --backup
- btrfs-check --backup --super 0
- btrfs-check --backup --super 1
- btrfs-check --backup --super 2
Lembrando que se vc quiser corrigir (–repair), estará entrando na região perigosa de mais perda ainda de dados. Novamente se a informação for importante, clone o disco e tente recuperar em backups do backup da imagem.
