Existem backups, mas as restaurações raramente são testadas
Você não possui evidências recentes de quanto tempo leva uma restauração representativa nem se todas as dependências estão disponíveis.
Alta disponibilidade & recuperação de desastres
A recuperação deve ser um plano que sua equipe tenha testado.
Um trabalho de backup bem-sucedido e uma réplica íntegra são sinais úteis. A empresa precisa de uma resposta mais completa: quantos dados podem ser perdidos, quanto tempo a recuperação pode levar e quem pode restabelecer a aplicação. Ajudamos você a estabelecer e testar essa resposta.
Trabalhe diretamente com especialistas experientes em SQL Server.
Quando nos envolver
Você reconhece alguma destas situações?
Comece pelo problema que sua equipe está enfrentando. Você não precisa de um diagnóstico antes de entrar em contato.
O failover tem consequências inesperadas
O banco de dados é movido, mas aplicações, logins, trabalhos, listeners ou outras dependências não se recuperam como esperado.
A arquitetura se tornou difícil de explicar
Clusters, grupos de disponibilidade, envio de logs e infraestrutura de nuvem foram acumulados sem um plano atual de recuperação de ponta a ponta.
O que investigamos
Trate o problema por completo.
O escopo é adaptado ao seu ambiente, com as evidências e o método de acesso definidos no início.
Foco 01
Objetivos de recuperação e cenários de falha
Identifique as aplicações, a perda de dados aceitável, o tempo de inatividade aceitável e as falhas que a empresa espera que o projeto tolere.
Foco 02
Dependências do SQL Server e da infraestrutura
Analise, quando aplicável, grupos de disponibilidade, instâncias de cluster de failover, envio de logs, projeto de backup, dependências de rede, armazenamento, identidade e quorum.
Foco 03
Prática de restauração e failover
Projete um ensaio controlado que abranja a tomada de decisões, a recuperação do banco de dados, a validação da aplicação e as etapas necessárias para retornar à operação normal.
O que você recebe
Um resultado sobre o qual sua equipe pode agir.
Defina as entregas antes do início do trabalho. Quando incluída, a implementação segue seu processo de testes e mudanças.
Avaliação das lacunas de recuperação
Documente a diferença entre o resultado de recuperação necessário e as evidências disponíveis para o projeto atual.
Recomendações de arquitetura
Explique as opções adequadas, as dependências, os limites de falha, o esforço operacional e os motivos da recomendação.
Runbook de recuperação
Um plano sequenciado que abrange pré-requisitos, pontos de decisão, responsabilidades, validação e escalonamento.
Registro do ensaio
Resultados dos testes acordados, lacunas não resolvidas e ações necessárias antes de confiar no procedimento de recuperação.
Uma distinção prática
Planeje para as condições importantes.
A escolha técnica certa depende da carga e de como sua equipe a opera.
Inclua as pessoas e as dependências.
A recuperação pode depender de chaves de criptografia, identidade, configuração da aplicação, armazenamento, redes e acesso da equipe. Um ensaio útil verifica o caminho completo de volta a um serviço de negócio aceito.
Como o trabalho acontece
Um caminho claro das evidências à ação.
Você continua envolvido nas decisões e entende o raciocínio por trás das recomendações.
-
Defina os objetivos
Traduza as expectativas de negócio em cenários de recuperação e critérios de aceitação mensuráveis.
-
Analise o caminho completo
Acompanhe a recuperação desde os dados e as chaves, passando pelo SQL Server e pela infraestrutura, até a aplicação.
-
Ensaie com segurança
Defina o ambiente, a janela de mudança, o plano alternativo e os participantes antes de testar o procedimento.
-
Elimine as lacunas
Documente os resultados, atribua as correções e programe a próxima análise com os responsáveis pelo sistema.
Antes de começar
Perguntas que vale a pena responder.
Uma conversa direcionada ajuda a determinar se este serviço se adapta à sua situação.
A alta disponibilidade substitui os backups?
Não. Réplicas e infraestrutura redundante tratam determinadas falhas. Uma estratégia de recuperação também precisa de backups utilizáveis e de uma abordagem testada para corrupção, alterações acidentais e outros cenários de recuperação.
Vocês podem analisar um projeto Always On existente?
Sim. A análise pode abranger o projeto do SQL Server e suas dependências operacionais, incluindo comportamento de failover, conectividade da aplicação, monitoramento e procedimentos de manutenção.
Vocês podem garantir um tempo de recuperação antes dos testes?
Um objetivo de recuperação é um requisito, não uma evidência. O projeto, o volume de dados, a infraestrutura, as dependências e os resultados dos ensaios determinam o que pode ser atendido.
Serviços relacionados
Siga o problema até o próximo passo adequado.
Alguns problemas abrangem mais de uma parte do ambiente. Podemos combinar o trabalho relevante em um único escopo acordado.
Melhoria das operações de bancos de dados
Torne as boas operações repetíveis.
Comece aqui quando
Alertas demais, ações de menos.
Conheça a melhoria das operações de banco de dados
Migrações do SQL Server & atualizações
Mova a aplicação com um plano testado.
Comece aqui quando
Uma atualização ou mudança de infraestrutura está atrasada.
Conheça as migrações do SQL Server & atualizações
Conte-nos o que está impedindo o avanço.
Uma aplicação lenta, um incidente recorrente, uma mudança futura ou um processo que sua equipe deseja melhorar. Comece com uma breve descrição.