Ignorar Links de Navegao | |
Sair do Modo de Exibio de Impresso | |
![]() |
Guia de administração do ZFS Oracle Solaris |
1. Sistema de arquivos Oracle Solaris ZFS (introdução)
2. Introdução ao ZFS do Oracle Solaris
3. Diferenças entre o sistema de arquivos tradicional e o ZFS do Oracle Solaris
4. Gerenciando conjuntos de armazenamento ZFS do Oracle Solaris
5. Instalando e inicializando um sistema de arquivos raiz ZFS do Oracle Solaris
6. Gerenciando sistemas de arquivos ZFS do Oracle Solaris
7. Trabalhando com instantâneos e clones do ZFS do Oracle Solaris
8. Uso de ACLs e atributos para proteger arquivos ZFS do Oracle Solaris
9. Administração delegada do ZFS do Oracle Solaris
10. Tópicos avançados do ZFS do Oracle Solaris
11. Solução de problemas e conjunto de recuperação do Oracle Solaris ZFS
Ausência de dispositivos em um pool de armazenamento do ZFS
Dispositivos danificados em um pool de armazenamento do ZFS
Verificando a integridade do sistema de arquivos ZFS
Validação do sistema de arquivos
Controlando o scrubbing de dados do ZFS
Scrubbing explícito de dados do ZFS
Scrubbing e resilvering de dados do ZFS
Resolvendo problemas com o ZFS
Determinando se há problemas em um conjunto de armazenamento do ZFS
Revisando a saída de zpool status
Informações gerais sobre o status do pool
Informações sobre a configuração do pool
Relatório de mensagens de erros do ZFS do sistema
Reparando uma configuração do ZFS danificada
Reparando um dispositivo faltando
Reanexando fisicamente um dispositivo
Notificando o ZFS da disponibilidade de um dispositivo
Substituindo ou reparando um dispositivo modificado
Determinando o tipo de falha do dispositivo
Substituindo um dispositivo em um pool de armazenamento do ZFS
Determinando se um dispositivo pode ser substituído
Dispositivos que não podem ser substituídos
Substituindo um dispositivo em um pool de armazenamento do ZFS
Exibindo o status do resilvering
Reparando um sistema não inicializável
As seções seguintes descrevem como identificar o tipo de corrupção de dados e como reparar os dados, se possível.
O ZFS utiliza a soma de verificação, redundância e autocorreção de dados para minimizar o risco de corrupção de dados. Por outro lado, a corrupção de dados pode ocorrer se um conjunto não é redundante, se a corrupção ocorreu enquanto um conjunto foi degradado ou uma série de eventos conspirados para corromper cópias múltiplas de uma parte dos dados. Em relação à origem, o resultado é o mesmo: Os dados estão corrompidos e, portanto, não podem ser acessados. A ação tomada depende do tipo de dados que estão corrompidos e de seu valor relativo. Podem ser corrompidos dois tipos básicos de dados:
Metadados do pool – O ZFS requer uma determinada quantidade de dados a ser processada para abrir um pool e acessar os conjuntos de dados. Se esses dados estão corrompidos, todo o conjunto ou parte do conjunto de dados se tornará indisponível.
Dados do objeto – Neste caso, a corrupção está dentro de um arquivo ou um diretório específico. Este problema pode fazer com que uma parte do arquivo ou diretório não possa ser acessada ou que o objeto fique totalmente danificado.
Os dados são verificados durante operações normais bem como através de um scrubbing. Para informações sobre como verificar a integridade do conjunto de dados, consulte Verificando a integridade do sistema de arquivos ZFS.
Por padrão, o comando zpool status mostra somente que ocorreu uma corrupção, mas não mostra onde esta corrupção ocorreu. Por exemplo:
# zpool status monkey pool: monkey state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed after 0h0m with 8 errors on Tue Jul 13 13:17:32 2010 config: NAME STATE READ WRITE CKSUM monkey ONLINE 8 0 0 c1t1d0 ONLINE 2 0 0 c2t5d0 ONLINE 6 0 0 errors: 8 data errors, use '-v' for a list
Cada erro indica somente que um erro ocorreu em um dado momento. Os erros não estão necessariamente presentes no sistema até este momento. Sob circunstâncias normais, esse é o caso. Certas interrupções podem resultar em corrupção de dados que são automaticamente reparados depois que a interrupção acaba. É realizado um scrubbing completo do pool a fim de examinar todos os blocos ativos no pool, assim o registro do erro é redefinido sempre que o scrubbing terminar. Se detectar que os erros já não estão presentes e não quiser esperar a conclusão do scrubbing, redefina todos os erros no pool com o comando zpool online.
Se a corrupção de dados estiver nos metadados de todo o pool, a saída é um pouco diferente. Por exemplo:
# zpool status -v morpheus pool: morpheus id: 1422736890544688191 state: FAULTED status: The pool metadata is corrupted. action: The pool cannot be imported due to damaged devices or data. see: http://www.sun.com/msg/ZFS-8000-72 config: morpheus FAULTED corrupted data c1t10d0 ONLINE
No caso de corrupção de conjunto extenso, o conjunto é colocado em estado FAULTED porque o conjunto não pode fornecer o nível requerido de redundância.
Se um arquivo ou diretório está corrompido, o sistema ainda pode funcionar, dependendo do tipo de corrupção. Qualquer dano é efetivamente irrecuperável se não há nenhuma cópia boa de dados no sistema. Se os dados estão disponíveis, é preciso restaurar os dados afetados do backup. Mesmo assim, é possível recuperar essa corrupção sem ter que restaurar todo o pool.
Se o dano for dentro de um bloco de dados do arquivo, então o arquivo pode ser seguramente removido, eliminado o erro do sistema. Utilize o comando zpool status -v para exibir uma lista de nomes de arquivos com erros persistentes. Por exemplo:
# zpool status -v pool: monkey state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed after 0h0m with 8 errors on Tue Jul 13 13:17:32 2010 config: NAME STATE READ WRITE CKSUM monkey ONLINE 8 0 0 c1t1d0 ONLINE 2 0 0 c2t5d0 ONLINE 6 0 0 errors: Permanent errors have been detected in the following files: /monkey/a.txt /monkey/bananas/b.txt /monkey/sub/dir/d.txt monkey/ghost/e.txt /monkey/ghost/boo/f.txt
A lista de nomes de arquivos com erros persistentes devem ser descritos como os seguintes:
Se o caminho completo do arquivo for encontrado e o conjunto de dados estiver montado, o caminho completo do arquivo é exibido. Por exemplo:
/monkey/a.txt
Se o caminho completo do arquivo for encontrado, mas o conjunto de dados não estiver montado, então o nome do conjunto de dados é exibido sem a barra (/) precedente, seguido do caminho dentro do conjunto de dados do arquivo. Por exemplo:
monkey/ghost/e.txt
Se o número do objeto não puder ser traduzido com sucesso para o caminho do arquivo, devido a um erro ou a que o objeto não possui um caminho de arquivo verdadeiro associado a ele, como é o caso de dnode_t, então o nome do conjunto de dados seguido do número do objeto é exibido. Por exemplo:
monkey/dnode:<0x0>
Se um objeto no metaobject set (MOS) está corrompido, então uma marcação especial de <metadata>, seguida pelo número do objeto, é exibida.
Se a corrupção estiver dentro dos metadados de um arquivo ou diretório, a única opção é mover os arquivos para outro local. É possível mover seguramente qualquer arquivo ou diretório para um local menos conveniente, permitindo que o objeto original seja restaurado em seu lugar.
Se o dano está nos metadados do pool e o dano impede que o conjunto seja aberto ou importado, então as opções a seguir estão disponíveis para você:
Você pode tentar recuperar o pool usando o comando zpool clear -F ou o comando zpool import - F. Esses comandos tentam retornar as poucas últimas transações do conjunto para o estado operacional. É possível utilizar o comando zpool status para rever um conjunto danificado e as etapas de recuperação recomendadas. Por exemplo:
# zpool status pool: tpool state: FAULTED status: The pool metadata is corrupted and the pool cannot be opened. action: Recovery is possible, but will result in some data loss. Returning the pool to its state as of Wed Jul 14 11:44:10 2010 should correct the problem. Approximately 5 seconds of data must be discarded, irreversibly. Recovery can be attempted by executing 'zpool clear -F tpool'. A scrub of the pool is strongly recommended after recovery. see: http://www.sun.com/msg/ZFS-8000-72 scrub: none requested config: NAME STATE READ WRITE CKSUM tpool FAULTED 0 0 1 corrupted data c1t1d0 ONLINE 0 0 2 c1t3d0 ONLINE 0 0 4
O processo de recuperação, conforme descrito na saída anterior, deve usar o seguinte comando:
# zpool clear -F tpool
Se você tentar importar um conjunto de armazenamento danificado, irá visualizar mensagens similares as seguintes:
# zpool import tpool cannot import 'tpool': I/O error Recovery is possible, but will result in some data loss. Returning the pool to its state as of Wed Jul 14 11:44:10 2010 should correct the problem. Approximately 5 seconds of data must be discarded, irreversibly. Recovery can be attempted by executing 'zpool import -F tpool'. A scrub of the pool is strongly recommended after recovery.
O processo de recuperação, conforme descrito na saída anterior, deve usar o seguinte comando:
# zpool import -F tpool Pool tpool returned to its state as of Wed Jul 14 11:44:10 2010. Discarded approximately 5 seconds of transactions
Se o conjunto danificado está no arquivo zpool cache, o problema é descoberto quando o sistema é inicializado e o conjunto danificado é reportado no comando zpool status. Se o pool não estiver no arquivo zpool cache, ele não será importado nem aberto com sucesso, e você verá mensagens de pools danificados quando tentar importar o pool.
Você pode importar um pool danificado no modo somente leitura. Este método permite importar o pool de forma que você possa acessar os dados. Por exemplo:
# zpool import -o readonly=on tpool
Para obter mais informações sobre a importação de um pool somente leitura, consulte Importação de um pool no modo somente leitura.
Você pode importar um pool com um dispositivo de log ausente usando o comando zpool import -m. Para obter mais informações, consulte Importação de um pool com um dispositivo de log ausente.
Se o pool não pode ser recuperado pelo método de recuperação do pool, você deverá restaurar o pool e todos os seus dados de uma cópia de backup. O mecanismo utilizado varia amplamente dependendo da configuração do conjunto e da estratégia de backup. Primeiro, salve a configuração como exibida pelo comando zpool status, assim é possível recriá-la depois que o pool for destruído. Então, utilize o comando zpool destroy -f para destruir o conjunto.
Mantenha também, em um lugar seguro, um arquivo que descreva o layout dos conjuntos de dados e as diversas propriedades de conjunto, já que estas informações não poderão ser acessadas se o pool não puder ser acessado. Com a configuração do pool e o layout do conjunto de dados, você pode reconstruir a configuração completa depois de destruir o pool. Os dados podem, então, ser preenchidos usando o backup ou a estratégia de restauração de sua preferência.