Minha organização comprou recentemente um sistema de armazenamento. Tem 1,5Petabyte, com RAID6, e há um espelho sincronizado on-line em um local físico diferente.
O sistema permite a recuperação de rollback / arquivo, permitindo por padrão até 30 dias, mas isso pode ser aumentado.
Há uma discussão em andamento se precisarmos de algum tipo de backup extra para os dados que vivem apenas no armazenamento.
O sistema tem um nível muito bom de redundância, tem redundância geográfica e permite até certo ponto uma reversão, o que significa que podemos recuperar até o tempo definido (30 dias por padrão) dados antigos ou dados apagados acidentalmente.
Dado este cenário, ainda faz sentido ter um backup "tradicional"? Por tradicional, quero dizer um sistema de backup dedicado, com instantâneos que podemos recuperar caso algo dê errado.
Nós realmente precisamos disso? Estou esquecendo de algo? Estou pensando apenas no modo tradicional e sendo zeloso?
O que você descreve é essencial para um RAID geograficamente distribuído e um RAID nunca foi um backup .
A sincronização on-line geralmente significa que tudo que você faz no armazenamento primário é imediatamente replicado no sistema de backup, incluindo operações como a exclusão de (todos) instantâneos e / ou volumes por um invasor ou simplesmente um erro de administrador.
A reversão de 30 dias é uma ótima capacidade, mas e se "criticamente importante-file-xyz" se tornar corrompido / danificado e isso não foi detectado até 31+ dias depois? Esta situação é a diferença entre os cronogramas de back-up e arquivamento, mas em sua descrição o último não é mencionado. Os sistemas de arquivamento geralmente são armazenados em fitas de muito baixo custo. Além disso, não há informações disponíveis sobre se a empresa possui requisitos regulamentares ou outros para reter dados por mais de 30 dias, o que é frequentemente o caso.
Se este não for o caso da sua situação, então você deve ser bom.
Tendo máquinas separadas geograficamente, ambos os dados são bons.
O que acontece quando você tem várias falhas envolvendo todos ou todos os seus sites? Um incêndio em um, roubo dos servidores no outro? Ou há um problema com a linha entre eles, então o servidor do local principal se apaga, e o controlador HD fica apegado e escreve lixo eletrônico? Ou algum insider realiza atos maliciosos em ambos? Ou o FBI confisca seus servidores em ambos os locais por causa de suspeita (você nunca, mas, talvez, você seja co-hospedado em um datacenter com schmucks). Ou.. Lembro-me de várias falhas de "nuvem" de alto perfil, onde tudo era redundante, analisado em enésimo grau, mas, ainda assim, as coisas podem dar errado. Eu concedo a você que tudo isso é improvável, mas você reconheceu que coisas improváveis podem acontecer.
Então, tudo se resume a quão importante / valioso é esse dado? O que a organização fará se acabar?
A questão aqui parece ser sobre o quão desconectada e geograficamente distinta uma cópia replicada de seus dados precisa ser antes de ser uma infraestrutura de backup e não de alta disponibilidade / redundância. Meu instinto é que você está perto, mas ainda precisa de um backup.
Para juntar algumas ideias nas outras respostas e comentários, você pode ir muito longe no caminho de "bem, a tecnologia X não cobre o cenário de desastre do Y, então não é um backup", e em algum momento você precisa decidir o que é razoável para você, o que parece ser o motivo pelo qual você está perguntando. Meu sentimento sobre isso, e acho que o sentimento de muitos dos comentaristas, é que seu backup precisa existir em uma infraestrutura tecnológica separada de seus dados em uso para que falhas, acidentes e ações maliciosas não possam se propagar ou ter um obstáculo muito maior para atravessar. Um exemplo dado nos comentários é alguém excluindo os volumes, o que é um cenário válido, não para o céu, na minha opinião. Mas, além disso, um exemplo do mundo real do meu trabalho. A universidade em que trabalho (mas felizmente não gerencio esta infraestrutura) tem uma infraestrutura de virtualização séria e de alta disponibilidade que suporta muitas das instalações do campus. É em vários sites, mas está sendo executado na plataforma de um fornecedor. Um bug obscuro surgiu um dia que causou uma falha na cascata que primeiro derrubou um único servidor, então quando a carga mudou, ele removeu o resto do site, e quando a carga mudou novamente, ele removeu os outros sites que hospedavam essa infra-estrutura. (Eu acredito que eles resolveram essa questão desde então). Os dados não foram perdidos neste caso, mas é possível imaginar um cenário envolvendo seus dados onde eles estavam.
Você quer que seu backup fique imune a tudo isso, e até mesmo acessível enquanto essa infraestrutura estiver inativa. Se os dados ficarem indisponíveis por uma semana enquanto o seu RAID é reconstruído, é possível recuperar os documentos essenciais do negócio a partir do backup (embora não seja obrigatório). Se o seu RAID desaparecer e replicar para o outro site, você realmente desejará que o backup seja de um fornecedor separado ou em alguma mídia isolada, como fita.
Tudo isso dito, repetirei novamente que seu backup deve estar em uma infraestrutura separada dos seus dados. Há muitos níveis de isolamento aqui, mas acho que qualquer coisa conectada por meio de replicação direta está muito próxima para ser um backup. Você vai querer algo além disso.
Suposição: o sistema de armazenamento será usado por muitos aplicativos.
Eu considero que você fará muito melhor com um sistema de backup separado.
O RAID e o espelhamento não são de backup, mas o recurso de reversão interno pode substituir um sistema de backup tradicional.
MAS:
Eu prefiro que as políticas de recuperação sejam baseadas em aplicativos / dados e não em armazenamento porque: