Isenção de responsabilidade: Esta nota tem um caráter recreativo. A densidade de informações úteis nela é baixa. Foi escrita "para mim mesmo".
Introdução lírica
O depósito de arquivos na nossa organização roda em uma máquina virtual VMware ESXi 6 sob Windows Server 2016. E não é apenas um depósito. É um servidor de compartilhamento de arquivos entre os departamentos: aqui temos colaboração, documentação de projetos e pastas com os escaneadores de rede. Enfim, aqui está toda a vida produtiva.
E este reservatório de toda a vida produtiva começou a travar. E o convidado poderia travar silenciosamente, sem afetar os demais. Ele poderia bloquear toda a máquina host e, consequentemente, todas as outras máquinas convidadas. Ele poderia travar sozinho e paralisar os serviços do cliente vSphere: ou seja, os processos das outras máquinas convidadas estavam vivos, as máquinas funcionavam normalmente e respondiam, mas o depósito de arquivos não funcionava e o vSphere Client não se conectava ao host. Assim, não conseguíamos identificar nenhum sistema. As travadas podiam ocorrer durante o dia com carga leve. Podiam acontecer à noite com carga nula. Podiam ocorrer à noite durante o backup diferencial e com carga média. Podiam ocorrer nos finais de semana durante o backup completo e carga alta. E observou-se uma clara degradação da situação. No começo, era uma vez por ano, depois a cada seis meses. No final da minha paciência — duas vezes por semana.
Eu culpava a memória RAM. Mas não me permitiram interromper o depósito nem nos finais de semana e rodar o Memtest. Estávamos esperando pelos feriados de maio. Nos feriados de maio, eu rodei o Memtest e... não foram encontrados erros.
Fiquei atônito e decidi tirar férias. Enquanto estive de férias, o depósito não travou nenhuma vez. E quando voltei ao trabalho na segunda-feira — o depósito estava travado. Sobreviveu ao backup completo e justamente no final dele travou. Essa recepção calorosa de volta das férias me levou a decidir fisicamente transferir os discos da máquina convidada para outro host.
E, embora seja bem sabido que no primeiro dia após as férias não se deve fazer nada sério, enquanto eu tentava me programar para não trabalhar durante todo o caminho para o trabalho, minha indignação com mais um travamento saiu da minha cabeça, assim como minha determinação...
Os discos físicos foram transferidos para outro host. Conexão a quente. Nas configurações de armazenamento na aba Drives os discos aparecem. Na aba Datastores não há storages nesses discos. Atualizar — não aparecem. E, claro, a primeira reação é Adicionar Armazenamento. O assistente de adição informa que ele está suportando. Claro que suporta o VMFS. Eu nunca duvidei. Um olhar rápido nas mensagens do assistente em cada etapa: Próximo, Próximo, Próximo, Concluir. A visão nem sequer notou o pequeno círculo amarelo com um ponto de exclamação na parte inferior da janela de uma das etapas do assistente.
Após o término do assistente, o novo Datastore apareceu na lista… e, junto com ele, Datastores dos outros discos físicos.
Vou navegar pelo recém-adicionado Datastore, e ele… está vazio. É claro que eu fiquei surpreso novamente. 8 da manhã no relógio, primeiros 15 minutos no trabalho após as férias, nem fiz o açúcar no café ainda. E acontece isso. O primeiro pensamento foi — não puxei o disco ‘nativo’. Verifiquei se o Datastore desejado estava no ‘nativo’: não, não estava presente. O segundo pensamento foi: ‘caramba!’. Não tenho certeza, mas acho que o terceiro, quarto e pelo menos o quinto pensamento foram similares.
Para dissipar as dúvidas, rapidamente instalei uma nova versão do ESXi, peguei um disco diferente e, já me concentrando, passei pelas etapas do assistente. Sim. Ao adicionar o Datastore usando o assistente, ocorre a perda de todos os dados no disco sem possibilidade de reverter a operação e recuperar os dados. Mais tarde, li em um dos fóruns uma avaliação desse design do assistente: uma verdadeira porcaria. E concordei totalmente.
Começando a partir do sexto — os pensamentos começaram a fluir em uma direção mais construtiva. Tudo bem. A inicialização leva apenas alguns segundos, mesmo para um disco de 3Tb. Então, isso é uma formatação em alto nível. Então, a tabela de partições apenas foi sobrescrita. Então, os dados ainda estão lá. Então, agora vamos procurar um unformat e voilà.
Carregando a máquina com a imagem de inicialização do Strelec… E descubro que os programas de recuperação de partições conhecem tudo, exceto VMFS. Eles conhecem a partição do Synology, por exemplo, mas o VMFS — não.
A pesquisa dos programas de recuperação não é animadora: na melhor das hipóteses, GetDataBack e R.Saver encontram partições NTFS com estruturas de diretórios vivas e nomes de arquivos ativos. Mas isso não me satisfaz. Eu preciso de dois arquivos vmdk: com o disco do sistema e com o disco dos arquivos de lixo.
E aqui percebo que, aparentemente, vou ter que instalar o Windows e restaurar a partir do backup. E, ao mesmo tempo, lembro que eu tinha a raiz DFS lá. E ainda uma sistema de permissões de acesso a pastas de departamentos completamente maluca em volume e ramificação. Não é uma opção. A única opção viável em termos de tempo é restaurar o estado do sistema e do disco com os dados e todas as permissões.
Mais uma vez, pesquisa no Google, fóruns, KBs e novamente o choro da Iaroslavna: o VMware ESXi não prevê um mecanismo de recuperação de dados. Todos os tópicos de discussão têm dois finais: alguém se recuperou com o caro DiskInternals VMFS Recovery ou alguém foi ajudado por um especialista que ativamente promove seus serviços. vmfs-tools e dd. A opção de comprar uma licença do DiskInternals VMFS Recovery por $700 — não é uma opção. Permitir que uma pessoa de "território potencialmente hostil" tenha acesso a dados corporativos — também não é uma opção. Mas descobri que o UFS Explorer também consegue ler partições VMFS.
DiskInternals VMFS Recovery
Uma versão de teste foi baixada e instalada. O programa viu com sucesso a partição VMFS vazia:
No modo Undelete (Fast Scan) também encontrou o Datastore apagado com pastas máquinas virtuais com discos dentro:
A visualização mostrou que os arquivos estavam vivos:
A montagem da partição no sistema foi bem-sucedida, mas, por razões desconhecidas, em todas as três pastas havia a mesma máquina virtual. Claro, por uma lei da má sorte — não era a que precisava.
Três linhas de vergonhaA tentativa empreendida de piratear descaradamente o software terminou em fracasso. Mas o UFS Explorer foi pirateado.
Sou extremamente contra o roubo de software. De forma alguma eu incentivo o uso de meios de contornar a proteção contra o uso não licenciado.
Eu estava em uma situação catastrófica e não me orgulhava das medidas que tomei.
UFS Explorer
A varredura do disco mostrou a presença de 7 nós. O número de nós coincidiu "de forma surpreendente" com a quantidade de arquivos *-flat.vmdk encontrados pelo VMFS Recovery:
A comparação entre os tamanhos dos arquivos e os tamanhos dos nós também mostrou coincidência até o byte. Ao mesmo tempo, foram recuperados os nomes dos arquivos *-flat.vmdk e, consequentemente, sua pertencença às máquinas virtuais.
Em geral, os discos vmdk do ponto de vista do ESXi consistem em dois arquivos: um arquivo de dados (<nome da máquina>-flat.vmdk) e um arquivo de "particionamento físico" do disco (<nome da máquina>.vmdk). Se você enviar o arquivo *-flat.vmdk do seu computador local para o Datastore, o ESXi não reconhecerá como um arquivo de disco válido. Há um artigo na base de conhecimento da VMware explicando como criar manualmente o arquivo de descrição do disco: , mas eu não precisei fazer isso, apenas copiei e colei o conteúdo dos arquivos correspondentes da área de visualização do arquivo no DiskInternals VMFS Recovery:
Após 4 horas extraindo 2,5TB de um nó do UFS Explorer e 20 horas fazendo upload para o Datastore do hipervisor, os arquivos de disco danificados foram conectados a uma nova máquina virtual. Os discos foram reconhecidos. Não foram notadas perdas de dados.
Fonte: habr.com
