Início / computer / Perguntas / 1813511
Accepted
Xenox
Asked: 2023-10-21 20:25:26 +0800 CST

Fonte confusa com destino com ddrescue

  • 772

Eu estava prestes a recuperar o segundo de cinco discos RAID com falha com o ddrescue, e uma reviravolta repentina e peculiar ocorreu em minha mente e digitei

sudo ddrescue --verbose --idirect --no-scrape -f /dev/sda /dev/sdc disk1.logfile

enquanto deveria haver /dev/sdc /dev/sda. Isso durou cerca de 28 segundos:

GNU ddrescue 1.23
About to copy 6001 GBytes from '/dev/sda' to '/dev/sdc'
    Starting positions: infile = 0 B, outfile = 0 B
    Copy block size: 128 sectors Initial skip size: 117248 sectors
Sector size: 512 Bytes

Press Ctrl-C to interrupt
     ipos: 5961 MB, non-trimmed: 0 B, current rate: 59375 kB/s
     opos: 5961 MB, non-scraped: 0 B, average rate: 205 MB/s
non-tried: 5995 GB, bad-sector: 0 B, error rate: 0 B/s
  rescued: 5961 MB, bad areas: 0, run time: 28s
pct rescued: 0.09%, read errors: 0, remaining time: 8h 6m
                              time since last successful read: n/a
Copying non-tried blocks... Pass 1 (forwards)^C
  Interrupted by user

Existe alguma maneira de desfazer a ação. O arquivo de mapa criado ajudaria?

raid

1 respostas

  1. Best Answer

    Você copiou os 5.961 MB iniciais do /dev/sdato /dev/sdc, substituindo todos os dados que estavam nos primeiros 5.961 MB do /dev/sdc.

    Não há como simplesmente desfazer. O mapfile só pode informar o tamanho exato do fragmento substituído.

    Dependendo do tipo de RAID e do layout dos arquivos e/ou sistemas de arquivos envolvidos, você poderá resgatar alguns arquivos ou até mesmo sistemas de arquivos inteiros com /dev/sdcferramentas como testdiskou photorec. Dependendo do tipo de RAID, você pode precisar remontar o RAID à força em algum modo somente leitura que ignore o fato de que você provavelmente /dev/sdcnão se parece com um membro do RAID agora; ou talvez você possa remontar o RAID "manualmente" com uma ferramenta de baixo nível como o dmsetup.

    Não espere maravilhas. Escrever quase 6 GB de dados "aleatórios" no início de qualquer disco é quase certamente um golpe mortal para o(s) sistema(s) de arquivos que existem lá. No seu caso, alguns dados foram perdidos, foram substituídos, simplesmente não estão mais lá. Você terá sorte se recuperar alguma coisa.

    Em uma situação de extrema sorte, o início do seu /dev/sdcé responsável por manter setores não utilizados por nenhum sistema de arquivos ou blocos marcados como livres em algum sistema de arquivos (isso é possível por causa do RAID; em uma configuração não-RAID, o início de um disco é sempre importante) . Então talvez o seu acidente tenha sido inofensivo. Esta é uma maravilha que você não deve esperar.

    Os sistemas de arquivos (se houver) que existem completamente além da parte sobrescrita não são afetados pelo seu acidente e recuperá-los pode ser tão "simples" quanto encontrar suas assinaturas e construir uma tabela de partição que os tornará visíveis para o sistema operacional (isto é o que pode ser feito testdisk) ; ou talvez não. Ou talvez a tabela de partições esteja em outro disco e você a verá assim que remontar o RAID (o que por si só pode ou não ser fácil). Sem informações detalhadas sobre o RAID e as estruturas de dados (partições, sistemas de arquivos), não posso dizer se há alguma chance de você ter essa sorte. Observe que em algumas configurações de vários dispositivos (como LVM) não fica imediatamente claro quais (partes de quais) sistemas de arquivos pertencem a quais (partes de quais) discos.

    Escrevi "poderia" e "poderia" porque o texto acima serve para resgatar um disco fisicamente íntegro que contém dados logicamente corrompidos.

    Se você suspeita ou sabe que /dev/sdcestá falhando fisicamente, ou seja, o disco em si não está íntegro (ao contrário de uma falha lógica onde alguns (meta)dados estão corrompidos, algo que você acabou de causar de qualquer maneira), você deve dirigir ddrescuena direção certa e trabalhar com a cópia. Então, basicamente, você deveria fazer o que ia fazer e então usar uma cópia para superar a corrupção lógica: aquela que possivelmente existia antes mais aquela que pode resultar da leitura da fonte fisicamente prejudicial, mais aquela que você causou ao sobrescrever uma parte da fonte com outra coisa.

    Como RAID significa Matriz Redundante de Discos Independentes, talvez você possa reconstruir o RAID de outros membros e não precisa (e não precisava) /dev/sdcem primeiro lugar. Obviamente, isso depende do RAID.

    A frase "o segundo entre cinco discos RAID com falha" é vaga, eu realmente não sei:

    • se você quer dizer "falha no RAID", possivelmente falhando logicamente,
    • ou se você quer dizer "discos com falha", possivelmente com falha física,
    • e se sim, então “cinco falharam” em quantas;
    • de que tipo de RAID se trata;

    então não posso dizer se você pode se recuperar do acidente graças a outros membros do RAID.

    Em geral, alguns dados são perdidos. O fato de o RAID estar envolvido pode permitir algumas abordagens que aumentam as chances de recuperação (parcial ou total); e pode proibir algumas outras abordagens. Sem informações detalhadas sobre o RAID e as estruturas de dados (partições, sistemas de arquivos) nele contidos, não há como orientá-lo de maneira ideal neste ponto; há muitos ifs e muitos "pontos de entrada" para dar sorte. Se você quiser mais ajuda, faça uma nova pergunta onde deverá nos fornecer informações detalhadas sobre o RAID. Não espere maravilhas mesmo assim.

    • 3

relate perguntas