O RPO descreve a janela de perda de dados que está preparado para aceitar; o RTO descreve a interrupção que pretende manter dentro de limites. Defina ambos para uma função empresarial útil e depois comprove a sequência de recuperação num exercício. Um calendário de cópias de segurança ou uma especificação de servidor, por si só, não estabelece nenhum dos objetivos.
Comece com um serviço que as pessoas possam utilizar
Os objetivos de recuperação tornam-se úteis quando descrevem uma função empresarial em vez de uma máquina isolada. Um servidor pode arrancar enquanto os clientes continuam sem conseguir iniciar sessão, obter ficheiros ou concluir um pedido. Escreva a condição final em linguagem comum: os utilizadores autorizados conseguem aceder à aplicação e os dados necessários estão consistentes. Isto torna o objetivo testável por alguém fora da equipa de infraestrutura.
Pergunte ao responsável da aplicação o que uma interrupção impediria e quanto custariam os dados em falta. Uma publicação semanal e uma aplicação de processamento de transações podem ter respostas diferentes. Trate os objetivos resultantes como metas de planeamento, não como promessas inventadas a partir do catálogo de hardware. Registe quem os aprovou e que cenários de falha o plano abrange.
Separe os dois relógios
O RPO diz respeito a quão atrás podem estar os dados recuperados em relação à perturbação. O RTO diz respeito a quanto tempo a função pode permanecer indisponível. Uma cópia de segurança recente pode melhorar a janela de perda de dados, enquanto um restauro lento ainda falha o objetivo de tempo de recuperação. Inversamente, um reinício rápido pode restaurar o acesso a uma aplicação cujos dados mais recentes não sobreviveram.
Especifique os pontos de referência. Decida quando começa o relógio do incidente, o que conta como operação restaurada e como será identificado o ponto de dados utilizável. Mantenha os objetivos separados dos resultados medidos: um objetivo é o que procura; um exercício mostra o que o processo atual alcançou. Revisite qualquer deles quando a aplicação ou o conjunto de dados mudar.
Orçamente cada passo da recuperação
Um orçamento prático de RTO inclui deteção, avaliação, autorização, acesso ao ambiente de recuperação, restauro, validação da aplicação e reabertura. O tempo de cópia de ficheiros é apenas um componente. Se a pessoa que detém a chave de recuperação estiver indisponível, uma cópia de segurança teoricamente rápida pode continuar inutilizável. Enumere as dependências e garanta que a equipa de recuperação lhes consegue aceder durante a falha em consideração.
Atribua um tempo provisório a cada passo e depois substitua as estimativas por observações. Neste orçamento ilustrativo de duas horas, o restauro recebe a maior margem, mas a validação continua a ter tempo protegido. Os números descrevem um exemplo de planeamento, não a prestação de serviços SwissOctet. Se o total não tiver margem, o design precisa de melhorias antes de o objetivo ser credível.
| Passo de recuperação | Margem ilustrativa | Evidência a recolher |
|---|---|---|
| Detetar e avaliar | 15 minutos | Chegada do alerta e decisão sobre o incidente |
| Preparar o ambiente de recuperação | 20 minutos | Acesso e configuração disponíveis |
| Restaurar dados e serviço | 50 minutos | Restauro concluído com dados consistentes |
| Validar e reabrir | 25 minutos | O percurso do utilizador é bem-sucedido |
| Margem de contingência | 10 minutos | Trabalho inesperado registado |
Verifique a janela real de perda de dados
Uma tarefa agendada a cada hora não garante automaticamente um RPO de uma hora. Uma tarefa falhada, um carregamento atrasado ou uma cópia inutilizável podem tornar o ponto recuperável mais recente muito mais antigo. Observe a conclusão bem-sucedida e o estado que pode realmente ser restaurado. Para uma aplicação com vários armazenamentos de dados, confirme que os seus pontos de recuperação são compatíveis em vez de ler cada marca temporal isoladamente.
Escolha um evento de referência durante um exercício, como um registo de teste autorizado criado numa hora conhecida. Após o restauro, identifique o registo válido mais recente e meça a diferença. Utilize dados de teste inofensivos. Isto dá um resultado prático e expõe pressupostos que um painel que mostre apenas o sucesso das tarefas pode deixar ocultos.
Escolha uma estratégia dentro do orçamento
As abordagens de cópia de segurança e restauro, ambientes de reserva preparados e designs de aplicação replicados trocam custo e complexidade por velocidade de recuperação. A replicação pode reduzir alguns atrasos, mas também pode reproduzir uma eliminação acidental ou um erro da aplicação. Um ambiente de reserva que se afastou da configuração funcional cria o seu próprio risco. Selecione uma estratégia em função dos cenários de falha e dos objetivos que documentou.
Considere um serviço pequeno com um objetivo de quatro horas e um conjunto de dados maior cujo restauro, por si só, demora seis horas num ensaio. Comprar uma porta de rede mais rápida é apenas uma hipótese: as leituras de armazenamento, as escritas de receção e a recuperação da aplicação podem dominar. Melhore o passo limitante medido, reduza o conjunto de recuperação ou mude a estratégia e volte a fazer o exercício.
Ensaie sem pôr em risco a produção
Utilize um ambiente de recuperação isolado e uma janela de exercício definida. Certifique-se de que as tarefas restauradas não podem enviar notificações reais, aceitar pagamentos públicos ou escrever em integrações de produção. Teste o acesso, a integridade dos dados e percursos representativos do utilizador antes de considerar o exercício concluído. Inclua uma pessoa que não escreveu o procedimento original para expor instruções em falta.
Mantenha uma cronologia do exercício, do ponto de recuperação alcançado e de todas as interrupções causadas por informação indisponível. Um relatório útil indica o resultado medido, a diferença em relação ao objetivo e uma ação corretiva específica. Repita após alterações significativas e num intervalo adequado à importância do projeto.
Mantenha o plano utilizável durante uma falha
Guarde o procedimento de recuperação onde a equipa lhe possa aceder sem depender exclusivamente da aplicação falhada. Mantenha credenciais e chaves de encriptação num local protegido com um processo de acesso testado. Atualize contactos, dimensões dos conjuntos de dados e dependências à medida que o projeto evolui. Um plano obsoleto pode consumir a margem de tempo antes mesmo de o restauro começar.
Ao comparar configurações SwissOctet, separe a sua arquitetura de recuperação das opções de cópia de segurança do catálogo. Confirme o que uma opção abrange, onde são guardados os dados de recuperação e quem realiza o restauro. O catálogo não estabelece um RPO ou RTO da aplicação. O seu processo medido e os termos reais do serviço fornecem a base para essa decisão.
A sua lista de verificação prática.
- Defina a função empresarial restaurada.
- Aprove objetivos separados de RPO e RTO.
- Orçamente deteção, acesso, restauro e validação.
- Meça o ponto de dados utilizável mais recente.
- Ensaie num ambiente isolado.
- Registe lacunas e repita após alterações relevantes.
Os detalhes que importam.
O RTO é o mesmo que tempo de atividade?+
Não. O RTO é um objetivo de recuperação para um cenário de interrupção. O tempo de atividade mede a disponibilidade durante um período; um não estabelece o outro.
Uma cópia de segurança horária garante um RPO de uma hora?+
Não. Verifique cópias concluídas e utilizáveis e os requisitos de consistência da aplicação. Tarefas falhadas e transferências atrasadas podem alargar a lacuna de dados recuperáveis.
Todos os projetos devem utilizar um servidor de reserva?+
Escolha uma estratégia em função dos objetivos de recuperação do projeto e do processo de restauro medido. Um servidor de reserva acrescenta custo e complexidade operacional e não é automaticamente necessário.
Vá à fonte.
Estas referências sustentam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema de produção.
- NIST SP 800-34 Rev. 1: Guia de Planeamento de Contingência nvlpubs.nist.gov
- AWS Well-Architected: Defina objetivos de recuperação docs.aws.amazon.com
- Microsoft Learn: Continuidade empresarial, alta disponibilidade e recuperação de desastres learn.microsoft.com
Orientação editorial da SwissOctet. Os exemplos são ilustrativos. As especificações de serviço, as opções disponíveis e as condições contratuais devem ser verificadas separadamente.