As metas de recupera\u00e7\u00e3o precisam fazer sentido para quem depende do sistema. Definir uma c\u00f3pia di\u00e1ria sem discutir a perda aceit\u00e1vel pode criar uma diferen\u00e7a importante entre o que a tecnologia entrega e o que o neg\u00f3cio espera.<\/p>\n
RPO expressa o objetivo de ponto de recupera\u00e7\u00e3o, associado \u00e0 perda aceit\u00e1vel de dados medida em tempo. Se uma opera\u00e7\u00e3o tolera perder no m\u00e1ximo uma hora de registros, a estrat\u00e9gia precisa ser desenhada e verificada para esse requisito. Isso n\u00e3o \u00e9 uma garantia obtida apenas ao preencher um hor\u00e1rio de backup.<\/p>\n
RTO \u00e9 o objetivo de tempo para recuperar o servi\u00e7o. Considere as etapas necess\u00e1rias: decis\u00e3o, acesso \u00e0s c\u00f3pias, transfer\u00eancia, inicializa\u00e7\u00e3o e valida\u00e7\u00e3o. O tempo de ligar uma m\u00e1quina \u00e9 apenas parte da recupera\u00e7\u00e3o de um processo.<\/p>\n
A Veeam apresenta RPO e RTO como objetivos diferentes e complementares. Ambos precisam ser definidos por aplica\u00e7\u00e3o e confrontados com a capacidade real de recupera\u00e7\u00e3o.<\/p>\n
Como exemplo hipot\u00e9tico, um sistema de consulta hist\u00f3rica e uma aplica\u00e7\u00e3o usada para registrar pedidos podem ter toler\u00e2ncias diferentes. N\u00e3o h\u00e1 motivo para adotar a mesma meta sem avaliar as consequ\u00eancias.<\/p>\n
Documente os objetivos e teste um cen\u00e1rio representativo. Se o resultado n\u00e3o atender, ajuste arquitetura, procedimento ou expectativa com a gest\u00e3o. A decis\u00e3o deve ser expl\u00edcita: metas mais exigentes podem demandar recursos e organiza\u00e7\u00e3o adicionais.<\/p>\n
Conhe\u00e7a as solu\u00e7\u00f5es de backup gerenciado da Descomplique<\/a> e converse com a equipe sobre as necessidades da sua opera\u00e7\u00e3o.<\/p>\nRefer\u00eancias<\/h2>\n