Descrever o objetivo de tempo de recuperação e o objetivo de ponto de recuperação
É crucial entender os objetivos de ponto de recuperação e de tempo de recuperação para seu plano de HADR (alta disponibilidade e recuperação de desastres), pois eles são a base de qualquer solução de disponibilidade.
Objetivo de tempo de recuperação
O RTO (objetivo de tempo de recuperação) é o tempo máximo disponível para colocar recursos online após uma interrupção ou um problema. Se esse processo demorar mais do que o RTO, poderá haver consequências como penalidades financeiras, impossibilidade de realizar um trabalho etc. 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 de Ponto de Recuperação
O RPO (objetivo de ponto de recuperação) é o ponto no tempo em que um banco de dados deve ser recuperado e é igual à quantidade máxima de perda que a empresa está disposta a aceitar. Por exemplo, suponha que uma VM de IaaS contendo o SQL Server sofra uma interrupção às 10h e os bancos de dados dentro da instância do SQL Server tenham um RPO de 15 minutos. Não importa qual recurso ou tecnologia é usado para recuperar essa instância e seus bancos de dados, a expectativa é que haverá no máximo 15 minutos de perda de dados. Isso significa que o banco de dados pode ser restaurado para as 9h45 ou mais tarde para garantir uma perda de dados mínima ou ausente, cumprindo o que é declarado no RPO. Pode haver fatores que determinam se esse RPO pode ser atingido.
Como definir os objetivos de ponto de recuperação e tempo de recuperação
Os RTOs e RPOs são orientados pelos requisitos de negócios, mas também são baseados em vários fatores tecnológicos, entre outros, como as habilidades e as capacidades dos administradores (não apenas DBAs). Embora a empresa possa querer zero perda de dados ou nenhum tempo de inatividade, isso pode não ser realista ou viável por vários motivos. Determinar o RTO e o RPO da solução deve ser uma discussão franca e honesta entre todas as partes envolvidas.
Um dos aspectos cruciais para o RTO e o RPO é saber o custo do tempo de inatividade. Se você definir esse número e o efeito geral que ficar inativo ou não disponível tem sobre a empresa, ficará mais fácil definir as soluções. Por exemplo, se a empresa puder perder US$ 10.000 por hora ou puder ser multada por uma agência governamental se algo não puder ser processado, essa será uma forma mensurável de ajudar a definir o RTO e o RPO. O gasto na solução deve ser proporcional à quantidade ou ao custo do tempo de inatividade. Se a sua solução HADR custar US$ X, mas você acabar sendo afetado apenas por alguns segundos, em vez de horas ou dias em que um problema ocorrer, ela já terá se pago.
De um ponto de vista não empresarial, 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 é apenas tão boa quanto seu elo mais fraco. Por exemplo, se o SQL Server e os bancos de dados dele puderem ser colocados online em cinco minutos, mas os servidores de aplicativos levarem 20 minutos para ficarem online, o RTO geral será de 20 minutos, não de cinco. O ambiente do SQL Server ainda poderia ter um RTO de cinco minutos. Mesmo assim, isso não alterará o tempo geral de recuperação.
O RPO lida especificamente com os dados e influencia diretamente o design de qualquer solução de HADR, bem como os procedimentos e as políticas administrativas. Os recursos usados devem dar suporte ao RTO e aos RPOs definidos. Por exemplo, se os backups do 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, no pior caso, será de 30 minutos atrás. Esse tempo não pressupõe nenhum outro problema e os backups foram testados e são sabidamente íntegros. 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 alguma de que eles estejam íntegros. A execução de verificações durante o processo de backup pode oferecer algum grau de confiança.
Os recursos específicos usados, como um AG (grupo de disponibilidade) Always On 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 de IaaS ou de PaaS podem ou não fazer failover automaticamente para outra localização, o que pode resultar em um tempo de inatividade maior. Ao definir o RTO e o RPO, a solução técnica que dá suporte a esse requisito pode ser projetada sabendo as concessões de tempo e perda de dados. Se isso acabar não sendo realista, os RTOs e os RPOs deverão ser ajustados de acordo. Por exemplo, se houver um RTO desejado de duas horas, mas copiar o backup para o servidor de destino para restauração levar três horas, o RTO já estará perdido. Esses tipos de fatores devem ser contabilizados ao determinar seus RTOs e RPOs.
Deve haver RTOs e RPOs definidos para HA e DR. A HA é considerada um evento mais localizado do qual é possível se recuperar com mais facilidade. Um exemplo de alta disponibilidade seria um AG realizando failover automaticamente de uma réplica para outra dentro de uma região do Azure. Isso pode levar segundos e, nesse ponto, é preciso 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 potencialmente pode ser medido em minutos, dependendo da natureza crítica da solução ou do sistema.
A DR seria semelhante a ativar um data center totalmente novo. Há várias peças no quebra-cabeça, e o SQL Server é apenas uma delas. Colocar tudo online pode levar horas ou mais tempo ainda. É por isso que os RTOs e os RPOs são separados. Mesmo que muitas tecnologias e recursos usados para HA e DR sejam iguais, o nível de esforço e o tempo envolvido podem não ser.
Todos os RTOs e RPOs devem ser formalmente documentados e revisados de modo periódico ou conforme necessário. Depois que eles forem documentados, você poderá considerar quais tecnologias e recursos serão usados para a arquitetura.