Como restaurar registos de uma base de dados sem sobrescrever alterações posteriores

Uma cópia de segurança permite recuperar dados, mas restaurá-la diretamente sobre a base de dados ativa pode eliminar alterações legítimas feitas depois da data da cópia. Quando o problema afeta um registo ou um conjunto limitado, o objetivo costuma ser recuperar a informação perdida e conservar o restante estado atual. Isso exige tratar a recuperação como uma operação de comparação e reconciliação, e não como uma simples substituição.

A estratégia adequada depende do motor de base de dados, do esquema, da disponibilidade de registos de auditoria e do âmbito dos danos. Numa aplicação PHP, convém separar a lógica de recuperação da aplicação em produção, documentar as decisões e testar as validações antes de escrever dados. Se não for possível determinar quais alterações são seguras, parar e preparar uma reconciliação manual costuma ser menos arriscado do que automatizar uma substituição.

Definir o que significa recuperar os dados

Uma restauração completa substitui uma base de dados, um esquema ou um conjunto amplo de dados pelo conteúdo de um ponto de recuperação. Uma recuperação seletiva, por outro lado, procura restabelecer linhas específicas ou determinados valores sem modificar os restantes dados ativos. Antes de escolher, descreva com precisão o resultado esperado: qual entidade está em falta ou foi alterada, que campos devem ser recuperados e que alterações posteriores devem ser preservadas.

Delimite o âmbito usando identificadores estáveis, como a chave primária, e não apenas valores que podem ter mudado, como o nome ou o endereço de e-mail. Esclareça também se o incidente afeta registos relacionados: por exemplo, uma encomenda pode depender de linhas, pagamentos, moradas e eventos de estado. Recuperar apenas a linha principal pode deixar uma entidade incoerente; recuperar todo o grupo pode incluir alterações válidas que não devem ser revertidas.

• Registe o sintoma, o intervalo temporal aproximado e quem comunicou o problema.
• Identifique as tabelas, as chaves primárias, as chaves externas e as restrições relevantes.
• Defina quais campos devem voltar a um valor anterior e quais devem permanecer como estão.
• Determine quem aprovará a operação e que verificações permitirão considerá-la concluída.

Escolher um ponto de recuperação e reconstruir o contexto

Selecione um ponto de recuperação que permita reconstruir o estado necessário, não necessariamente uma cópia anterior aos danos. Dependendo do incidente, pode ser necessário comparar várias cópias, registos de transações e dados de auditoria para identificar que informação deve ser recuperada e que contexto posterior convém preservar. A recuperação para um ponto no tempo pode produzir uma base de dados temporária útil para extrair dados, mas isso não significa que seja seguro transferir todo o seu conteúdo para produção.

Confirme a data e o fuso horário, a cobertura da cópia, o esquema com que foi criada e o resultado das verificações de integridade disponíveis. Uma cópia não verificada não deve ser considerada, por defeito, uma fonte fiável. Verifique também se os identificadores podem ter sido reutilizados ou se existem processos que escrevem nas tabelas afetadas durante a investigação.

Restaure a cópia numa instância isolada, com acesso restrito e sem ligações de escrita à produção. A aplicação não deve apontar acidentalmente para essa instância nem executar tarefas agendadas sobre ela. Se os dados contiverem informações pessoais ou sensíveis, limite o acesso e aplique as medidas de proteção previstas para esses dados. O ambiente isolado permite comparar estados sem acrescentar riscos à base de dados ativa.

Comparar sem presumir que a cópia representa a verdade atual

Compare as linhas candidatas da cópia com as linhas atuais usando as respetivas chaves estáveis. Para cada uma, distinga três situações: o registo já não existe, existe mas tem campos alterados, ou não apresenta diferenças relevantes. Se houver marcas de atualização, histórico de eventos ou auditoria, use-os para perceber quando e por que motivo ocorreu a alteração. Uma marca temporal, por si só, não demonstra que utilizador fez a alteração nem se esta deve ser preservada.

A recuperação seletiva exige uma precaução essencial: não copiar automaticamente uma linha antiga completa quando alguns dos seus campos tiverem evoluído de forma válida. A comparação pode revelar, por exemplo, que um registo perdeu um campo descritivo, enquanto o seu estado, proprietário ou relação com outra entidade mudou posteriormente. Recuperar apenas o campo perdido pode ser mais seguro do que substituir a linha inteira, desde que as regras de negócio o permitam.

Verifique também conflitos de unicidade, chaves externas, colunas obrigatórias, valores predefinidos e regras aplicadas pela aplicação. Em sistemas com eliminação lógica, confirme se o registo está marcado como eliminado em vez de estar ausente. As tabelas que participam na mesma operação de negócio podem exigir uma reconciliação conjunta para evitar saldos, estados ou referências incoerentes.

Aplicar uma operação limitada e verificável

Prepare um plano com o conjunto exato de chaves e colunas que serão modificadas. Antes de o executar, guarde uma cópia do estado atual dessas linhas ou um mecanismo equivalente de reversão. Teste o plano numa cópia recente da base de dados ativa e compare o resultado com o esperado. O teste deve incluir as restrições e dependências reais, e não apenas uma importação de linhas isoladas.

Quando o motor e a operação o permitirem, execute as alterações numa transação. Uma transação não substitui a revisão: algumas ações de restauração ou importação podem ter comportamentos específicos do motor, e processos externos podem atualizar dados em simultâneo. Use condições que detetem alterações inesperadas entre a comparação e a escrita. Se a linha já não corresponder ao estado revisto, pare a operação e volte a analisá-la, em vez de a substituir silenciosamente.

Numa aplicação PHP, uma tarefa controlada ou um comando de manutenção pode validar entradas, limitar as chaves afetadas e registar os resultados. Evite construir instruções SQL concatenando valores. Use consultas parametrizadas e o mecanismo transacional de acesso a dados utilizado pela aplicação. Mantenha a operação fora de rotas públicas e não exponha credenciais ou cópias em registos de texto.

Antes de confirmar as alterações, verifique o número de linhas afetadas, as restrições e as relações relevantes. Depois, confirme os valores recuperados e o comportamento da aplicação nas operações de negócio relacionadas. Se uma validação falhar antes de confirmar uma transação, reverta a transação. Se já tiver sido confirmada ou existirem efeitos irreversíveis, não improvise uma nova escrita: ative o plano de reversão ou recuperação aprovado antes da execução, seguindo o procedimento testado para restaurar o estado aceite e verificá-lo. Se o plano não permitir recuperar um estado coerente, pare de fazer novas alterações, preserve as evidências e encaminhe a decisão para as pessoas responsáveis.

Registar a decisão e escolher quando não automatizar

Registe o incidente, o ponto de recuperação utilizado, as chaves examinadas, os campos restaurados e as alterações posteriores preservadas. Registe quem reviu e aprovou a operação, quando foi executada, que validações foram realizadas e qual foi o resultado. Não inclua dados sensíveis desnecessários no registo. Esta rastreabilidade permite explicar a decisão e facilita uma investigação posterior.

Opte pela reconciliação manual se não houver chaves fiáveis, existirem conflitos entre operações de negócio, não for possível distinguir uma alteração acidental de uma legítima ou a recuperação afetar relações cujo significado dependa do contexto. A restauração completa pode ser adequada perante uma corrupção extensa, mas exige avaliar o seu impacto, a interrupção, a perda de alterações posteriores e o procedimento de recuperação. Não deve ser escolhida apenas por ser mais simples de executar.

• Recuperação seletiva: os danos estão bem delimitados, as chaves são fiáveis e as diferenças podem ser verificadas.
• Reconciliação manual: existem alterações simultâneas ou regras de negócio que exigem avaliação humana.
• Restauração completa: os danos são extensos e existe um plano aprovado para gerir a indisponibilidade e as alterações que seriam perdidas.

Lista de verificação antes de concluir a recuperação

• Preparação: estão identificados o âmbito, as chaves, as dependências e o resultado esperado? Foi escolhido e verificado um ponto de recuperação adequado?
• Ambiente e aprovação: a cópia foi restaurada num ambiente isolado, o acesso foi limitado e o procedimento foi testado? As pessoas responsáveis aprovaram a operação e o plano de reversão ou recuperação?
• Execução: o estado atual das linhas afetadas foi preservado, a escrita está limitada às chaves e aos campos previstos e são detetadas alterações simultâneas?
• Verificação: foram revistas as linhas afetadas, as restrições, as referências e o comportamento de negócio? Se uma verificação falhar, foram interrompidas novas escritas e ativado o procedimento aprovado?
• Rastreabilidade: ficaram registados a decisão, a execução, as validações, as alterações preservadas e o resultado, sem incluir dados sensíveis desnecessários?

Se não puder responder afirmativamente aos pontos aplicáveis, adie a escrita em produção. A decisão entre recuperação seletiva, reconciliação manual e restauração completa deve basear-se no âmbito dos danos, na fiabilidade das evidências, no impacto operacional e na possibilidade real de recuperar um estado coerente.