Backup e recuperação Melhores Práticas

Proposição de atividades e procedimentos como sendo as melhores práticas podem ser controversos, como sempre haverá exceções a uma regra, e sempre haverá sites e empresas que necessitam para realizar backups de forma diferente ao que é aqui proposto. O que permanece verdadeiro, porém, é que seguindo essas diretrizes é um bom ponto de partida para alcançar um ambiente de backup ideal.

Backup para recuperar

Não há realmente uma única razão que realizamos backup – para se recuperar. Todas as outras razões potenciais para backup são secundárias quando se trata de necessidade de realizar uma recuperação.

Como tal, isto significa que os sistemas de backup devem ser concebidos com a performance de recuperação em mente ao invés de simplesmente focando a quantidade de tempo que o backup vai demorar. Em ambientes com acordos de nível de serviço (SLAs), o projeto de um ambiente de backup deve realmente começar com a determinação que os SLAs de recuperação são, e então trabalhar para trás para um sistema de backup que pode proporcionar um desempenho tal, ao invés de assumir que o sistema de backup desenhado vai ser capaz de satisfazer as exigências de recuperação.

Como backups são feitos para se recuperar, por implicação isso também significa que deve haver testes adequados, monitoramento e proteção dos backups realizados.

Documentação

Sempre documentar o máximo possível em um sistema, e lembre-se sempre que os backups não negam a necessidade de documentação do sistema de recuperação (ou qualquer outra forma de documentação do sistema ou aplicativo).

Backup disponíveis e os procedimentos de recuperação para cada sistema protegido pelo ambiente de backup. Isto deve incluir procedimentos de recuperação de desastres que cobrem atividades para além das etapas de informática para uma recuperação, como qualquer outro procedimentos corporativos ou referências a documentação externa e sistemas de apoio podem ser potencialmente necessárias durante a recuperação. A documentação para cada sistema deverá ainda incluir detalhes de contato para os proprietários, os usuários-chave, e os administradores do sistema. Isto é útil não só em situações de recuperação, mas também para as ações administrativas em geral, tais como:

Notificação de backups com falha
Confirmando que as alterações previstas no procedimento de backup será aceitável
A confirmar se quer re-executar backups com falha
Confirmar se um novo contato está autorizado a fazer backup / recuperação de solicitações sobre o sistema (habilitação inadequada de pedidos de contactos anteriormente desconhecidos pode resultar em uma violação de segurança)

Proteger os backups

Backups não devem representar um ponto único de falha dentro de uma organização e, portanto, eles também exigem proteção – normalmente através de duplicação, de modo que se houver uma peça de mídia de backup falhar, os backups podem ser recuperados a partir de outra peça de mídia. Isso cria óbvias implicações na forma como um sistema de backup deve ser projetado – não só o sistema precisa ser projetado de tal forma que as recuperações e backups podem ser concluídas em tempo hábil, mas a duplicação de backups também deve ser concluído dentro de um tempo hábil também.

Normalmente há muito mais para proteger backups, no entanto, que apenas duplicar.

Questões como a seguir também devem ser considerados:

Se há uma diferença lógica ou funcional entre replicas e originais, cuja cópia é enviada fora do local?
São os backups off-site armazenado em um local que é suficientemente afastada da zona primária para não ser afetado pelas causas mais prováveis de falha ou desastre que poderia ocorrer no local primário
Fazer backups periodicamente o teste para garantir que eles podem ser recuperados a partir de? Se assim for:
O que é feito se um backup é testado e não conseguiu ser recuperado com sucesso?
A documentação de recuperação refletem os procedimentos utilizados para realizar as recuperações teste?
É um log tomada de backups que foram testadas?
Se backups não são testados periodicamente, por que não?
Quando a mídia de backup são movidos de local para local (por exemplo, offsiting fitas de backup), são os meios de comunicação devidamente protegidas de fatores ambientais como umidade, variações extremas de temperatura, etc?

A checagem dos resultados e relatórios

Sempre projetar um sistema com uma meta de zero falhas durante operações normais. Dessa forma, verdadeiros fracassos são facilmente detectados sem precisar peneirar através de falso-positivos em uma base diária. Isso auxilia no dia-a-dia das operações para o ambiente de backup, mas também garante que os novos funcionários podem facilmente se adaptar ao sistema e não precisam ser treinados no que é e não é um erro aceitável.

Se os resultados de backup não estão sendo verificados, assume falha 100 por cento. Como este não é obviamente um resultado desejado, ele deve destacar a necessidade de verificar os resultados de backup. Backups não são feitos para ser capaz de assinalar algumas caixas em um relatório diário dos deveres assumidos, mas têm um lugar sério para garantir a continuidade da empresa. Como tal, eles precisam ser tratados com seriedade e monitorados adequadamente, assim como qualquer outro sistema de chave em um ambiente.

Considerações sobre Core design

Particularmente quando se planeja um sistema de backup a partir do zero, sempre buscando atender as seguintes práticas de projeto do núcleo:

Centralize, sempre que possível – gestão de sistemas de backup corporativo é consideravelmente mais fácil quando um número mínimo de servidores principais estão em uso.
Ao escolher a tecnologia, software, e práticas, lembre-se que vanguarda é perfeitamente bem para um ambiente de backup, mas borda do sangramento devem ser evitados. (Se a decisão for feito para ir de ponta, tente lembrar-se quando ocorre uma falha que esta escolha foi feita – ou seja, documento e obter sign-off).
Manter o máximo do ciclo mais curto possível retenção na automatizado de manuseio de mídia unidades (bibliotecas normalmente fita). Por exemplo, se backups diários são mantidos por seis semanas, ter em vista que tamanho suficiente de armazenamento online para manter esta no mínimo. No entanto, mais do que esta capacidade é necessária e que deveria haver espaço para volumes em branco para ser usado para a duplicação, sobressalentes, volumes de recuperação, e um número adequado de volumes mensal / anual on-line também. Isso irá garantir que as recuperações são mais fáceis para facilitar.
Garantir todos entendam que backup é uma outra forma de seguro – especialmente quando os orçamentos precisam ser renovados.
Em um ambiente de backup com o crescimento de dados em curso, novas mídias normalmente deve ser visto como despesas operacionais, em oposição às despesas de capital. É muito importante lembrar que os preços de mídia quase sempre vir para baixo. Se prevê-se que o sistema vai exigir, por exemplo, 4.000 fitas ao longo de três anos, pode ser um erro caro que comprá-los todos no início da implementação. Em vez disso, sempre que possível, compre mídia para cobrir períodos de três a seis meses, no máximo, de modo que a vantagem pode ser tomada de preços em queda de mídia. (Se prestação de serviços de backup para vários departamentos, divisões ou clientes, será necessário atravessar a cobrar requisitos media com precisão.)
Em grandes organizações, dar atenção para um grupo de administração de armazenamento e de backup em vez de deixar tais considerações individuais com as equipes de administração do sistema operacional. Isto permite uma maior redução nos custos de gerenciamento de sistemas, e fornece mais consistência em regimes de proteção em toda a organização.
Evitar a “fantasia” extras, tais como verificação de vírus integrada, que desvia requisitos de backup do núcleo.
A data e a hora da ocorrência da falha
O host (s) associados, a diferenciação entre servidor, cliente e nó de backup remoto como apropriado
A mensagem de erro exata observado na falha
O que a resolução para o problema era, se o problema foi resolvido
Quaisquer atividades que ocorrem fora do software de backup (por exemplo, interrupções do sistema, falhas de hardware, etc) que podem ter tido um impacto sobre o sistema de backup e, portanto, pode ter desempenhado um papel na falha

Esta lista de monitoramento deve pelo menos ser capaz de ser classificadas por:

A data ea hora da falha (s)
O host (s) associado com a falha
A mensagem de erro (s) associado com a falha

Delinear claramente Papéis e Responsabilidades

Cada sistema terá vários papéis e responsabilidades e, como discutido no início do livro, um sistema de backup irá envolver um grande número de pessoas diferentes em uma empresa de uma forma ou de outra.

Duas das questões mais incapacitante pessoal que pode ocorrer com os sistemas de backup são disputas de domínio (onde diferentes pessoas acreditam que o seu “território” está a ser invadido) e atividade desconecta. Uma disputa de domínio, como foi discutido, é o lugar onde duas equipes discordam sobre quem é responsável por uma determinada atividade e, como resultado de atrito ocorre sempre que a atividade é executada. Uma atividade de desconexão é o lugar onde todo mundo achou que uma determinada tarefa era de responsabilidade de outra pessoa ou outro grupo e, portanto, não foi realizada.

A forma mais adequada para evitar estes cenários, e assim aumentar a eficácia do sistema de backup, é assegurar que toda a gente está formalmente ciente de suas funções e responsabilidades em relação ao sistema de backup. (Se isso significa ter um documento delegações formal, que assim seja.)

A Rede

A importância de uma rede em pleno funcionamento em um ambiente de backup corporativo nunca pode ser mais enfatizado, e, portanto, este assunto merece uma consideração especial em melhores práticas. Pelo “pleno funcionamento”, estamos nos referindo a:

Resolução de nomes completos e corretos entre todos os hosts, independentemente de qual método de resolução de nome é usado.
Uso da velocidade da rede forçado e configurações duplex onde suportado pela rede para reduzir o impacto da ‘autonegotation’ sob carga alta de backup.
Embora não diretamente relacionados com a rede por si só, com sincronização de tempo de funcionamento entre todos os hosts envolvidos na rede de backup irá resultar em um ambiente mais adequadamente integrado que pode ser totalmente invocado e mais facilmente depurado.

(Muitas vezes a implantação de sistemas de backup centralizado tem um benefício inesperado da fixação finalmente todos aqueles irritantes problemas de rede que foram pouco afetam os negócios por um longo período de tempo, mas em si nunca foram suficientes para justificar o tempo gasto para rastrear.)

Assegurar o sistema é suportado

É quase garantido que não importa quem a empresa emprega, eles não terão uma resposta para cada problema. Além disso, nem todo problema vai ser resolvido por um exercício de depuração – alguns problemas acabam por ser bugs no software ou falhas no hardware. Quando estes tipos de problemas surgem, ou problemas regulares se tornam muito difíceis de diagnosticar, é importante referir o problema para outra pessoa. Lembre-se que um sistema de backup é em muitos aspectos, a chave para o meio ambiente. Não ter contratos de suporte e manutenção no local para um servidor de backup pode resultar em qualquer, todos, ou até mais do que os seguintes cenários:

Ficando hardware atendidos sem um suporte ou contrato de manutenção pode resultar em um custo mais elevado para uma atividade de serviço único de todo o contrato de um ano – por exemplo, um cliente uma vez decidiu não gastar US $ 3000 por ano em manutenção de hardware para um stand-alone unidade de fita. Quando falhou nove meses depois que custou 3.300 dólares para um serviço one-off da unidade.
Equipe pode esgotar todas as vias de analisar um problema que ocorre com os backups e ainda não necessariamente encontrar uma solução. Não faz muito sentido para uma empresa a pagar centenas de milhares de dólares em apoio para servidores de produção primária, fornecendo suporte 24 / 7 de platina com tempos de resposta de uma hora, mas deixar tais sistemas irrecuperável devido a um problema no ambiente de backup que não pode ser escalado.
Pior do que o acima exposto, a equipe pode determinar que há uma correção para o conhecido software de backup que aborda os problemas encontrados, mas a manutenção para o software de backup não foi comprado, e, portanto, a empresa de software de backup escolhe a cobrar o custo total das licenças para ter acesso ao patch (efetivamente cobrar por novas licenças).

Um servidor de backup, seu sistema operacional, hardware, software, e respectivos dispositivos de backup remoto devem ser considerados

Até a próxima!