Um checkpoint do Avamar é um conjunto de diretórios somente leitura nos nós de dados do Avamar.
É como um snapshot point-in-time do sistema Avamar. Isso pode ser útil para fins de reversão caso o sistema Avamar tenha um problema grave que não possa ser corrigido.
A
ferramenta cplist cria uma lista de checkpoints que existem em um sistema Avamar.
A ferramenta pode ser executada por qualquer pessoa com acesso ao nó do utilitário Avamar.
Entender quais pontos de verificação existem e suas condições é essencial antes de tomar qualquer decisão sobre como proceder em um sistema que está enfrentando um problema ou que está passando por manutenção.
Suposições incorretas sobre o estado dos checkpoints podem resultar em perda de dados ou em um sistema Avamar irrecupeável.
Este artigo ajuda o leitor a interpretar a saída da ferramenta.
Aqui está um exemplo de resultado da lista de comando cplist.
cp.20130915110057 Sun Sep 15 12:00:57 2013 valid rol --- nodes 3/3 stripes 3530
cp.20130915110654 Sun Sep 15 12:06:54 2013 valid --- --- nodes 3/3 stripes 3530
Analisamos o primeiro checkpoint acima e discutimos o significado de cada campo de dados.
Nome da etiqueta de ponto de verificação - cp.20130915110057
- Esta é a etiqueta de identificação do checkpoint e corresponde ao horário em que o checkpoint foi iniciado. Cp. YYYYMMDDHHMMSS
- No Avamar v7.1, os checkpoints são atribuídos com números de série em vez de serem marcados com a data e a hora de início do checkpoint.
Tempo necessário - Domingo, 15 de setembro, 12:00:57
- O dia, a data e a hora em que o checkpoint foi criado. Isso sempre corresponderá à etiqueta de checkpoint.
Validade - válida
- Se esse campo mostrar "válido", o checkpoint será "saudável".
- A validade indica se o checkpoint é útil para fins de reversão.
- Se esse campo mostrar "válido", isso não significa que o checkpoint foi submetido à validação de verificação de HFScheck.
- O campo validity é superfluente ao executar "cplist", pois, por padrão, o comando mostra checkpoints utilizáveis.
- A execução de "cplist --full" mostrará todos os checkpoints no sistema, inclusive qualquer um que não seja utilizável para fins de reversão.
Tipo de validação de verificação de HFS - "rol"
- Este campo mostra o tipo de validação de verificação de HFS que foi executado no checkpoint.
- Os tipos possíveis são "hfs", "rdc", "par", "rol"
- hfs ou full - significa que a validação foi executada em todas as faixas no checkpoint.
- roll — significa que a validação verificou todas as faixas novas ou modificadas no checkpoint.
- Uma pesquisa mostrou que, quando ocorrem problemas de integridade dos dados, geralmente as frações afetadas são aquelas recém-criadas ou modificadas recentemente. Por esse motivo, a engenharia do Avamar recomenda que a validação contínua seja considerada praticamente tão confiável quanto uma validação de verificação de HFScheck completa mais longa.
- Dependendo da taxa de inclusão de dados do sistema Avamar, uma verificação contínua de HFScheck também pode verificar uma proporção das frações não modificados de um checkpoint. Isso significa que, eventualmente, todas as faixas, mesmo aquelas que não foram modificadas, podem ser verificadas de integridade.
- rdc - significa que a validação foi concluída, mas que um nó não participou da validação. O tipo de validação não é especificado.
- A integridade dos dados não pode ser garantida para checkpoints marcados como rdc. Essa verificação oferece mais confiança na integridade dos dados do que nenhuma validação.
"---"
- Este campo indica se o checkpoint pode ser excluído, de acordo com as configurações de retenção de checkpoint em vigor no servidor Avamar.
- A retenção de checkpoint é controlada pelos parâmetros "cphfschecked" e "cpmostrecent".
- A retenção de checkpoint deve ser deixada como padrão, a menos que seja aconselhada por um engenheiro de suporte.
- Configurações incorretas de retenção de checkpoint podem colocar um sistema Avamar em risco de perda de dados ou podem causar problemas de capacidade do sistema operacional.
REFCOUNT/NODECOUNT - "nó 3/3"
- O primeiro número é o refcount. Isso relata o número de nós que responderam ao comando cplist. Esse valor não significa necessariamente o número de nós que estão on-line.
- O segundo número é o nodecount. Isso se refere ao número de nós que participaram quando o checkpoint foi originalmente obtido. Em outras palavras, quantos nós de dados contêm esse diretório de checkpoint específico.
- Observe cuidadosamente o estado do sistema (número total de nós e número de nós on-line) e como a cplist foi executada, antes de considerar o significado do resultado desses dois campos.
Campo de contagem de fração - "3530"
- Este campo exibe o número total de frações capturadas no checkpoint.
- Uma validação de checkpoint contínuo valida um subconjunto desse número de faixas.
- Uma validação completa de checkpoint valida todos eles.
Exemplos de resultado da cplist
Exemplo 1:
cp.20130914190119 Sat Sep 14 20:01:19 2013 valid rol --- nodes 1/1 stripes 1401
cp.20130914192153 Sat Sep 14 20:21:53 2013 valid --- --- nodes 1/1 stripes 1401
O que isso nos diz?
- Este é um sistema de único nó.
- Há dois pontos de verificação "inteiros" ou utilizáveis.
- cp.20130914190119 foi validado com uma verificação HFScheck contínua; o outro checkpoint não foi validado.
- Ambos os checkpoints capturaram 1401 frações.
Exemplo 2:
cp.20130911150620 Wed Sep 11 11:06:20 2013 valid rol --- nodes 9/9 stripes 121107
cp.20130911160421 Wed Sep 11 12:04:21 2013 valid --- --- nodes 9/9 stripes 121107
cp.20130912151051 Thu Sep 12 11:10:51 2013 valid --- --- nodes 8/9 stripes 121107
O que isso nos diz?
- Durante cada checkpoint, nove nós participaram do processo de criação do checkpoint. Podemos supor que há nove nós no sistema, mas não depende exclusivamente do resultado da lista de cplist para essas informações.
- O mais antigo dos três checkpoints foi validado com uma verificação contínua de HFS.
- No momento, os checkpoints mais recentes (12 de setembro) estão inacessíveis em um dos nove nós que formam esse checkpoint.
Exemplo 3:
cp.20130915110057 Sun Sep 15 12:00:57 2013 valid rol --- nodes 3/3 stripes 3530
cp.20130915110654 Sun Sep 15 12:06:54 2013 valid --- del nodes 3/3 stripes 3530
cp.20130916053830 Mon Sep 16 06:38:30 2013 valid --- --- nodes 3/3 stripes 3530
cp.20130916060236 Mon Sep 16 07:02:36 2013 valid --- --- nodes 2/2 stripes 3530
O que isso nos diz?
- cp.20130915110654 é elegível para ser excluído de acordo com as regras de retenção de checkpoint.
- cp.20130916060236 foi obtido enquanto um dos três nós estava off-line.
Exemplo 4:
Se um sistema Avamar estiver integrado ao Data Domain, a cplist poderá mostrar checkpoints como inválidos se o sistema Data Domain ficar indisponível. Por exemplo,
cp.20130830173413 Fri Aug 30 10:34:13 2013 valid hfs --- nodes 1/1 stripes 82
cp.20130831000113 Fri Aug 30 17:01:13 2013 valid hfs --- nodes 1/1 stripes 82
Se o dispositivo Data Domain estiver desligado;
admin@utility:~/>: cplist
cplist: ERROR: ddrmaint: <4750>Datadomain get checkpoint list operation failed.
2013/09/17-14:28:06.79970 [cplist] ERROR: <0001> ddrmaint: <4750>Datadomain get checkpoint list operation failed.
cp.20130830173413 Fri Aug 30 10:34:13 2013 invalid --- --- nodes 1/1 stripes 82
cp.20130831000113 Fri Aug 30 17:01:13 2013 invalid --- --- nodes 1/1 stripes 82