Questão de Segurança da Informação — Backup — FCC 2026

Estratégias de backup e recuperação: RPO, RTO e consistência transacional

Gabarito: letra D. Para atender a um RPO de 15 minutos e garantir consistência transacional em um banco de dados relacional, a estratégia adequada combina backups full periódicos com backups incrementais frequentes e uso de logs de transação para restauração ponto-no-tempo (Point-in-Time Recovery – PITR). Essa abordagem permite recuperar o banco até o instante imediatamente anterior à falha lógica, minimizando a perda de dados e preservando a integridade das transações.

O cenário descreve um Ministério Público Estadual com sistemas de gestão processual que exigem um RPO (Recovery Point Objective) de 15 minutos e um RTO (Recovery Time Objective) de duas horas. O RPO define a quantidade máxima de dados que a organização pode perder em um incidente — ou seja, o backup deve permitir recuperar o banco de dados com, no máximo, 15 minutos de perda. O RTO define o tempo máximo aceitável para que o sistema fique indisponível após o desastre — aqui, duas horas. A falha lógica (como um erro de aplicação, exclusão acidental ou corrupção de dados) exige uma restauração que retorne o banco a um estado consistente, sem transações parcialmente aplicadas.

Para alcançar um RPO tão curto, a estratégia mais adequada é o uso de backups incrementais frequentes combinados com o arquivamento contínuo dos logs de transação do banco de dados. Os logs registram cada transação executada, permitindo que, após restaurar o último backup completo (full) e os incrementais, o banco seja "replayado" até o ponto desejado — geralmente o instante exato da falha ou um pouco antes. Essa técnica é conhecida como restauração ponto-no-tempo (PITR) e é o padrão em bancos relacionais como PostgreSQL, Oracle e SQL Server. Ela garante a consistência transacional porque o banco aplica as transações na ordem correta, descartando aquelas que estavam em andamento no momento da falha.

A alternativa D é a única que combina todos os elementos necessários: backups full periódicos (para ter uma base íntegra), backups incrementais frequentes (para capturar as mudanças recentes e reduzir o tempo de backup) e logs de transação (para permitir a recuperação ponto-no-tempo). As demais alternativas apresentam estratégias que não atendem ao RPO de 15 minutos ou não garantem a consistência transacional exigida.

A pegadinha da questão está em confundir RPO com RTO e em não perceber que a consistência transacional exige o uso de logs de transação, não apenas cópias de arquivos ou snapshots. O candidato que não domina o conceito de PITR pode ser atraído por alternativas que parecem razoáveis, como backups diferenciais ou snapshots de storage, mas que não oferecem a granularidade necessária para recuperar o banco com apenas 15 minutos de perda e com integridade transacional.

Alternativa A — ❌ Incorreta

A exportação lógica diária em formato dump para armazenamento externo é uma prática válida de backup, mas não atende ao RPO de 15 minutos. Um dump diário significa que, em caso de falha, a perda de dados pode chegar a quase 24 horas — muito acima do limite de 15 minutos. Além disso, a exportação lógica não captura o estado transacional do banco em tempo real, e a restauração de um dump não oferece recuperação ponto-no-tempo sem o uso de logs.

Alternativa B — ❌ Incorreta

Backups completos semanais combinados com backups diferenciais diários reduzem o tempo de backup e o espaço de armazenamento, mas a restauração do último diferencial disponível ainda deixa uma janela de perda de até um dia. O RPO de 15 minutos não é atendido, pois o diferencial diário não captura as transações ocorridas após o último backup. Além disso, a consistência transacional não é garantida apenas com backups diferenciais — é necessário o uso de logs de transação para recuperação ponto-no-tempo.

Alternativa C — ❌ Incorreta

Snapshots de volume em nível de storage a cada 30 minutos reduzem a janela de perda, mas ainda assim o RPO de 15 minutos não é atendido — a perda máxima seria de 30 minutos. Além disso, a alternativa menciona "integrados com o mecanismo de consulta transacional do banco de dados", o que não é uma prática padrão. Snapshots de storage capturam o estado do volume em um instante, mas não garantem a consistência transacional do banco de dados, pois podem capturar o arquivo de dados em um estado intermediário de uma transação. Para garantir consistência, seria necessário usar snapshots consistentes com o banco (como os fornecidos por alguns sistemas de storage com integração com o banco), mas mesmo assim o RPO de 15 minutos não seria atendido com snapshots de 30 minutos.

Alternativa D — ✅ Correta ⟵ GABARITO

Esta é a estratégia correta. Backups full periódicos fornecem uma base íntegra do banco de dados. Backups incrementais frequentes capturam as mudanças desde o último backup, reduzindo o tempo de backup e o espaço de armazenamento. O uso de logs de transação permite a restauração ponto-no-tempo (PITR), que é essencial para atender ao RPO de 15 minutos e garantir a consistência transacional. Com os logs, é possível recuperar o banco até o instante imediatamente anterior à falha lógica, aplicando as transações na ordem correta e descartando as que estavam em andamento. Essa combinação é o padrão em bancos de dados relacionais para cenários com requisitos rigorosos de RPO e RTO.

Alternativa E — ❌ Incorreta

Replicar arquivos de dados do banco por cópia assíncrona em nível de sistema operacional não garante a consistência transacional. A cópia assíncrona pode capturar o banco em um estado inconsistente, com transações parcialmente aplicadas, e a replicação em nível de SO não conhece a estrutura interna do banco de dados. Além disso, a replicação assíncrona pode ter um atraso maior que 15 minutos, dependendo da carga e da rede, não atendendo ao RPO. Para garantir consistência, seria necessário usar replicação síncrona ou semissíncrona com mecanismos do próprio banco, mas mesmo assim a recuperação ponto-no-tempo exigiria logs de transação.

Gabarito: letra D — a combinação de backups full, incrementais frequentes e logs de transação é a única que atende ao RPO de 15 minutos e garante a consistência transacional na restauração após falha lógica.