Descrever o objetivo de tempo de recuperação e o objetivo de ponto de recuperação
Compreender o tempo de recuperação e os objetivos de ponto de recuperação são cruciais para seu plano HADR (High Availability and Disaster Recovery), pois eles são a base para qualquer solução de disponibilidade.
Objetivo de tempo de recuperação
O RTO (Recovery Time Objetive, objetivo de tempo de recuperação) é a quantidade máxima de tempo disponível para colocar os recursos online após uma interrupção ou problema. Se esse processo demorar mais do que o RTO, pode haver consequências, como sanções financeiras, trabalho que não pode ser feito, e assim por diante. O RTO pode ser especificado para toda a solução, que inclui todos os recursos, bem como para componentes individuais, como instâncias e bancos de dados do SQL Server.
Objetivo do ponto de recuperação
O RPO (Recovery Point Objetive, objetivo de ponto de recuperação) é o ponto no tempo para o qual um banco de dados deve ser recuperado e equivale à quantidade máxima de perda de dados que a empresa está disposta a aceitar. Por exemplo, suponha que uma VM IaaS contendo o SQL Server sofra uma interrupção às 10h00 e os bancos de dados na instância do SQL Server tenham um RPO de 15 minutos. Não importa qual recurso ou tecnologia seja usada para trazer de volta essa instância e seus bancos de dados, a expectativa é que haja no máximo 15 minutos de dados perdidos. Isso significa que o banco de dados pode ser restaurado para 9h45 ou posterior para garantir uma perda de dados mínima ou nenhuma reunião que o RPO declarado. Pode haver fatores que determinem se esse RPO é alcançável.
Definindo o tempo de recuperação e os objetivos do ponto de recuperação
RTOs e RPOs são impulsionados por requisitos de negócios, mas também são baseados em vários fatores tecnológicos e outros, como as habilidades e habilidades dos administradores (não apenas DBAs). Embora a empresa não queira tempo de inatividade ou perda zero de dados, isso pode não ser realista ou possível por vários motivos. Determinar o RTO e o RPO da sua solução deve ser uma discussão aberta e honesta entre todas as partes envolvidas.
Um dos aspetos cruciais para RTO e RPO é saber o custo do tempo de inatividade. Se você definir esse número e o efeito geral que estar indisponível ou indisponível tem para o negócio, é mais fácil definir soluções. Por exemplo, se a empresa pode perder 10.000 por hora ou pode ser multada por uma agência governamental se algo não puder ser processado, essa é uma maneira mensurável de ajudar a definir RTO e RPO. Os gastos com a solução devem ser proporcionais ao montante, ou ao custo, do tempo de inatividade. Se a sua solução HADR custa $X, mas você acaba sendo afetado apenas por alguns segundos, em vez de horas ou dias quando ocorre um problema, ele se pagou por si mesmo.
De um ponto de vista não comercial, o RTO deve ser definido em um nível de componente (por exemplo, SQL Server), bem como para toda a arquitetura do aplicativo. A capacidade de se recuperar de uma interrupção é tão boa quanto seu elo mais fraco. Por exemplo, se o SQL Server e seus bancos de dados puderem ser colocados online em cinco minutos, mas os servidores de aplicativos levarem 20 minutos para fazer o mesmo, o RTO geral será de 20 minutos, não de cinco. O ambiente do SQL Server ainda pode ter um RTO de cinco minutos; ainda não vai alterar o tempo total para recuperar.
O RPO lida especificamente com dados e influencia diretamente o design de qualquer solução HADR, bem como políticas e procedimentos administrativos. Os recursos usados devem suportar o RTO e os RPOs definidos. Por exemplo, se os backups de log de transações forem agendados a cada 30 minutos, mas houver um RPO de 15 minutos, um banco de dados só poderá ser recuperado para o último backup de log de transações disponível, que, na pior das hipóteses, seria há 30 minutos. Esse tempo não pressupõe outros problemas e os backups foram testados e são conhecidos por serem bons. Embora seja difícil testar cada backup gerado para cada banco de dados em seu ambiente, os backups são apenas arquivos em um sistema de arquivos. Sem fazer pelo menos restaurações periódicas, não há garantia de que sejam boas. Executar verificações durante o processo de backup pode lhe dar algum grau de confiança.
Os recursos específicos usados, como um Grupo de Disponibilidade Always On (AG) ou uma FCI (Instância de Cluster de Failover Always On), também afetarão seus RTOs e RPOs. Dependendo de como os recursos são configurados, as soluções IaaS ou PaaS podem ou não fazer failover automaticamente para outro local, o que pode resultar em um tempo de inatividade mais longo. Ao definir RTO e RPO, a solução técnica que suporta esse requisito pode ser projetada conhecendo as permissões para perda de tempo e dados. Se essas liquidações não forem realistas, os OIT e RPO devem ser ajustados em conformidade. Por exemplo, se houver um RTO desejado de duas horas, mas um backup levará três horas para copiar para o servidor de destino para restauração, o RTO já está perdido. Esses tipos de fatores devem ser levados em conta ao determinar seus RTOs e RPOs.
Deve haver RTOs e RPOs definidos para HA e DR. O AH é considerado um evento mais localizado que pode ser recuperado mais facilmente. Um exemplo de alta disponibilidade seria um AG automaticamente fazendo failover de uma réplica para outra dentro de uma região do Azure. Isso pode levar segundos e, nesse ponto, você precisaria garantir que o aplicativo possa se conectar após os failovers. O tempo de inatividade do SQL Server seria mínimo. Um RTO ou RPO local pode ser medido em minutos, dependendo da natureza crítica da solução ou do sistema.
DR seria semelhante a trazer um novo data center. Há muitas peças para o quebra-cabeça; O SQL Server é apenas um componente. Colocar tudo online pode levar horas ou mais. É por isso que os RTOs e RPOs são separados. Mesmo que muitas das tecnologias e recursos usados para HA e DR sejam os mesmos, o nível de esforço e tempo envolvido pode não ser.
Todos os RTOs e RPOs devem ser formalmente documentados e revisados periodicamente ou conforme necessário. Depois de documentados, você pode considerar quais tecnologias e recursos você pode usar para a arquitetura.