Aviso Legal: A nota é para fins de entretenimento. A densidade específica de informações úteis é baixa. Foi escrito “para mim”.
Introdução lírica
O despejo de arquivos em nossa organização é executado em uma máquina virtual VMware ESXi 6 executando o Windows Server 2016. E isso não é apenas um despejo de lixo. Este é um servidor de troca de arquivos entre divisões estruturais: há colaboração, documentação de projetos e pastas de scanners de rede. Em geral, toda a vida produtiva está aqui.
E esse contêiner de toda a vida produtiva começou a travar. Além disso, o convidado poderia enforcar-se silenciosamente, sem afetar os outros. Ele poderia derrubar todo o host e, consequentemente, todas as outras máquinas convidadas. Eu poderia me enforcar e travar os serviços do cliente vSphere: ou seja, os processos dos outros convidados estão ativos, as máquinas funcionam corretamente e respondem, mas não há lavador de arquivos e o vSphere Client não se apega ao host. Em geral, nenhum sistema pôde ser identificado. Podem ocorrer congelamentos durante o dia durante uma carga baixa. Eles poderiam fazer isso à noite sem carga. Poderia à noite durante backup diferencial e carga média. Poderia nos finais de semana durante backups completos e alta carga. E houve uma clara degradação da situação. No início era uma vez por ano, depois uma vez a cada seis meses. No fim da minha paciência - duas vezes por semana.
Eu tive um problema de memória. Mas eles não me deixaram parar o lixo nem nos finais de semana e rodar o Memtest. Estávamos esperando as férias de maio. Durante as férias de maio, executei o Memtest e... nenhum erro foi encontrado.
Fiquei maravilhado e decidi sair de férias. Enquanto eu estava de férias, não houve um único problema no depósito de lixo. E quando voltei ao trabalho no primeiro dia de segunda-feira, havia um monte de lixo. Aguentei um backup completo e desliguei logo após a conclusão. Uma recepção tão calorosa das férias me levou à decisão de arrastar fisicamente os discos com a máquina convidada para outro host.
E, embora se saiba há muito tempo que não se pode fazer nada sério no primeiro dia após as férias, embora eu estivesse me preparando para não trabalhar até o trabalho, minha indignação com mais um congelamento abalou meu humor e meu votos fora da minha cabeça...
Os discos físicos foram movidos para outro host. Conexão quente. Nas configurações de armazenamento na guia Drives discos aparecem. Na aba Armazenamentos de dados Não há armazenamento nesses discos. revisar - Não apareça. Bem, claro, o primeiro impulso - Adicionar armazenamento. O Assistente para Adicionar explica o que ele oferece suporte. Claro que também suporta VMFS. Eu não duvidei disso. Uma rápida olhada nas mensagens do assistente em cada etapa: Próximo, Próximo, Próximo, Concluir. O olho nem chegou perto de captar o pequeno círculo amarelo com ponto de exclamação na parte inferior da janela de uma das escadas do mestre.
No final do assistente, o novo Datastore apareceu na lista... e junto com ele os Datastores dos discos físicos restantes.
Prossigo navegando pelo Datastore recém-adicionado e ele está... vazio. Claro, fiquei surpreso. São 8h, primeiros 15 minutos de trabalho depois das férias, ainda nem mexi o açúcar do café. E aqui está. O primeiro pensamento foi que retirei o disco errado do host “nativo”. Procurei ver se o Datastore necessário estava presente no host “nativo”: não, não estava presente. O segundo pensamento foi: “foda-se!” Não tenho certeza, mas me parece que o terceiro, o quarto e pelo menos o quinto pensamento eram iguais.
Para tirar dúvidas, instalei rapidamente um ESXi novo para teste, peguei o disco esquerdo e, já lendo, percorri os passos do assistente. Sim. Ao adicionar um Datastore usando o assistente, você perde todos os dados no disco sem a capacidade de reverter a operação e restaurar os dados. Mais tarde li em um dos fóruns uma avaliação desse design feita por um mestre: uma porcaria de merda. E eu realmente concordei.
A partir do sexto dia, os pensamentos fluíram em uma direção mais construtiva. OK. A inicialização leva apenas alguns segundos, mesmo para um disco de 3 TB. Portanto, esta é uma formatação de alto nível. Isso significa que a tabela de partições foi simplesmente reescrita. Portanto, os dados ainda estão lá. Então, agora vamos procurar algum unformat e pronto.
Eu inicializo a máquina a partir da imagem de inicialização do Strelec... E descubro que os programas de recuperação de partição sabem tudo, exceto VMFS. Por exemplo, eles conhecem o layout da partição do Synology, mas não do VMFS.
Pesquisar programas não é reconfortante: na melhor das hipóteses, GetDataBack e R.Saver encontram partições NTFS com uma estrutura de diretório ativa e nomes de arquivo ativos. Mas isso não combina comigo. Preciso de dois arquivos vmdk: com o disco do sistema e o disco do arquivo lixo.
E então entendo que agora vou instalar o Windows e lançar a partir de um backup de arquivo. E ao mesmo tempo lembro que tinha uma raiz DFS lá. E também um sistema de direitos de acesso às pastas do departamento que é absolutamente selvagem em escopo e ramificações. Não é uma opção. A única opção aceitável em termos de tempo é restaurar o estado do sistema e do disco com dados e todos os direitos.
Novamente Google, fóruns, KB'shki e novamente o choro de Yaroslavna: VMware ESXi não fornece um mecanismo de recuperação de dados. Todos os tópicos de discussão têm dois finais: alguém foi recuperado usando o caro DiskInternals VMFS Recovery ou alguém foi ajudado por um especialista em software que promove ativamente seus serviços ferramentas vmfs и dd. A opção de adquirir uma licença DiskInternals VMFS Recovery por US$ 700 não é uma opção. Permitir que alguém de fora do “território de um inimigo potencial” acesse dados corporativos também não é uma opção. Mas foi pesquisado no Google que as partições VMFS também podem ser lidas pelo UFS Explorer.
Recuperação DiskInternals VMFS
A versão de teste foi baixada e instalada. O programa viu com sucesso a partição VMFS vazia:
No modo Recuperar exclusão (verificação rápida) Também encontrei um Datastore surrado com pastas de máquinas virtuais com discos dentro:
A visualização mostrou que os arquivos estão vivos:
A montagem da partição no sistema foi bem-sucedida, mas por algum motivo desconhecido, todas as três pastas continham a mesma máquina virtual. É claro que, de acordo com a lei, a maldade não é o que é exigido.
Três linhas de vergonhaA tentativa de bloquear descaradamente o software terminou em fracasso. Mas o UFS Explorer travou.
Tenho uma atitude extremamente negativa em relação ao roubo de software. De forma alguma incentivo o uso de meios para contornar a proteção contra uso não licenciado.
Eu estava numa situação catastrófica e não estava nada orgulhoso das medidas a que tinha recorrido.
Explorador UFS
Uma varredura de disco mostrou a presença de 7 nós. O número de nós “surpreendentemente” coincidiu com o número de arquivos *-flat.vmdk detectados pelo VMFS Recovery:
Uma comparação entre tamanhos de arquivos e tamanhos de nós também mostrou uma correspondência até o byte. Ao mesmo tempo, os nomes dos arquivos *-flat.vmdk e, consequentemente, sua pertença às máquinas virtuais foram restaurados.
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 layout de disco “físico” (<nome da máquina>.vmdk). Se você fizer upload de um arquivo *-flat.vmdk para o Datastore de uma máquina local, o ESXi não o reconhecerá como um arquivo de disco válido. A Base de Conhecimento VMware possui um artigo sobre como criar manualmente um arquivo descritor de disco: , mas não precisei fazer isso, simplesmente copiei o conteúdo dos arquivos correspondentes da área de visualização do conteúdo do arquivo no DiskInternals VMFS Recovery:
Após 4 horas de descarregamento de um nó de 2,5 TB do UFS Explorer e 20 horas de carregamento no Datastore do hipervisor, os arquivos do disco travados foram conectados à máquina virtual recém-criada. Os discos pegaram. Nenhuma perda de dados foi observada.
Fonte: habr.com