Pontos principais
- Entenda as métricas centrais: o RTO define o tempo máximo aceitável para restaurar sistemas após uma interrupção; o RPO define a perda máxima aceitável de dados, medida retroativamente a partir do momento da falha.
- Assuma a responsabilidade pela recuperação: provedores de SaaS garantem a disponibilidade da plataforma, não a proteção dos dados; no modelo de responsabilidade compartilhada, definir e cumprir metas de RTO e RPO cabe ao cliente, não ao fornecedor.
- Ajuste as metas à realidade do SaaS: cumprir RTO e RPO no backup SaaS depende da velocidade de restauração, do volume de dados, do throttling de API do fornecedor e da frequência dos backups, e não da disponibilidade da infraestrutura local.
- Reforce a defesa contra ransomware: como os invasores miram cada vez mais nas próprias cópias de backup, cumprir RPO e RTO durante um ataque exige ao menos um backup imutável, offline ou isolado por air gap, conforme a regra 3-2-1-1-0.
- Aplique boas práticas: alinhe as metas ao impacto no negócio, automatize backups, teste a recuperação com frequência, monitore o desempenho e considere novos escopos, como agentes de IA e Copilot, que mudam a velocidade com que os dados se movem.
O planejamento de backup e recuperação de desastres envolve objetivos que ajudam as organizações a definir o que esperar da recuperação. Entre eles estão o RTO e o RPO, que estabelecem com que rapidez os sistemas devem voltar ao ar e quanta perda de dados é aceitável depois de um incidente.
Esses conceitos são amplamente adotados em ambientes de TI tradicionais, mas os fatores que afetam RTO e RPO podem ser diferentes em ambientes SaaS. Neste artigo, vamos examinar mais a fundo o papel do RTO e do RPO em plataformas SaaS e sistemas de backup. Entender como essas duas métricas funcionam no SaaS ajuda a criar expectativas realistas para o backup SaaS.
Por que o backup SaaS coloca RTO e RPO sob sua responsabilidade
Provedores de SaaS trabalham com um modelo de responsabilidade compartilhada: o fornecedor garante a disponibilidade da plataforma e da infraestrutura, mas proteger os dados em si (contra exclusão acidental, ransomware, ameaças internas ou uma migração malfeita) é tarefa do cliente.
Microsoft 365, Google Workspace e Salesforce isentam-se de responsabilidade por perda de dados em seus termos de serviço. É justamente por isso que RTO e RPO precisam ser definidos e assumidos internamente, em vez de presumir que estão cobertos pelo SLA do provedor.
O que RTO e RPO significam no backup SaaS
Tanto o RTO quanto o RPO definem limites aceitáveis de determinados fatores antes que um desastre aconteça. Veja o que cada um estabelece:
Recovery point objective (RPO) é o volume máximo de dados que uma organização pode perder depois de um incidente. É medido retroativamente a partir do momento da interrupção e determina com que frequência os backups precisam ser feitos para respeitar a tolerância à perda de dados.
Recovery time objective (RTO) é o tempo máximo que o sistema de uma organização pode ficar fora do ar antes que o impacto no negócio se torne inaceitável. É medido para a frente, a partir do momento da falha, e define com que rapidez os serviços devem voltar a funcionar.
Ambas as metas são definidas antes de um desastre; não são medições do que de fato aconteceu.
| RTO | RPO | |
| Mede | Tempo de inatividade | Perda de dados |
| Direção | Para a frente, a partir da falha | Para trás, a partir da falha |
| Determinado por | Velocidade de restauração, volume de dados, limites de API | Frequência de backup, automação |
| Responsabilidade de | TI/operações | TI/operações + governança de dados |
Veja como alinhar as expectativas de recuperação ao que cada sistema realmente precisa.
RTO e RPO em ambientes SaaS
RTO e RPO medem as mesmas coisas, independentemente do ambiente. O que muda no backup SaaS é o conjunto de variáveis que determina se essas metas podem mesmo ser cumpridas quando uma restauração é necessária.
- O que influencia o RTO no backup SaaS:
- A rapidez com que os dados podem ser restaurados pelo processo de restauração da solução de backup
- O volume de dados recuperados, já que conjuntos maiores levam mais tempo para restaurar
- O throttling de API imposto pelo fornecedor (por exemplo, os limites de taxa da Microsoft Graph API e da API do Google Workspace), que limita a velocidade de gravação dos dados, não importa quanta banda ou orçamento haja disponível
- O que influencia o RPO no backup SaaS:
- A frequência dos backups, que define diretamente o tamanho da janela de perda potencial de dados
- Se os backups são automatizados e rodam de forma consistente, sem lacunas
- A velocidade com que os dados mudam entre um backup e outro, entre usuários e sistemas
Como o SaaS muda as expectativas de RTO
No contexto do backup SaaS, o RTO gira em torno de restaurar dados com eficiência. Isso faz com que o RTO dependa muito do desempenho da restauração e do tamanho dos dados, e não da disponibilidade da infraestrutura. Os principais fatores que afetam o RTO são:
- O volume de dados restaurados
- A velocidade das operações de restauração via APIs
- Os limites impostos pelo provedor de SaaS durante a restauração
Como o SaaS muda as expectativas de RPO
Já o RPO no backup SaaS está ligado à frequência dos backups e à captura dos dados. Pontos importantes a considerar:
- Mudanças frequentes nos dados SaaS entre usuários e sistemas
- Os intervalos entre backups, que determinam quantos dados podem ser perdidos
- As lacunas entre backups, que representam perda potencial de dados
- A retenção nativa (uma lixeira, por exemplo), que não é backup e pode ser esvaziada por um invasor, eliminando totalmente aquele ponto de recuperação
Melhorar o RPO significa reduzir as lacunas entre os backups. Para isso, é preciso:
- Aumentar a frequência dos backups
- Contar com automação confiável
- Monitorar constantemente o sucesso dos backups
Impacto do RTO e do RPO nas estratégias de recuperação em SaaS
RTO e RPO influenciam como a estratégia de backup SaaS de uma organização é construída e mantida. Ao definir essas métricas, considere:
- Um RPO mais rígido: exige backups mais frequentes, o que afeta a configuração e o monitoramento da solução de backup.
- Um RTO mais rígido: exige capacidade de restauração mais rápida, o que pode influenciar a escolha da solução de backup e a estrutura dos fluxos de restauração.
- Testes regulares: confirmam se os objetivos declarados são mesmo viáveis. Testar uma estratégia de backup, em cenário real ou simulado, ajuda a validar sua confiabilidade.
- Classificação por níveis: categorizar sistemas por criticidade permite aplicar metas de RTO e RPO mais rígidas às aplicações prioritárias e aceitar tolerâncias mais folgadas nas menos críticas.
Gerencie backups em uma única plataforma com o NinjaOne Backup
Cenários comuns de recuperação em SaaS
Veja situações comuns em que a recuperação de dados é crítica e como RTO e RPO entram em jogo.
-
Exclusão acidental
RTO: determina com que rapidez a solução de backup conclui a restauração depois que o ponto correto é identificado.
RPO: determina quão recente é o ponto de restauração disponível, o que delimita quais dados podem ser recuperados.
-
Ataques de ransomware
RTO: determina por quanto tempo as operações ficam paradas enquanto a restauração acontece (algo complicado pelo fato de que as variantes modernas de ransomware procuram ativamente cópias de backup acessíveis e as criptografam ou excluem antes de criptografar os dados de produção).
RPO: determina quão longe a recuperação precisa voltar para alcançar um backup anterior ao comprometimento (o que só é possível se esse backup fosse imutável ou offline e, portanto, tivesse ficado intocado pelo ataque).
-
Configuração incorreta
RTO: determina com que rapidez as operações normais podem ser retomadas depois que o backup adequado é selecionado e aplicado
RPO: define quantos dados podem ser perdidos ao restaurar para um ponto anterior à mudança que causou o problema
Boas práticas de RTO e RPO no backup SaaS
Estas são algumas boas práticas de backup SaaS para ajudar as organizações a cumprir suas metas de RTO e RPO.
- Defina RTO e RPO a partir das necessidades do negócio: determine os requisitos com base no que a perda ou indisponibilidade de dados custaria de fato à organização.
- Automatize os backups para sustentar as metas de RPO: a automação reduz lacunas e minimiza riscos de exposição silenciosa.
- Teste os processos de recuperação com frequência: garanta que os pontos de recuperação atendam aos requisitos de RPO e que os procedimentos de restauração cumpram as metas de RTO definidas.
- Monitore o desempenho dos backups: falhas de backup devem gerar alertas automáticos para as equipes de TI, para que os problemas sejam identificados antes de crescerem.
- Ajuste conforme os dados crescem: a frequência dos backups e a velocidade de restauração podem mudar com o tempo, especialmente à medida que o volume de dados SaaS aumenta.
- Inclua agentes de IA e o Copilot no escopo do backup: faça o inventário de quais agentes do Copilot, fluxos do Power Automate e integrações de IA de terceiros estão ativos.
- Mantenha ao menos uma cópia de backup imutável, offline ou isolada por air gap: aplique a regra 3-2-1-1-0, porque um backup que o invasor consegue excluir não é um ponto de recuperação de verdade.
Equívocos comuns sobre RTO e RPO em SaaS
Existem vários equívocos sobre as soluções de backup SaaS e o que elas conseguem fazer. Veja alguns deles:
-
“Sistemas na nuvem garantem recuperação instantânea.”
Uma plataforma SaaS estar na nuvem não torna a restauração instantânea. Restaurar dados de um backup leva tempo, e esse tempo varia conforme o volume de dados recuperados.
-
“O RTO é sempre curto em ambientes SaaS.”
Vários fatores, como um conjunto de dados grande ou limites de throughput no processo de restauração, podem alongar o tempo de recuperação. Disponibilidade da plataforma não é sinônimo de recuperação rápida.
-
“O RPO é automaticamente mínimo.”
Quem configura a frequência dos backups é a organização, e é ela que determina o RPO. Sem planejamento intencional, o RPO pode ser bem maior do que o esperado, mesmo com uma solução de backup nativa da nuvem.
-
“A frequência dos backups não afeta a perda de dados.”
Frequência e exposição à perda de dados estão diretamente ligadas. O intervalo entre backups define exatamente quantos dados ficam em risco se um incidente ocorrer pouco antes do próximo backup.
-
“O desempenho de recuperação é ilimitado.”
Processos de backup e restauração têm limites de throughput. Esses limites não somem em uma emergência e precisam entrar no planejamento de RTO desde o início.
Entendendo RTO e RPO no backup SaaS
RTO e RPO devem ser tratados como compromissos práticos que determinam como a estratégia de backup SaaS é desenhada, como os processos de restauração são testados e quão realistas são as expectativas de recuperação caso aconteça algo inesperado que afete os dados da organização. No fim das contas, cada organização precisa definir seu RTO e RPO com base no impacto real para o negócio e validá-los com testes regulares.
Temas relacionados:
