O que o sistema promete
Uma cópia é apenas candidata à recuperação até provar que restaura serviço útil. Acerte quanto trabalho recente pode ser redigitado e quanto tempo o serviço pode parar. São decisões operacionais, não promessas criadas pelo agendamento.
Comparar opções práticas
Liste banco, arquivos, configuração, acesso a segredos e versão compatível da aplicação. O banco sozinho pode não reconstruir o produto. Use método adequado às escritas ativas. O SQLite documenta uma API para cópias consistentes; copiar arquivo em uso sem entender seu journal não basta.
Testar a jornada completa
Restaure, por exemplo, pedidos em ambiente isolado. Confira integridade, ordens representativas e anexos. Inicie com integrações de saída desativadas para não reenviar avisos nem cobrar no ensaio. Meça desde obter a cópia até concluir uma tarefa comum. Permissões ou configuração ausentes são defeitos de recuperação, mesmo se o banco abre.
Tornar a recuperação visível
Não ensaie sobrescrevendo a única produção. Proteja o estado atual, identifique o destino exato e exija uma ação deliberada ao substituir dados. Cópia no mesmo disco não cobre a perda dele. Teste acesso à cópia separada e às chaves; arquivo inacessível não recupera nada.
Escrever a sequência de recuperação antes do incidente
Comece por propósito e destino: ensaio isolado, host perdido ou substituição da produção danificada. As consequências diferem. Registre origem, criação, integridade e versão compatível. Separe instruções de acesso dos segredos para compartilhar procedimento sem espalhar credenciais.
Para substituir produção, estabeleça parada controlada das escritas: web, workers, tarefas agendadas e demais escritores. Preserve estado atual quando possível e útil. Restaure no local certo, confira dono, permissões, banco e arquivos antes do tráfego. Reinicie em ordem que impeça a fila de processar dados incompletos ou incompatíveis. Ensaie no modelo real em vez de improvisar na falha.
Depois concilie pedidos recentes, anexos e referências financeiras com o ponto restaurado. Trabalho posterior precisa de responsável. Não repita cobrança, envio ou mensagens só porque o registro local voltou atrás; o mundo externo não voltou. Mantenha diferenças visíveis e explique impacto ao atendimento. Atualize o procedimento com tempo, falhas de acesso e dependências ausentes. Teste retenção e cópia separada; restaurar arquivo local não prova recuperação após perda do host.
Evidências de aceite da recuperação
| Etapa | O que demonstrar |
|---|---|
| Escolher a origem | Identidade, criação, integridade e destino são inequívocos. |
| Parar escritas | Todos os escritores são controlados e o estado anterior preservado quando viável. |
| Reabrir serviço útil | Uma tarefa autorizada funciona com arquivos e configuração, não só abertura do banco. |
| Conciliar o exterior | Trabalho posterior e ações externas são revisados antes de repetir, evitando duplicar atividade concluída. |
Exemplos para revisão
Quem restaura na ausência do operador habitual? Que dados se perderão e como serão conciliados? O que exige voltar atrás? Leve o último teste real, tempo e lacunas à revisão, não apenas um trabalho de backup verde.
Fontes e outras leituras
Recuperação e manutenção
Um próximo capítulo pensado para o software existente.
Converse sobre este serviço