Como verificar cópias de segurança em aplicações PHP

Uma cópia de segurança só proporciona proteção se permitir recuperar um serviço com um estado conhecido, dentro de um prazo aceitável e sem introduzir novos erros. Um ficheiro de cópia de segurança que existe, foi gerado sem alertas ou foi enviado para outro armazenamento não demonstra que possa ser restaurado, que inclua todos os componentes necessários nem que a aplicação PHP funcione com esses dados.

A pergunta como verificar cópias de segurança em aplicações PHP deve ser respondida com testes de restauro repetíveis. O objetivo não é apenas recuperar uma base de dados: é reconstruir um serviço coerente, verificar as suas regras de negócio e conservar evidências que permitam corrigir o procedimento antes de um incidente real.

Uma cópia existente não garante uma recuperação possível

As falhas de recuperação costumam surgir devido a dependências omitidas. Uma base de dados pode ser restaurada corretamente e, depois, descobrir-se que faltam ficheiros carregados por utilizadores, chaves para decifrar informação, variáveis de ambiente ou configurações de serviços externos. Também pode acontecer que a cópia de segurança esteja corrompida, que a conta técnica não tenha permissões para a restaurar ou que o seu formato não seja compatível com a infraestrutura de destino.

É conveniente separar dois objetivos operacionais:

• Objetivo de ponto de recuperação (RPO): quantidade máxima de dados que se aceita perder, medida a partir do último estado recuperável.
• Objetivo de tempo de recuperação (RTO): tempo máximo aceitável para devolver o serviço a uma situação operacional.

Ambos os objetivos condicionam a frequência das cópias, a retenção, a utilização de registos de transações e a conceção dos testes. Uma cópia noturna pode ser suficiente para um catálogo com poucas alterações, mas não para transações que exijam voltar a um instante próximo do incidente. Neste último caso, o plano deve contemplar um restauro para um ponto no tempo, se a tecnologia de dados e a sua configuração o permitirem.

Construa um inventário recuperável, não apenas uma exportação de dados

O inventário deve descrever quais os elementos que formam o estado mínimo da aplicação e onde são feitas cópias de segurança dos mesmos. Numa aplicação PHP, a base de dados costuma ser central, mas raramente é o único componente persistente.

• Dados transacionais: bases de dados relacionais, documentos, ficheiros de migração relevantes e, quando aplicável, registos necessários para restauro pontual.
• Ficheiros persistentes: anexos, imagens, exportações, documentos gerados e qualquer conteúdo armazenado fora da base de dados.
• Configuração: parâmetros de execução, domínios, caminhos de armazenamento, configuração de correio, serviços de pagamento e ligações a APIs. O código versionado ajuda, mas não substitui a configuração operacional.
• Segredos: chaves de cifragem, credenciais, certificados, tokens e segredos de sessões. Devem ser recuperados através de um mecanismo controlado, não copiados para relatórios ou repositórios.
• Processamento assíncrono: filas, trabalhos agendados, consumidores e política de tentativas. É necessário decidir se as mensagens pendentes são restauradas, eliminadas ou reconstruídas de forma segura.
• Dados derivados: caches, índices de pesquisa, vistas materializadas, miniaturas ou agregados. Normalmente não são a fonte de verdade, mas a sua reconstrução pode ser necessária antes de operar.

Documente para cada elemento o proprietário, a localização, o método de restauro, as dependências e a sensibilidade. Se um segredo não puder ser recuperado ou sujeito a rotação de forma controlada, o procedimento não está completo.

Defina cenários e escolha o ponto de restauro

Nem todos os incidentes exigem a mesma resposta. Um registo eliminado por engano, uma corrupção em massa, uma vulnerabilidade que alterou dados e uma falha completa do ambiente exigem procedimentos distintos. Definir cenários evita aplicar um restauro total quando bastaria uma correção limitada, ou restaurar dados contaminados por escolher um ponto posterior ao problema.

Cenários que devem ser testados

• Recuperação de um registo ou de um conjunto reduzido de dados através de exportação, auditoria ou restauro numa instância temporária.
• Recuperação de uma base de dados completa a partir de uma cópia consistente.
• Restauro para um instante anterior ao incidente através de registos de transações, quando essa capacidade existir.
• Recuperação de um serviço completo: dados, ficheiros, configuração, segredos, aplicação e processos auxiliares.
• Reconstrução de índices, caches e outros dados derivados sem alterar a fonte de verdade.

Antes de restaurar, defina o ponto objetivo e registe a perda de dados assumida. Por exemplo, se for recuperada uma cópia das 02:00, qualquer operação posterior pode exigir reconciliação a partir de outras fontes legítimas, como registos de pagamento ou sistemas de terceiros. Esse estado não deve ser apresentado como se incluísse transações que não contém.

Respeite uma ordem de recuperação que limite efeitos secundários

Um restauro controlado necessita de isolamento e de uma sequência clara. O ambiente de teste não deve enviar emails reais, executar cobranças, chamar integrações de produção nem partilhar filas com o serviço ativo. Utilize credenciais e destinos seguros para esse teste.

1. Prepare a infraestrutura de destino: rede, armazenamento, versão do motor de dados, permissões e capacidade suficiente.
2. Recupere ou provisione a configuração e os segredos através do canal autorizado. Verifique que as chaves de cifragem necessárias correspondem ao estado dos dados restaurados.
3. Restaure a base de dados e os ficheiros persistentes. Registe as marcas temporais, os identificadores da cópia e os comandos ou tarefas utilizados.
4. Faça a implantação da versão de aplicação compatível. A implantação instala o artefacto de software; não equivale, por si só, a disponibilizá-lo aos utilizadores.
5. Execute migrações apenas se forem justificadas pelo cenário. Uma migração irreversível pode dificultar a comparação com o estado original ou modificar indevidamente os dados recuperados.
6. Mantenha desativados consumidores, tarefas agendadas e integrações com efeito externo até concluir as validações.
7. Reconstrua dados derivados e ative os processos de forma gradual, monitorizando duplicados, erros e tentativas.

As filas exigem especial atenção. Reativar um consumidor antes de validar o estado pode enviar notificações duplicadas, repetir operações ou processar mensagens que já não correspondem aos dados recuperados. A política deve definir quais as mensagens que são conservadas, quais são descartadas e como se evita a execução duplicada.

Valide a consistência técnica e de negócio

O facto de uma aplicação responder HTTP 200 não demonstra que seja recuperável. As verificações devem combinar integridade técnica, comportamento funcional e restrições do domínio. Automatize as validações que forem estáveis para poder repeti-las após cada teste.

• Compare contagens de entidades relevantes com os valores esperados para o ponto de restauro: utilizadores, pedidos, faturas, ficheiros ou eventos.
• Procure referências quebradas entre a base de dados e o armazenamento de objetos: registos que apontam para ficheiros ausentes ou ficheiros sem proprietário conhecido.
• Verifique restrições, relações, codificação, fusos horários e sequências de identificadores quando afetarem novas escritas.
• Execute percursos funcionais com uma conta de teste: autenticação, leitura de dados, criação controlada de um registo e acesso a um ficheiro protegido.
• Verifique papéis e permissões. Um segredo restaurado incorretamente pode impedir acessos ou, pior, ampliar privilégios.
• Revise trabalhos pendentes, falhados ou bloqueados e assegure que a sua retoma não gera ações externas indevidas.

Os testes da aplicação devem utilizar dados adequadamente protegidos. Se forem copiados dados pessoais para um ambiente isolado, aplique os controlos de acesso, retenção e minimização correspondentes. Sempre que possível, utilize dados mascarados para validações que não exijam informação identificável.

Trate caches, índices e derivados como componentes reconstruíveis

Uma cache não deve ser a única localização de informação necessária para recuperar o serviço. Após restaurar a fonte de verdade, invalide caches que possam conter valores anteriores ao ponto recuperado. Em seguida, permita o seu aquecimento controlado ou execute uma geração explícita, se existir.

Os índices de pesquisa e outros armazenamentos derivados devem ser identificados como tal antes de serem eliminados ou regenerados. A reconstrução deve partir dos dados restaurados e produzir métricas verificáveis: número de documentos indexados, erros, elementos pendentes e consultas de verificação. Se um índice guardar campos sensíveis, as suas permissões e a sua política de retenção também fazem parte da validação.

Transforme cada teste em evidência operacional

Testar um restauro num ambiente isolado deve ser uma atividade programada, não uma improvisação durante uma crise. Atribua responsáveis para executar, observar, validar o negócio e autorizar alterações ao procedimento. Meça os tempos reais por fase em vez de estimativas.

Conserve uma evidência breve e útil após cada exercício:

• cenário testado, data, responsável e ponto de recuperação escolhido;
• identificador e antiguidade de cada cópia utilizada;
• versões e configuração relevante do destino, sem expor segredos;
• tempo observado para restaurar, validar e reconstruir derivados;
• resultado dos controlos de consistência e dos testes funcionais;
• incidentes, decisões tomadas, perda de dados assumida e ações corretivas.

Revise o procedimento quando mudarem o esquema de dados, o armazenamento de ficheiros, os segredos, as integrações, a arquitetura de filas ou o processo de implantação. A evidência histórica permite detetar que o RTO já não é cumprido, que uma cópia deixou de incluir um componente ou que uma dependência se tornou manual.

Erros que invalidam uma estratégia de cópias de segurança

Restaurar apenas a base de dados é o erro mais visível, mas não o único. Também são riscos frequentes não verificar que a cópia de segurança termina corretamente, depender de uma única localização, não comprovar o restauro pontual, misturar ambientes, omitir permissões da conta restauradora e deixar o procedimento apenas no conhecimento de uma pessoa.

A correção não consiste em acumular mais cópias sem critério. Consiste em definir estados recuperáveis, isolar um restauro, validar dados e processos, medir o resultado e atualizar o plano. Assim, as cópias de segurança deixam de ser uma promessa operacional e passam a ser uma capacidade demonstrável de recuperação do serviço.