Estratégia de backup e restauração em um ambiente em cluster strategy-for-backup-and-restore-in-a-clustered-environment
Você precisa fazer backup das seguintes partes do sistema de formulários AEM para se recuperar de qualquer erro:
- Banco de dados usado por formulários AEM
- GDS com dados de longa vida e outros documentos persistentes
- Banco de dados AEM (crx-repository)
Fazer backup de um ambiente em cluster back-up-a-clustered-environment
Este tópico discute as seguintes estratégias para fazer backup de qualquer ambiente em cluster de formulários AEM:
- Backup off-line com tempo de inatividade
- Backup off-line sem tempo de inatividade (backup de um nó secundário que está desligado)
- Backup on-line sem tempo de inatividade, mas com atraso na resposta
- Faça backup do arquivo de propriedades do Bootstrap
Backup off-line com tempo de inatividade offline-backup-with-downtime
-
Desligue todo o cluster e os serviços relacionados. (consulte Iniciando e interrompendo serviços)
-
Em qualquer nó, faça backup do banco de dados, do GDS e dos Conectores. (consulte Arquivos para fazer backup e recuperar)
-
Para fazer backup do repositório AEM off-line, execute as seguintes etapas:
- Para cada nó de cluster, faça backup do arquivo que contém a ID do nó de cluster.
- Faça backup de todos os arquivos de qualquer nó de cluster secundário, incluindo subdiretórios.
- Faça backup do repositório/ID do sistema de cada nó de cluster separadamente.
Para obter etapas detalhadas, consulte Backup e restauração.
-
Faça backup de todos os outros dados, como fontes de clientes.
-
Inicie o cluster novamente.
Backup off-line sem tempo de inatividade offline-backup-with-no-downtime
-
Entre no modo de backup contínuo. (consulte Entrando nos modos de backup)
Sair do modo de backup contínuo após uma recuperação.
-
Desligue qualquer um dos nós secundários do cluster em relação ao AEM. (consulte Iniciando e interrompendo serviços)
-
Em qualquer nó, faça backup do banco de dados, do GDS e dos Conectores. (consulte Arquivos para fazer backup e recuperar)
-
Para fazer backup do repositório AEM off-line, execute as seguintes etapas:
- Para cada nó de cluster, faça backup do arquivo que contém a ID do nó de cluster.
- Faça backup de todos os arquivos de qualquer nó de cluster secundário, incluindo subdiretórios.
- Faça backup do repository/system.id de cada nó de cluster separadamente.
Para obter etapas detalhadas, consulte Backup e restauração.
-
Faça backup de todos os outros dados, como fontes de clientes.
-
Inicie o cluster novamente.
Backup on-line sem tempo de inatividade, mas com atraso na resposta online-backup-with-no-downtime-but-delay-in-response
-
Entre no modo de backup contínuo. (consulte Entrando nos modos de backup)
Sair do modo de backup contínuo após uma recuperação.
-
Desligue qualquer um dos nós secundários do cluster em relação ao AEM. (consulte Iniciando e interrompendo serviços)
-
Em qualquer nó, faça backup do banco de dados, do GDS e dos Conectores. (consulte Arquivos para fazer backup e recuperar)
-
Para fazer backup do repositório AEM on-line, execute as seguintes etapas:
- Para cada nó de cluster, faça backup do arquivo que contém o cluster_node.id.
- Faça backup do repository/system.id de cada nó de cluster separadamente.
- Em qualquer nó secundário, faça um backup on-line do repositório. Para obter etapas detalhadas, consulte Backup on-line.
-
Faça backup de todos os outros dados, como fontes de clientes.
-
Inicie o cluster novamente.
Faça backup do arquivo de propriedades do Bootstrap back-up-the-bootstrap-properties-file
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
Faça backup do arquivo para o cenário de recuperação de desastres do nó secundário AEM e substitua-o no local especificado no servidor de aplicativos, se restaurado.
Recuperação em um ambiente em cluster recovery-in-a-clustered-environment
Se houver qualquer falha do cluster inteiro ou de um único nó, restaure-o usando o backup.
Para uma recuperação de um único nó, desative o único nó e execute o procedimento de recuperação de um único nó.
Caso todo o cluster falhe devido a falhas como falha no banco de dados, execute as etapas a seguir. A restauração depende do método de backup usado.
Restauração de um único nó restoring-a-single-node
-
Interrompa o nó corrompido.
note note NOTE Se o nó corrompido for um nó primário AEM, desative todo o nó do cluster. -
Recrie o sistema físico a partir de uma imagem do sistema.
-
Aplique patches ou atualizações aos formulários AEM que foram aplicados desde que a imagem foi criada. Essas informações foram registradas durante o procedimento de backup. Os formulários AEM devem ser recuperados no mesmo nível de patch que tinham quando foi feito o backup do sistema.
-
(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 dessincronização do repositório no arquivo error.log do repositório AEM.
Para restaurar o repositório, execute as etapas a seguir.
note note NOTE Se um backup de repositório crx compactado foi colocado online, descompacte-o em qualquer local e siga o processo de restauração offline. - Exclua os diretórios de repositório, compartilhado, versão e espaços de trabalho no diretório clusterNode do nó.
- Restaure o backup do nó de cluster (incluindo subdiretórios) para o nó.
- Exclua o arquivo clusterNode/revision.log no nó.
- Exclua o arquivo .lock no nó, se existir.
- Exclua o repository/system.id no nó, se existir.
- Exclua os arquivos **/listener.properties no nó, se existir.
- Restaure repository/cluster_node.id para nós de cluster individuais.
- Se o nó com falha era um nó primário AEM, copie todo o conteúdo da pasta do repositório secundário (crx-repository\crx.0000, onde 0000 pode conter 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 ativado, inicie os outros nós.
Restaurando todo o cluster restoring-the-entire-cluster
-
Interrompa todos os nós de cluster.
-
Recrie o sistema físico a partir de uma imagem do sistema.
-
Aplique patches ou atualizações aos formulários AEM AEM que foram aplicados desde que a imagem foi criada. Essas informações foram registradas na etapa 1 do procedimento de backup. Os formulários AEM devem ser recuperados no mesmo nível de patch que tinham quando foi feito o backup do sistema.
-
Restaure o banco de dados, o GDS e os Conectores.
-
Faça o seguinte para recuperar o repositório AEM off-line:
note note NOTE Se um backup de repositório crx compactado foi colocado online, descompacte-o em qualquer local e siga o processo de restauração offline. - 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.
- Exclua todos os arquivos e diretórios no diretório compartilhado.
- Restaure o backup do nó de cluster (incluindo subdiretórios) para um nó de cluster.
- 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.
- Exclua o arquivo clusterNode/revision.log em todos os nós de cluster.
- Exclua o .lock em todos os nós de cluster, se existir.
- Exclua os nós de cluster repository/system.id, se existirem.
- Exclua os arquivos **/listener.properties em todos os nós do cluster, se existirem.
- Restaure repository/cluster_node.id para nós de cluster individuais.
- Se o nó com falha era um nó primário AEM, copie todo o conteúdo da pasta do repositório secundário (parece crx-repository\crx.0000, em que 0000 pode conter 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 ativado, inicie os outros nós.
Fazer backup e restaurar nó de publicação da Solução de gerenciamento de correspondência back-up-and-restore-correspondence-management-solution-publish-node
O nó publicador não tem nenhuma relação primário-secundário em um ambiente clusterizado. Você pode fazer backup de qualquer nó do Editor seguindo Backup e Restauração.
Recuperar um único nó de editor recover-a-single-publisher-node
- Desligue o nó que deve ser recuperado e não faça nenhuma atividade de publicação até que o nó esteja ativo novamente.
- Restaure o nó Publish usando Restaurando o Backup.
Recuperar um cluster recover-a-cluster
- Desligue o cluster.
- Restaure o nó Publish usando Restaurando o Backup.
- Inicie o nó primário seguido pelo nó secundário do cluster do autor.