Um pouco mais longo, um pouco mais barato · Economize 28% por 6 meses ou 50% por um ano, pagos uma vez Ver os planos ↗

Recuperação · 5 min de leitura

Ensaiar a recuperação da sua wiki compartilhada.

Restaure um serviço completo em um ambiente separado e controlado e verifique o que seus usuários precisam fazer. Mantenha o serviço original intacto, impeça que a cópia de teste contate usuários reais e anote as falhas com o mesmo cuidado que os passos bem-sucedidos.

Antes de começar

  • Um inventário de serviço concluído e permissão para lidar com os dados de backup dele.
  • Um conjunto de backup selecionado, seu carimbo de data/hora, versões de software e acesso autorizado aos segredos de recuperação.
  • Um destino separado com espaço suficiente e controles de acesso para as informações restauradas.
  • Duas contas testemunhas inofensivas com permissões diferentes, além de uma página e um anexo conhecidos.
  • Um responsável pelo teste nomeado e outro mantenedor que possa revisar o resultado.

Decida o que contaria como um caderno funcional

Use o wiki de oficina ilustrativo do inventário de serviços. Seus critérios de sucesso são específicos: um editor consegue encontrar e alterar uma página de teste, um leitor consegue visualizar instruções permitidas, um livro organizador privado permanece oculto e um diagrama anexado abre. Use essas verificações como o plano de teste antes de abrir o backup.

Verificações planejadas — nenhum resultado foi registrado
TestemunhaObservação esperadaRegistrar durante o exercício
Conta de leitorConsegue ler a página de reparo permitida; não consegue editá-la.Aprovado/reprovado e a página verificada.
Conta de editorConsegue salvar uma alteração inofensiva na página de teste designada.Alteração e revisão resultante.
Livro restritoIndisponível para o leitor por meio da navegação e de um link direto.Conta, caminho e acesso observado.
Diagrama testemunhaAbre a partir de sua página com o conteúdo esperado.Nome do arquivo e qualquer divergência.
NotificaçãoCapturada apenas no destino de teste isolado.Destino e número observados.

Escolha testemunhas que existiam quando o backup selecionado foi feito. Uma página recém-criada não pode provar que um backup mais antigo está incompleto.

Identifique o conjunto exato de recuperação

Escreva o identificador do backup e o carimbo de data/hora na folha de resultados. Inclua a configuração da aplicação, os dados do banco de dados, os anexos e as informações de software necessárias para interpretá-los. Se seus momentos de captura forem diferentes, investigue como seu procedimento de backup os mantém consistentes antes de começar o exercício.

Para um repositório restic, escolha um snapshot explícito ou verifique cuidadosamente os filtros usados com latest. Sua --path opção seleciona um snapshot; ela não limita os arquivos restaurados. Uma restauração pode sobrescrever arquivos existentes, o que é outro motivo para usar um destino vazio e dedicado. Documentação do restic restore.

Distinga as verificações do repositório da recuperação da aplicação. Um restic padrão check examina a estrutura do repositório; check --read-data também lê os dados de pacote armazenados e pode consumir transferência e tempo substanciais. Nenhum dos dois verifica se um membro consegue usar seu wiki. verificações de integridade do restic.

Faça a cópia de teste ficar silenciosa antes de iniciar

Mantenha hosts de banco de dados de produção, caminhos de armazenamento e credenciais de saída fora da configuração de teste. Peça ao segundo mantenedor para comparar cada destino com o mapa de serviço. Confirme que o destino está separado antes de qualquer operação de restauração que grave arquivos ou objetos de banco de dados.

  • Restrinja o acesso às pessoas que conduzem o exercício.
  • Mantenha os registros DNS de produção inalterados.
  • Bloqueie a entrega de saída ou substitua-a por um destino de captura aprovado.
  • Desative webhooks, integrações agendadas e trabalhadores de fila até que seu comportamento de teste seja definido.
  • Verifique se links e redirecionamentos do navegador não podem levar discretamente o testador de volta à produção.

Trate os dados restaurados como tão sensíveis quanto os originais. O isolamento é uma verificação operacional a ser demonstrada, não um rótulo anexado a um diretório. Se você não conseguir verificar os destinos ou controles, pare antes de iniciar a aplicação.

Traga as peças de volta em uma ordem deliberada

Siga as instruções de restauração para o método de instalação e as versões em seu inventário. Para o exemplo do BookStack, o procedimento oficial cobre uma restauração separada de banco de dados e arquivos, mantendo o original APP_KEY, e ajustando a URL da aplicação quando o endereço muda. Configurações de contêiner exigem a restauração do banco de dados antes que o contêiner da aplicação seja executado. Sequência de restauração e notas de configuração do BookStack.

  1. Prepare o destino dedicado de execução e banco de dados sem iniciar o tráfego comum de membros.
  2. Restaure o banco de dados e os arquivos correspondentes; mantenha o backup original inalterado.
  3. Aplique os endereços do ambiente de teste e as conexões externas restritas.
  4. Verifique a propriedade e o acesso necessários aos arquivos de acordo com as instruções de instalação da aplicação.
  5. Inicie o serviço com as ações de saída ainda controladas, depois execute as testemunhas planejadas.

Recuperar primeiro a versão registrada mantém um simulado de rotina focado. Se o exercício também exigir uma mudança de versão, documente seu caminho de migração e ponto de recuperação separadamente. Não faça de uma atualização não planejada o remédio para uma falha de restauração inexplicada.

Verifique tanto o que funciona quanto o que permanece proibido

Execute as verificações de leitor e editor em sessões de navegador separadas para que uma sessão de administrador não possa ocultar uma falha de permissões. Teste um anexo pela página e pelo seu endereço direto. Pesquise por uma frase conhecida, siga um link interno e inspecione uma revisão mais antiga que deveria existir no backup.

Se uma verificação falhar, registre a primeira diferença observável. Uma imagem ausente sugere uma investigação diferente de um redirecionamento de login inesperado ou de uma conexão de banco de dados proibida. Preserve as evidências de erro relevantes sem copiar conteúdo privado ou credenciais para uma nota de suporte geral. Corrija uma causa identificada e repita a verificação afetada; não altere permissões amplamente apenas para fazer um erro desaparecer.

Teste e-mail apenas contra o destino de captura escolhido. O BookStack oferece uma ação de e-mail de teste e documenta que algumas falhas de notificação aparecem nos logs em vez da página do usuário. Revise essa evidência, bem como o resultado visível. Verificações de e-mail e comportamento de falha do BookStack.

Deixe um resultado honesto para a próxima pessoa

Service / test owner / reviewer:
Backup identifier / capture timestamp:
Application and database versions:
Isolated target / access restrictions:
Outbound actions disabled or redirected:
Test start / usable-service checkpoint / finish:
Reader / editor / private book / attachment results:
Search / links / revision / notification results:
Missing information or failed steps:
Corrective action / owner / next exercise:
Test data cleanup completed by:

Insira os horários observados apenas depois de fazer o trabalho e diga qual checkpoint cada um mede. Um único ensaio bem-sucedido é evidência para aquele backup e procedimento; ele não estabelece uma garantia de recuperação para outra falha. Confirme a limpeza da cópia de teste e de suas mensagens capturadas sob as regras de retenção do grupo. Realimente os ingredientes ausentes no inventário e use exportações de dados portáteis para preparar um caminho separado para mover o conteúdo do grupo.

Documentação por trás desta nota

Use a documentação da versão que você realmente executa. Estes exemplos são material de planejamento, não um registro de teste em um VPS Hoszen.