Recuperação de Sistema de Arquivos Oracle ZFS | OpenZFS

A Hosco Tecnologia possui soluções seguras, modernas e eficientes para recuperação de ZFS (recuperação de dados em ZFS), tendo histórico exclusivo de êxito em cenários complexos, principalmente, quando esse sistema de arquivos torna-se inacessível por causa de danos físicos.

Em 2006, a empresa teve seu primeiro caso de recuperação de ZFS corrompido. Logo, passou a desenvolver seus softwares e procedimentos para recuperar pools, datasets e volumes, ZFS, tornando-se referência nacional nessa categoria de serviço.

As ações devidamente planejadas, e minimamente invasivas, resultam em elevados índices de recuperação positiva.

Sinta-se à vontade para falar conosco. Caso já esteja certo da qualidade dos serviços prestados pela Hosco Tecnologia, solicite atendimento.

Conceito

Recuperação de ZFS (recuperação de dados em ZFS) é o nome dado aos procedimentos adotados por pessoal capacitado, e devidamente munido de equipamentos, para recuperar dados alocados em dispositivos de armazenamento que contém sistema de arquivos ZFS (pool, zvol ou qualquer dataset). Em inglês, os termos equivalentes mais usados são ZFS repair e ZFS data recovery.

O sistema de arquivos ZFS teve seu projeto iniciado em 2001, por uma equipe da Sun Microsystems liderada pelo renomado desenvolvedor Jeff Bonwick. No início, foi chamado de Zettabyte File System, mas logo perdeu este significado, deixando de ser um acrônimo. O ZFS foi lançado no ano de 2005, em uma das subversões do sistema proprietário Solaris 10. Ele agregou elementos importantes para o universo do armazenamento de dados em grande escala.

Principais Características do ZFS

  • 128 bit de endereçamento, o qual permite alocar um enorme volume de dados
  • Combinação de sistema de arquivo com gerenciador de volume em única camada
  • Agilidade operacional, com criação rápida de filesystem, volume, RAID e LUN
  • Otimização de espaço, através de blocos com tamanho variável e compactação
  • Alocação e escrita de blocos com tecnologia transacional Copy-On-Write (COW)
  • Elevada capacidade de autorecuperação e autoreparo sem intervenção externa
  • Snapshots instantâneos ilimitados, clones e replicações (locais ou remotos)
  • Volumes em Striping (distribuídos), Mirroring (espelhamento) e RAID (RAID-Z)

Entre 2005 e 2009, o desenvolvimento do ZFS ocorria era dentro do projeto OpenSolaris (baseado em código aberto). Neste período foram criados ports para Linux (através de FUSE), FreeBSD e Mac OS X. Em 2010, durante o processo de aquisição da Sun pela Oracle®, o seu código tornou-se proprietário e o OpenSolaris foi encerrado. Em 2013, é criado o OpenZFS, um projeto com modelo de desenvolvimento comunitário, que reúne implementações (illumos, FreeBSD, ZFS on Linux e OpenZFS on OS X) open-source do ZFS original.

O algoritmo de gestão de erros do ZFS oferece alta resiliência e uma sofisticada capacidade de recuperação instantânea (self-healing), sendo muito eficaz no tratamento de erros causados por crashes ou interrupção abrupta de energia. O reparo de arquivos em um pool ZFS (zpool), ou no próprio dataset (sistema de arquivos, volumes, clones e snapshots), é automático e transparente para seus usuários.

O ZFS foi desenvolvido de modo a detectar e responder com eficácia a erros de disco, falhas de I/O e inconsistências. Portanto, ao ser identificado um bloco defeituoso, imediatamente, ele é substituído por seu par redundante contido, na maioria das vezes, em outro dispositivo ou partição dentro do mesmo pool. Para cada novo bloco criado, gera-se o respectivo checksum (fletcher-4 ou sha-256) que é gravado em uma área de meta informações (usada para checagem de integridade). Quando a leitura de um bloco é solicitada, também há geração de um hash o qual é comparado com seu checksum original; havendo divergência entre os hashes, o sistema busca o primeiro bloco redundante para substituir aquele está corrompido e corrigir o problema, mantendo a integridade dos dados.

A tecnologia copy-on-write foi criada para otimizar programas, através de um melhor gerenciamento de recursos e operações de escrita. Ela foi integrada ao ZFS para reduzir requisições de entrada e saída (I/O), diminuir índices duplicados e aumentar a redundância em nível de arquivos.

As rotinas de auto reparo do ZFS têm se mostrado fundamentais para prover alta disponibilidade de armazenamento, estimulando fabricantes e desenvolvedores a inserí-lo em plataformas modernas de storage NAS (FreeNAS, NexentaStor, OpenMediaVault, etc.), e produtos ainda mais completos que também suportam arquitetura SAN (Storage Area Network), como os appliances ZFS Storage ZS5-2 e Fire X4540. Elas garantem o funcionamento de serviços críticos, mesmo após graves falhas de hardware. Ainda assim, se tais eventos passarem despercebidos e os dispositivos danificados não forem substituídos, o ambiente poderá entrar em colapso. Portanto, é fundamental monitoração ativa dos discos que compõe uma arquitetura com ZFS.

Indepente da capacidade de auto reparo do ZFS, todo vdev (HD, SSD, etc.) defeituoso deve ser rapidamente desativado e substituído, mesmo que seja necessário interromper o servidor. Pools que operam muito tempo em modo degradado, podem sofrer perda definitiva do seu conteúdo, ocasionada pela realocação forçada de setores (em nível de firmware), corrupção de metadados, etc.

A possibilidade de snapshots, clones, espelhamentos, duplicações, entre outras qualidades, fazem do ZFS mais resiliente e, ainda, permite melhoes respostas perante desastres computacionais. Porém, qualquer sistema de arquivos está sujeito a falhas de hardware, ações humanas indevidas e eventuais acidentes, que geram paralisação de um servidor ou perda de dados, podendo levar a prejuízos significativos.

Orientação para Gestores de Sistema ZFS Danificado

ESTADO

VDEV DE SPARE

RECOMENDAÇÃO

Degradado, mas operante

presente

monitorar e aguardar reconstrução do pool

Degradado, mas operante

ausente

substituir vdevs degrados e aguardar reconstrução

Indisponível (inoperante)

presente|ausente

Imediatamente, desativar o pool e manter seus vdevs desligados. EM NEHUMA HIPÓTESE tentar manipular ou exportar (zpool export) qualquer elemento do dataset. Consultar empresa de recuperação ZFS

Serviço de Recuperação de Dados em ZFS


Arquiteturas Recuperadas

Plataformas Recuperadas

A Hosco Tecnologia continua sendo a primeira empresa brasileira a oferecer recuperação ZFS de modo profissional. Sua equipe tem duas décadas de experiência real (implementação, administração e proteção) em servidores Unix, e também dispõe dos melhores equipamentos de recuperação. As ações são realizadas de modo consciente (procedimentos corretos, com algoritmo eficiente) e seguro (preservação de datasets e da organização dos dados). Essas qualidades refetem diretamente nos excelentes resultados em reparar dados perdidos de ZFS, proporcionando diversos casos comprovados de sucesso.

O primeiro contato da Hosco Tecnologia com ZFS ocorreu em 2005, em virtude da necessidade de migração do filesystem de seu storage NAS (Linux Debian), por questões de escalabilidade. Contudo, tal ação ficou inviável porque a única implementação GNU/Linux ZFS (ZFS-FUSE) ainda estava em fase alpha. O problema foi resolvido com a instalação e migração para um Unix Solaris 10. Um ano depois, ocorreu a primeira recuperação em ZFS: reparar um zvol (dispositivo de bloco virtual) que ficou inacessível porque um dos HDs apresentou problemas. Naquele tempo a documentação era quase toda restrita ao site da Oracle®, principalmente para utilização do zdb. Consequentemente, houve um processo longo de tentativa e erro, mas que agregou conhecimento e experiência para a equipe.

É essencial muita experiência com ZFS para criar um algoritmo eficaz de recuperação de dados, sendo requerimentos básicos: o pleno entendimento do controle de operações de read/write (registrado por logs transacionais) e da forma como blocos de dados são validados (conferência de checksums organizados em merkle4). Uma simples recuperação de HD ZFS danificado pode exigir centenas de linhas de comandos pré programadas. Portanto, os procedimentos de reconstrução dos pools, zvols e mirrors são complexos, feitos manualmente por profissionais que têm ampla experiência com essa tecnologia.

Com o lançamento do Solaris 11, o código fonte do ZFS - que estava na versão 28 - ficou proprietário e fechado. Em 2013, as implementações livres do ZFS (Linux port, MacZFS, FreeBSD port, etc.) passaram a se reunir em um único projeto chamado OpenZFS. Atualmente, há o ZFS original (desenvolvido pela Oracle) e seu fork OpenZFS (desenvolvido por diversos colaboradores e apoiado por várias empresas). Ambos têm o mesmo core baseado na versão 28, mas com o decorrer dos anos passam ter melhorias e recursos diferentes. Sendo implementações diferentes, o modo de acesso e as ferramentas de administração e gerenciamento são distintas, ocasionando diferenças entre os processos de recuperação de arquivos em ZFS e OpenZFS.

A análise de histórico é uma das primeiras rotinas da recuperação ZFS. Quanto mais intacto estiver o Volume, Pool ou RAID-Z, maior probabilidade de sucesso e menor custo. Por outro lado, storages que sofreram tentativas forçadas de importação, resilvering e uso do scrub (uma espécie de fsck para o ZFS), tendem a uma recuperação mais difícil e onerosa. Cabe também lembrar que forçar operações em um volume que já está indisponível, adiciona mais danos a estrutura comprometida, sendo necessário incluir uma longa etapa de restruturação lógica durante o trabalho de recuperação.

A grande quantidade de recursos oferecidos e as peculiaridades inerentes ao ZFS (alocação variável de blocos e indexação de seus respectivos arquivos), exigem prudência do expert que cuidará da resposta ao incidente e do reparo de todo dataset. Aqueles que buscam soluções para recuperação em ZFS, precisam ter ciência que qualquer tentativa executada por pessoal não especializado, poderá resultar na perda definitiva dos dados, restando apenas a possibilidade de tentar alguma reparação judicial de quem cometeu o ato de imperícia e/ou imprudência.

Arquiteturas de armazenamento complexas precisam de supervisão constante. Por mais moderna que seja, nenhuma tecnologia é infalível. Fatalidades ou erros humanos levam muitas empresas a utilizar a recuperação emergencial como a única forma de atenuar desastres ocorridos em sistemas com ZFS. Na maioria dos casos, essas empresas recorrem a Hosco Tecnologia.


Estado Operacional de Elementos ZFS



ONLINE: Todos os vdevs (dispositivos) estão funcionando corretamente

OFFLINE: Um ou mais vdevs (dispositivos) foram removidos manualmente

REMOVED: Vdev que é removido durante o funcionamento de um storage ZFS

UNAVAIL: Determinado Vdev de Pool ou RAID-Z que não pode ser acessado

DEGRADED: Zpool ou RAID-Z, operacional, mas com vdev(s) danificado(s)

FAULTED: Qualquer componente ZFS (vdev, zpool, zvol e RAID-Z) inacessível




Top