Ainda preciso de um backup se tiver um sistema de armazenamento redudante com recursos de reversão?


32

Minha organização comprou recentemente um sistema de armazenamento. Possui 1,5 Petabyte, com RAID6, e há um espelho sincronizado online em um local físico diferente.

O sistema permite recuperação de arquivos / recuperação, por padrão, permitindo até 30 dias, mas isso pode ser aumentado.

Há uma discussão em andamento se precisarmos de algum tipo de backup extra para dados que residem apenas no armazenamento.

O sistema possui um nível muito bom de redundância, possui redundância geográfica e permite até certo ponto reversão, o que significa que podemos recuperar até o tempo definido (30 dias por padrão) dados antigos ou dados excluídos acidentalmente.

Dado esse cenário, ainda faz sentido ter um backup "tradicional"? Por tradicional, refiro-me a 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 apenas pensando da maneira tradicional e sendo zeloso?


Se também permitir replicar os instantâneos para outro dispositivo, você poderá superar os problemas mencionados por Sven em sua resposta.
Drifter104

4
Definitivamente relacionado, mas talvez não seja uma duplicata definitiva devido à capacidade de separação geográfica e reversão de instantâneo: Por que o RAID não é um backup?
um CVn

Contanto que você também remover a tecla "delete" de cada teclado no lugar, você é ouro ;-)
Tom Newton

1
Certamente melhor do que não ter isso. Eu ainda preferiria que os backups fiquem em um meio longe dos "erros de pessoas" ao vivo. Ainda assim, você sabe a resposta para sua pergunta, mas isso envolve colocar um preço em seus dados. Boa sorte.
Tom Newton

7
Seu recurso de "reversão" também cobre as alterações nos volumes? Por exemplo, ele poderá se recuperar se alguém remover todos os volumes?
vhu

Respostas:


40

O que você descreve é ​​essencial: um RAID geograficamente distribuído e um RAID nunca foi um backup .

A sincronização online geralmente significa que tudo que você faz no armazenamento primário é replicado imediatamente 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.


3
Ou, como os dois armazenamentos provavelmente usam o mesmo sistema operacional, um erro de software pode destruir os dados. Não provável, um erro de administrador é mais provável, mas possível.
Sunzi 6/10/2015

8
Verdade. O objetivo é que ninguém consiga gerenciar os instantâneos automatizados. Isso deve dar o nível de resiliência contra erros. Claro que também é possível excluir um backup por engano.
Nsn 6/10/2015

2
@nsn existem muitas outras falhas correlatas, como erros no software do dispositivo ou erros nos scripts de gerenciamento. Sem um backup em outro lugar, você está confiando seu trabalho ao fornecedor ... Você está disposto a fazer isso? Quantifique também o dano em caso de perda. Talvez a resposta dependa da importância dos dados. A empresa se foi sem ela?
usr

2
@ nsn > Claro que também é possível excluir um backup por engano. < - sim, mas fica substancialmente mais difícil quando o backup é colocado offline e colocado em armazenamento externo seguro, por exemplo.
quer

7

A reversão de 30 dias é uma excelente capacidade, mas e se "arquivo-xyz de importância crítica" ficar corrompido / danificado e isso não for detectado até mais de 31 dias depois? Essa situação é a diferença entre agendamentos de backup e arquivamento, mas na sua descrição o último não é mencionado. Os sistemas de arquivamento geralmente são armazenados em fita de custo muito baixo. 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 geralmente ocorre.

Se esse não for o seu caso, você deve ser bom.


3
Sim, verdade. O 30 é apenas o padrão, podemos definir outros valores. De qualquer forma, o armazenamento offline também custa dinheiro e não fica para sempre. Sempre haverá um dia n + 1
nsn

2
Eu gosto de ter 30 dias consecutivos, mais mensalmente no último ano e mais um ano. Eu tive vários arquivos (importantes e antigos) desaparecerem e não serão detectados dentro do período de rolagem. Os backups anuais podem salvar vidas.
Brian Knoblauch

@BrianKnoblauch: Sim, esse tipo de esquema é uma boa ideia, para instantâneos online ou backups offline.
Ben Voigt

6

Ter máquinas geograficamente separadas e ter os dados é bom.

O que acontece quando você tem várias falhas envolvendo ambos ou todos os seus sites? Um incêndio em um, roubo dos servidores no outro? Ou há um problema com a linha entre eles, o servidor do local principal apaga-se e o controlador HD ape e escreve lixo? Ou algum insider executa atos maliciosos em ambos? Ou o FBI confisca seus servidores nos dois locais por suspeita (você nunca, mas talvez esteja co-hospedado em um datacenter com idiotas). Ou ... Lembro-me de várias interrupções de alto nível na "nuvem", onde tudo era redundante, analisado até o enésimo grau, mas, ainda assim, as coisas podem dar errado. Concordo que tudo isso é improvável, mas você reconheceu que coisas improváveis ​​podem acontecer.

Então, tudo se resume à importância / valor desses dados? O que a organização fará se acabar?


3
Se você tem dois locais e perde os dois, provavelmente também perdeu seus backups. A maior parte dessa resposta é um argumento para replicação em mais de dois sites, não um argumento a favor do backup.
Ben

2
Isso vale para sempre. Cada vez que você adiciona um nível de redundância, sempre pode esperar que falhe (geográfico ou apenas discos). Se você tiver n discos redundantes, sempre poderá perguntar "e se n + 1 for interrompido". Você pode ter um incêndio na sua sala de servidores e na sua sala de backup também. Trabalhos internos também podem atacar os dois. Não existem sistemas 100% à prova de falhas. A questão aqui é saber se essa configuração pode ser equivalente a um servidor "tradicional" + backup
nsn 7/10/2015

1
Eu acho que o @nsn faz um grande ponto, mas também acho que a lição de muitas dessas respostas é que ter seu backup em uma infraestrutura tecnológica separada da mídia de armazenamento é uma boa ideia, porque dificulta muito o desenvolvimento tecnológico. falha na propagação e mais difícil para um ator malicioso infectar os dois (mas apenas mais difícil). Vemos regularmente erros em sistemas redundantes que causam cascatas de falhas. Ter uma solução / fornecedor diferente envolvido ajuda. Essa cobertura ainda continua, mas considero que esse nível de separação tecnológica é uma precaução razoável na maioria dos casos.
Nick

@ Nick, acho que você tem um comentário muito válido. Eu daria uma resposta.
Nsn 7/10

4

A pergunta aqui parece ser sobre o quão desconectada e geograficamente distinta uma cópia replicada dos 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 reunir algumas idéias 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 em Y, portanto não é um backup" e, em algum momento você precisa decidir o que é razoável para você, o que parece ser o motivo de você estar perguntando. Minha opinião sobre isso, e acho que muitos dos comentaristas, é que seu backup precisa existir em uma infraestrutura tecnológica separada dos 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 torta no céu, na minha opinião. Além disso, um exemplo do mundo real do meu trabalho. A universidade em que trabalho (mas felizmente não gerenciar esta infraestrutura para) possui uma infraestrutura de virtualização séria de alta disponibilidade que suporta muitas instalações do campus. Está em vários sites, mas está sendo executado na plataforma de um fornecedor. Um bug obscuro surgiu um dia que causou uma cascata de falha que derrubou primeiro um único servidor; depois, quando a carga mudou, ele removeu o restante do site e, quando a carga mudou novamente, removeu os outros sites que hospedavam essa infraestrutura. (Eu acredito que eles resolveram esse problema desde então). Os dados não foram perdidos nesse caso, mas é possível imaginar um cenário que envolva seus dados onde eles estavam. Um bug obscuro surgiu um dia que causou uma cascata de falha que derrubou primeiro um único servidor; depois, quando a carga mudou, ele removeu o restante do site e, quando a carga mudou novamente, removeu os outros sites que hospedavam essa infraestrutura. (Eu acredito que eles resolveram esse problema desde então). Os dados não foram perdidos nesse caso, mas é possível imaginar um cenário que envolva seus dados onde eles estavam. Um bug obscuro surgiu um dia que causou uma cascata de falha que derrubou primeiro um único servidor; depois, quando a carga mudou, ele removeu o restante do site e, quando a carga mudou novamente, removeu os outros sites que hospedavam essa infraestrutura. (Eu acredito que eles resolveram esse problema desde então). Os dados não foram perdidos nesse caso, mas é possível imaginar um cenário que envolva seus dados onde eles estavam.

Você deseja que seu backup seja imune a tudo isso e até acessível enquanto essa infraestrutura estiver inativa. Se os dados estiverem indisponíveis por uma semana enquanto o RAID for reconstruído, a recuperação de documentos críticos para os negócios a partir do backup é boa (embora não seja necessária). Se o seu RAID desaparecer e depois replicar para o outro site, você realmente desejará que o backup seja de um fornecedor separado ou de uma mídia isolada, como fita.

Tudo isso dito, repetirei novamente que seu backup deve estar em uma infraestrutura separada dos seus dados. Existem muitos níveis de isolamento aqui, mas acho que qualquer coisa conectada através da replicação direta está muito perto para ser um backup. Você vai querer algo além disso.


1

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 embutido pode substituir um sistema de backup tradicional.

MAS:

Prefiro que as políticas de recuperação sejam baseadas em aplicativos / dados e não em armazenamento porque:

  1. os aplicativos têm requisitos diferentes relacionados à recuperação e à perda aceitável de dados (alguns deles impostos por vários regulamentos: mídias somente leitura, criptografia, manter os últimos X anos etc.),
  2. alguns aplicativos têm (muito) boas ferramentas de backup e recuperação (oracle, mssql) integrados e são uma maneira recomendada de fazer a parte de backup / recuperação (como um DBA Oracle, eu prefiro e farei todos os meus backups relacionados ao Oracle com rman).
  3. crescimento, seu uso do espaço pode crescer muito mais rapidamente do que o esperado, agora esse sistema pode acomodar 30 dias de dados de reversão, o que não é garantido no futuro
  4. mais barato, o custo de usar fitas maiores para acomodar políticas de backup / recuperação, após vários anos de crescimento, será menor que o custo de comprar discos novos e maiores para respeitar a mesma janela de reversão de agora
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.