Com o DR, as coisas básicas são seus RTOs (Objetivos do Tempo de Recuperação) e RPOs (Objetivos do Ponto de Recuperação), que traduzem aproximadamente "quanto tempo é aceitável para gastar, e quantos dados podemos perder". Em um mundo ideal, as respostas seriam "nenhuma e nenhuma", mas um cenário de DR é uma circunstância excepcional. Eles devem ser orientados por seus clientes, mas, como você está começando pelo ângulo da TI, você pode adivinhar melhor, mas esteja preparado para se ajustar para cima ou para baixo conforme necessário. Apontar para o mais próximo de "nenhum e nenhum", como você pode razoavelmente obter é bom, mas você precisa ser capaz de reconhecer quando o ponto de retornos decrescentes entra.
Esses dois fatores podem ser diferentes em diferentes épocas do ano e diferentes em sistemas diferentes.
Eu gosto da abordagem mais completa; É tentador listar os eventos que podem levar a um cenário de recuperação de desastres, mas eles realmente pertencem mais a um exercício de análise / mitigação de riscos. Com DR, o incidente já aconteceu, e detalhes do que ele é são menos relevantes (exceto talvez em termos de afetar a disponibilidade de instalações de DR). Se você perder um servidor, precisará recuperá-lo, independentemente de ter sido atingido por um raio, acidentalmente formatado ou o que for. Uma abordagem centrada na escala e disseminação do desastre tem maior probabilidade de produzir resultados.
Uma abordagem para usar nos clientes, se você achar que eles estão relutantes em se envolver, é perguntar-lhes sobre o DR de um ângulo que não seja de TI. Perguntar quais são seus planos, se todos os seus arquivos em papel ficarem em chamas é um exemplo aqui. Isso pode ajudar a envolvê-los mais com o DR, e pode fornecer informações úteis aos seus próprios planos.
Finalmente, testar seu plano regularmente é crucial para o sucesso. Não adianta ter um belo plano de DR que pareça ótimo no papel, mas que não atenda aos seus objetivos.