Servidor de armazenamento de backup com ZFS

Eu sou tudo de homem em uma pequena empresa. Quero projetar uma nova infraestrutura, incluindo um novo servidor e um servidor de backup separado com política de backup em toda a empresa.

A coisa mais importante na empresa é o SQL Server e seus bancos de dados. Existem 10 bancos de dados, mas apenas 2 deles são realmente importantes. O primeiro de 8 GB, principalmente dados e números de texto. O segundo, com cerca de 300 GB e 16 GB / mês, cresce com PDFs e GIFs.

Para salvar o armazenamento, a política de backup atual consiste em um backup completo por semana e 6 diferenciais. Eu acho que é de cerca de 350 GB por semana, 1,4 TB por mês.

Depois de ler artigos sobre corrupção de dados silenciosos, decidi experimentar o ZFS com o Nexenta Community edition.

Minha pergunta: o ZFS com desduplicação é bom para armazenar arquivos de backup em termos de confiabilidade ou devo pensar em algum backup em fita ou algo mais?

EDIT: Eu sei que, no momento, não podemos prever desempenho, taxa de deduplicação, etc., mas quero saber se é uma boa ideia.

Certamente o ZFS é bastante estável o suficiente para fazer esse tipo de coisa; existem muitas plataformas de produção confiáveis ​​e de alto perfil por aí baseadas inteiramente no ZFS e na Nexenta.

Dito isto, sempre gosto de ter backups baseados em disco no local, como o que você está sugerindo E backups baseados em disco ou fita removível que saem do site diariamente para proteger contra incêndio / terremoto / Cthulhu etc.

Então, minha resposta é sim, tudo bem, mas eu iria para as duas opções, se puder.

(supondo que você esteja se referindo ao uso de deduplicação no ZFS versus seu software de backup)

Eu não recomendaria o uso da deduplicação nativa do ZFS para o seu sistema de backup, a menos que você projete seu sistema de armazenamento especificamente para ele.

O uso da desduplicação no ZFS consome muita RAM. Como a desduplicação ocorre em tempo real, à medida que os dados são transmitidos / gravados no pool de armazenamento, há uma tabela mantida na memória que controla os blocos de dados. Esta é a tabela DDT . Se o seu servidor de armazenamento ZFS não tiver RAM suficiente para acomodar esta tabela, o desempenho sofrerá tremendamente. A Nexenta irá avisá-lo quando a tabela ultrapassar um certo limite, mas a essa altura já é tarde demais. Isso pode ser aumentado pelo uso de um dispositivo L2ARC (cache de leitura), mas muitos dos primeiros usuários do ZFS caíram nessa armadilha.

Vejo:

ZFS - a destruição do zvol desduplicado ou do conjunto de dados interrompe o servidor. Como recuperar?

ZFS - Impacto da falha do dispositivo de cache L2ARC (Nexenta)

Quando digo que o requisito de RAM é alto para usar a desduplicação, eu estimaria as necessidades de RAM e L2ARC para o conjunto de dados que você está descrevendo em 64GB + RAM e 200GB + L2ARC. Isso não é um investimento menor. Manter muitos arquivos do sistema Windows e documentos de imagem que não serão relidos, preencherá o DDT muito rapidamente. A recompensa pode não valer o trabalho de engenharia que precisa ser feito antecipadamente.

Uma idéia melhor é usar a compactação no zpool, possivelmente aproveitando os recursos gzip para os tipos de dados mais compactáveis. A desduplicação não valerá a pena, pois há um problema quando você precisa excluir dados desduplicados (precisa fazer referência ao DDT).

Além disso, como você apresentará o armazenamento para o seu software de backup? Qual pacote de software de backup você usará? Em ambientes Windows, apresento o ZFS como armazenamento em bloco no Backup Exec sobre iSCSI. Nunca achei que os recursos do ZFS CIFS fossem robustos o suficiente e preferi as vantagens de um dispositivo com formato nativo.

Além disso, aqui está um excelente recurso do ZFS para idéias de design. Coisas sobre o ZFS que ninguém lhe disse

Um sistema operacional alternativo é o OpenIndiana, que é igualmente bom e recebe atualizações mais frequentes algumas vezes.

Outra opção é configurar um segundo servidor ZFS com um pool de armazenamento menor (potencialmente) com a compactação ativada. Você pode usar este segundo dispositivo para backups estáticos. Assim, você pode dispensar o cache de leitura e também não precisa de quantidades tolas de CPU / RAM para lidar com isso.

Executamos uma instalação como esta onde trabalho:

• Servidor de armazenamento principal OpenIndiana [ principal ] com seis discos de 2 TB em um conjunto RaidZ1 de três conjuntos de pares espelhados. Isso reduz o espaço de armazenamento disponível, criando um pool de armazenamento rápido e com redundância múltipla.
• Um servidor de armazenamento secundário [ backup ] também executa o OpenIndiana com uma configuração semelhante de discos que serve apenas como um dispositivo de backup.
• main possui um script que é executado a partir de uma tarefa cron que captura instantaneamente / tank / [dataset] regularmente ao longo do dia
• Todas as noites, é executado outro trabalho cron que envia os instantâneos do dia pela rede para o backup . Depois que a sincronização inicial de todos os seus snapshots for concluída (um procedimento único), a natureza incremental dos snapshots significa que as alterações são enviadas ao seu dispositivo de backup muito rapidamente.

Tenho um rápido resumo de como montar o ZFS para enviar / receber aqui: http://kyrill-poole.co.uk/blog/tech/zfs-send-and-receive/