O Windows anulou um metadado pv do LVM

Question

Ontem usei a ferramenta de partição de disco do windows apenas para ler o layout do disco (não toquei em nada, simplesmente o abri). Parece que parte de um grupo de volumes é substituído, pelo menos no que diz respeito ao nome (rótulo e UUID); As ferramentas lv sempre solicitam um erro sobre uma partição ausente, "pNvsomething-something".

De acordo com /etc/lvm/archive , /dev/sdb e / dev/sdd1 são usados no grupo de volumes.

    physical_volumes {
            pv0 {
                    id = "pNv7bl-5uND-rHH1-B3kK-Jcud-rxCm-7nJcKb"
                    device = "/dev/sdb"     # Hint only

                    status = ["ALLOCATABLE"]
                    flags = []
                    dev_size = 1953525168   # 931,513 Gigabytes
                    pe_start = 2048
                    pe_count = 238467       # 931,512 Gigabytes
            }

            pv1 {
                    id = "983nT1-PMwL-21Fz-tGw4-1ynZ-4JP9-s5OmGv"
                    device = "/dev/sdd1"    # Hint only

                    status = ["ALLOCATABLE"]
                    flags = []
                    dev_size = 1562500000   # 745,058 Gigabytes
                    pe_start = 2048
                    pe_count = 190734       # 745,055 Gigabytes
            }
    }

Esta é a saída de blkid /dev/sdb :

/dev/sdb: PTUUID="2539097c-4f75-41e4-86c2-7e60f1f561ee" PTTYPE="gpt"

e /dev/sdb1 :

/dev/sdb1: PARTLABEL="Microsoft reserved partition" PARTUUID="ce5feefa-d5ab-4ae4-8147-d06a81fe32d3"

Eu não sei de onde vieram esses 130mb de "partição reservada da Microsoft", mas acho que é bom porque o tamanho exibido no arquivo lvm é o mesmo exibido pelo lsblk.

sdb tem um tipo de partição e UUID diferente, mas parece ser exatamente o mesmo. Eu acho que a partição de 130MB foi roubada do espaço não alocado resultante do redimensionamento da partição lv. O que devo fazer? mkfs e, em seguida, aponte lvm para o novo UUID? Não deve haver nenhuma substituição de dados.

UPDATE

Eu tenho procurado por um tempo e a ideia do mkfs foi uma idiotice, já que parece que eu deveria estar usando ferramentas de lvm.

Posso restaurar /etc/lvm/backup/nameOfVG e apontar o uuid para o dispositivo correto.

pvcreate --restorefile /etc/lvm/backup/datavg/ --uuid pNv-something /dev/sdb

O problema agora é que o pvcreate e outras ferramentas não podem acessar o / dev / sdb:

Device /dev/sdX not found (or ignored by filtering).

Alguns links:

• redhat docs

Arquivos de redhat

O Google também me lançou alguns links para soluções redhat descrevendo um problema muito semelhante, mas eles estão por trás de um paywall.

• link

• link

Answer 1

Primeiro: Execute o fsck (ou o mkfs ou qualquer coisa que esteja gravando no FS / partition) se você quiser resgatar dados de LVs incompletos. Você sempre precisa obter os PVs em seu estado original primeiro com o mínimo de modificações possível!

E segundo Primeiro: Se possível, faça um backup primeiro - você pode precisar de algum software de resgate de dados e, em qualquer caso, é melhor executá-lo em uma cópia de dados e manter o original intacto.

1. E o que o lsblk está exibindo? E blkid? E sgdisk -p / dev / sdb? E quais são os LVs: lvs --segments -a -o+pe_ranges ? É provável que esses 130MB tenham sido retirados do início de / dev / sdb, portanto, é provável que os primeiros 130MB sejam danificados, caso tenham sido formatados.

2. Agora você pode usar wipefs para remover a assinatura da GPT e, em seguida, deve poder executar o comando pvcreate acima. Ou se você quiser mais controle, sobrescreva apenas o primeiro setor (não tenho certeza de que será o suficiente) - dd if=/dev/zero of=/dev/sdb bs=4k count=1 .

3. Em qualquer caso, prefiro aproveitar uma oportunidade e mover os dados dentro de uma partição. Se houver alguma chance de o disco ser usado pelo Windows, é altamente recomendável usar a tabela de partições, de modo que os sistemas que não reconhecem o LVM não o considerem como um disco não utilizado.