Estratégia para backup e restauração em um ambiente agrupado

OBSERVAÇÃO

Se a implementação de formulários AEM armazenar dados personalizados adicionais em um banco de dados diferente, será necessário implementar uma estratégia para fazer backup desses dados, garantindo que eles permaneçam sincronizados com os dados de formulários AEM. Além disso, o aplicativo deve ser projetado de modo que seja robusto o suficiente para lidar com um cenário em que os bancos de dados adicionais fiquem fora de sincronia. É altamente recomendável que qualquer operação de banco de dados executada seja feita no contexto de uma transação para ajudar a manter um estado consistente.

É necessário fazer backup das seguintes partes do sistema de formulários AEM para recuperar-se de qualquer erro:

  • Banco de dados usado por formulários AEM
  • GDS com dados de longa duração e outros documentos persistentes
  • Banco de dados AEM (crx-repository)
OBSERVAÇÃO

É necessário fazer backup de quaisquer outros dados que estejam sendo usados pela configuração de formulários AEM, como fontes do cliente, dados do conector, etc.

Faça backup de um ambiente agrupado

Este tópico discute as seguintes estratégias para fazer backup de qualquer ambiente agrupado de formulários AEM:

  • Backup offline com tempo de inatividade
  • Backup offline sem tempo de inatividade (backup de um nó secundário que é desligado)
  • Backup on-line sem tempo de inatividade, mas atraso na resposta
  • Fazer backup do arquivo de propriedades do Bootstrap

Backup offline com tempo de inatividade

  1. Encerre todo o cluster e os serviços relacionados. (consulte Iniciar e parar serviços)

  2. Em qualquer nó, faça backup do banco de dados, GDS e Conectores. (consulte Arquivos para fazer backup e recuperar)

  3. Execute as seguintes etapas para fazer backup AEM repositório offline:

    1. Para cada nó de cluster, faça backup do arquivo que contém a id do nó de cluster.
    2. Faça backup de todos os arquivos de qualquer nó de cluster secundário, incluindo subdiretórios.
    3. Faça backup do repositório/ID do sistema de cada nó de cluster separadamente.

    Para obter etapas detalhadas, consulte Backup e restauração.

  4. Faça backup de quaisquer outros dados, como fontes do cliente.

  5. Start o cluster novamente.

Backup offline sem tempo de inatividade

  1. Insira o modo de backup em andamento. (consulte Entrando nos modos de backup)

    Observe que precisamos sair do modo de backup em andamento após uma recuperação.

  2. Desligue qualquer um dos nós secundários do cluster em relação à AEM. (consulte Iniciar e parar serviços)

  3. Em qualquer nó, faça backup do banco de dados, GDS e Conectores. (consulte Arquivos para fazer backup e recuperar)

  4. Execute as seguintes etapas para fazer backup AEM repositório offline:

    1. Para cada nó de cluster, faça backup do arquivo que contém a id do nó de cluster.
    2. Faça backup de todos os arquivos de qualquer nó de cluster secundário, incluindo subdiretórios.
    3. Faça backup repository/system.id de cada nó de cluster separadamente.

    Para obter etapas detalhadas, consulte Backup e restauração.

  5. Faça backup de quaisquer outros dados, como fontes do cliente.

  6. Start o cluster novamente.

Backup on-line sem tempo de inatividade, mas atraso na resposta

  1. Insira o modo de backup em andamento. (consulte Entrando nos modos de backup)

    Observe que é necessário sair do modo de backup em andamento após uma recuperação.

  2. Desligue qualquer um dos nós secundários do cluster em relação à AEM. (consulte Iniciar e parar serviços)

  3. Em qualquer nó, faça backup do banco de dados, GDS e Conectores. (consulte Arquivos para fazer backup e recuperar)

  4. Execute as seguintes etapas para fazer backup AEM repositório on-line:

    1. Para cada nó de cluster, faça backup do arquivo que contém o cluster_node.id.
    2. Faça backup repository/system.id de cada nó de cluster separadamente.
    3. Em qualquer nó secundário, faça um backup on-line do repositório para obter etapas detalhadas, consulte Backup on-line.

  5. Faça backup de quaisquer outros dados, como fontes do cliente.

  6. Start o cluster novamente.

Faça backup do arquivo de propriedades do Bootstrap

Quando criamos um cluster AEM, um arquivo de propriedades é criado no servidor de aplicativos para todos os nós secundários. É recomendável fazer backup do arquivo de propriedades do Bootstrap. Você pode encontrar o arquivo no seguinte local no servidor de aplicativos:

  • JBoss: no diretório BIN
  • WebLogic: no diretório de domínio
  • WebSphere: no diretório do perfil

É necessário fazer backup do arquivo para o cenário de recuperação de desastres AEM nó secundário e substituí-lo no local especificado no servidor de aplicativos, se restaurado.

Recuperação em um ambiente agrupado

Em caso de falha de todo o cluster ou de um único nó, é necessário restaurá-lo usando o backup.

Para uma recuperação de nó único, basta encerrar o nó único e executar o procedimento de recuperação de nó único.

Se o cluster inteiro falhar devido a falhas como falhas no banco de dados, é necessário executar as seguintes etapas. A restauração depende do método de backup usado.

Restaurar um único nó

  1. Pare o nó corrompido.

    OBSERVAÇÃO

    Se o nó corrompido for um nó primário AEM, desligue o nó de cluster inteiro.

  2. Recrie o sistema físico a partir de uma imagem do sistema.

  3. Aplique patches ou atualizações a formulários AEM que foram aplicados desde que a imagem foi feita. Essas informações foram registradas durante o procedimento de backup. AEM formulários devem ser recuperados para o mesmo nível de correção que no momento do backup do sistema.

  4. (Opcional) Se todos os outros nós estiverem funcionando bem, é possível que o repositório AEM também esteja corrompido. Nesse caso, você verá uma mensagem de não sincronização do repositório no arquivo error.log do repositório AEM.

    Para restaurar o repositório, execute as seguintes etapas.

    OBSERVAÇÃO

    Se um backup compactado do repositório crx foi colocado on-line, descompacte-o em qualquer local e siga o processo de restauração off-line.

    1. Exclua os diretórios de repositório, compartilhado, versão e espaços de trabalho no diretório clusterNode do nó.
    2. Restaure o backup do nó de cluster (incluindo subdiretórios) para o nó.
    3. Exclua o arquivo clusterNode/revision.log no nó.
    4. Exclua o .lock no nó, se houver.
    5. Exclua o diretório repository/system.id no nó, se houver.
    6. Exclua os arquivos **/listener.properties no nó, se houver.
    7. Restaure repository/cluster_node.id para nós de cluster individuais.
OBSERVAÇÃO

Considere os seguintes pontos:

  • Se o nó com falha for um nó primário AEM, copie todo o conteúdo da pasta do repositório secundário (crx-repository\crx.0000, onde 0000 pode ser qualquer dígito) para a pasta do repositório crx-repository\ e exclua a pasta do repositório secundário.
  • Antes de reiniciar qualquer nó de cluster, certifique-se de excluir o repositório /clustered.txt do nó primário.
  • Certifique-se de que o nó primário seja iniciado primeiro e depois de completamente ativado, start outros nós.

Restaurar todo o cluster

  1. Pare todos os nós do cluster.

  2. Recrie o sistema físico a partir de uma imagem do sistema.

  3. Aplique patches ou atualizações a formulários AEMAEM que foram aplicados desde que a imagem foi feita. Essas informações foram registradas na etapa 1 do procedimento de backup. AEM formulários devem ser recuperados para o mesmo nível de correção que no momento do backup do sistema.

  4. Restaure o banco de dados, GDS e Conectores.

  5. Faça o seguinte para recuperar o repositório AEM offline:

    OBSERVAÇÃO

    Se um backup compactado do repositório crx foi colocado on-line, descompacte-o em qualquer local e siga o processo de restauração off-line.

    1. Em todos os nós de cluster, exclua os diretórios de repositório, compartilhado, versão e espaços de trabalho no diretório clusterNode.
    2. Exclua todos os arquivos e diretórios no diretório compartilhado.
    3. Restaure o backup do nó de cluster (incluindo subdiretórios) para um nó de cluster.
    4. Copie todos os arquivos do nó de cluster restaurado para todos os outros nós de cluster. Depois de concluído, cada nó de cluster contém os mesmos dados.
    5. Exclua o arquivo clusterNode/revision.log em todos os nós de cluster.
    6. Exclua o .lock em todos os nós do cluster, se houver.
    7. Exclua repository/system.id todos os nós de cluster, se houver.
    8. Exclua os arquivos **/listener.properties em todos os nós de cluster, se houver.
    9. Restaure repository/cluster_node.id para nós de cluster individuais.
OBSERVAÇÃO

Considere os seguintes pontos:

  • Se o nó com falha for um nó primário AEM, copie todo o conteúdo da pasta do repositório secundário (parece crx-repository\crx.0000, onde 0000 pode ser qualquer dígito) para a pasta do repositório crx-repository.
  • Antes de reiniciar qualquer nó de cluster, certifique-se de excluir o repositório /clustered.txt do nó primário.
  • Certifique-se de que o nó primário seja iniciado primeiro e depois de completamente ativado, start outros nós.

Fazer backup e restaurar o nó de publicação da Solução de gerenciamento de correspondência

O nó do editor não tem nenhuma relação primário-secundário em um ambiente clusterizado. Você pode fazer backup de qualquer nó do Publisher seguindo Backup e restauração.

Recuperar um único nó do editor

  1. Desligue o nó que precisa ser recuperado e não faça nenhuma atividade de publicação até que o nó esteja ativo novamente.
  2. Restaure o nó Publicar usando [Restaurando o Backup] (https://docs.adobe.com/docs/en/crx/current/administering/backup_and_restore.html#Restoring o Backup).

Recuperar um cluster

  1. Desligue o cluster.
  2. Restaure o nó Publicar usando [Restaurando o Backup] (https://docs.adobe.com/docs/en/crx/current/administering/backup_and_restore.html#Restoring o Backup).
  3. Start o nó primário seguido pelo nó secundário do cluster do autor.

Nesta página