Sincronização do ZFS por WAN lenta e não confiável. Replicação do ZFS ou rsync?

Fui encarregado de fazer um backup externo funcionar através da WAN. Ambas as caixas de armazenamento são caixas NAS baseadas no FreeBSD executando o ZFS.

Uma ou duas vezes por semana, de 15 a 60 GB de dados fotográficos são jogados no NAS do escritório. Meu trabalho é descobrir como obter esses dados fora do local da maneira mais confiável possível, usando a conexão DSL MUITO LENTA (upload de ~ 700Kb / s). A caixa receptora está em uma forma muito melhor, com 30 Mb / s para baixo, 5 Mb / s para cima.

Eu sei, carregar um disco rígido fora do local moveria os dados muito mais rapidamente, mas não é uma opção nesse caso.

Minhas opções parecem ser:

• Envio incremental do ZFS pelo ssh
• Rsync

O rsync é uma solução consagrada pelo tempo e tem a capacidade essencial de retomar um envio se algo for interrompido. Ele tem a desvantagem de iterar sobre muitos arquivos e não saber sobre a desduplicação.

O envio de instantâneo do ZFS pode transferir um pouco menos de dados (ele sabe muito mais sobre o sistema de arquivos, pode fazer desduplicação, pode empacotar as alterações de metadados com mais eficiência que o rsync) e tem a vantagem de duplicar adequadamente o estado do sistema de arquivos, em vez de simplesmente copiar arquivos individualmente (o que consome mais disco).

Estou preocupado com o desempenho da replicação do ZFS [1] (embora esse artigo tenha um ano). Também estou preocupado em poder reiniciar a transferência se algo der errado - o recurso de instantâneo não parece incluir isso. Todo o sistema precisa ser completamente isolado.

[1] http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html

Usando qualquer uma das opções, devo poder priorizar a prioridade do tráfego, roteando-o através de uma porta especificada e, em seguida, usando o QOS nos roteadores. Preciso evitar um grande impacto negativo nos usuários dos dois sites durante cada transferência, pois isso levará vários dias.

Então ... esse é o meu pensamento sobre o assunto. Perdi algumas boas opções? Alguém mais criou algo semelhante?

1. Se você pode transferir um máximo de 6 GB por dia (assumindo zero sobrecarga e zero tráfego concorrente) e precisa mover "15-60 GB" com uma frequência de "uma ou duas vezes por semana", o que resulta em 15-120 GB por semana ou de 2 a 17 GB por dia. Como é necessário planejar o pico de demanda e 17 GB excedem até o máximo teórico de 6 GB, é provável que você tenha um problema muito sério de largura de banda. O que é necessário para atualizar a conexão? Se a atualização da conexão for impossível, considere a opção de enviar mídia física de forma programada (por exemplo, semanalmente).

2. Supondo que você consiga que a matemática da largura de banda faça um pouco mais de sentido, o rsync provavelmente será a melhor opção. A conscientização da redução de redundância seria extremamente valiosa ao replicar dados altamente redundantes (por exemplo, imagens de máquinas virtuais), mas deve ter pouco ou nenhum benefício quando se trata de conteúdo digital exclusivo (áudio, vídeo, fotos) ... a menos que, é claro, os usuários sejam inadvertidamente, armazenando cópias duplicadas de arquivos idênticos.

Depois de fazer algumas pesquisas, acredito que você está certo sobre o envio de instantâneos. O ZFS SENDe os RECEIVEcomandos podem ser canalizados para o bzip2 e, em seguida, esse arquivo pode ser sincronizado com outra máquina.

Aqui estão algumas fontes que eu usei:

• A página 211 do Guia do administrador do Oracle Solaris ZFS (ou versão da Web aqui ) começa a falar sobre isso.

• Eu também encontrei um post no blog que dava um exemplo simples disso. Este blog também mostrou canalizando o fluxo de bits através do bzip2 e enviando-o.

Não encontrei nenhuma postagem com scripts de replicação postados, mas encontrei alguém que postou o script de backup . Dito isto, eu não entendi, então pode ser lixo.

Muitos dos sites falaram sobre a configuração de um trabalho cron para fazer isso com freqüência. Se esse for o caso, você poderá replicar / fazer backup com menos impacto na largura de banda e nos usuários e ser um bom recurso de recuperação de desastre, porque os dados externos estão mais atualizados. (Ou seja, após o bloco inicial de dados ao iniciar.)

Mais uma vez, acho que você teve a ideia certa de enviar instantâneos. Parece haver muitas vantagens em usar SEND/ RECEIVE.

EDIT: Acabei de assistir a um vídeo1 vídeo2 que pode ajudar a apoiar o uso de SEND/ RECEIVEe fala sobre rsync (começa às 3m49s). Ben Rockwood foi o orador e aqui está um link para seu blog .

Qual é o objetivo dos backups e como eles precisam ser acessados?

Se seus backups são principalmente para recuperação de desastres, é preferível os instantâneos do ZFS, pois você poderá recuperar um sistema de arquivos no estado exato em que estava no momento do último incremental.

No entanto, se seus backups também devem fornecer aos usuários acesso a arquivos que podem ter sido excluídos acidentalmente, corrompidos etc., então o rsync pode ser uma opção melhor. Os usuários finais podem não entender o conceito de instantâneos ou talvez seu NAS não forneça aos usuários finais acesso a instantâneos anteriores. Em qualquer um dos casos, você pode usar o rsync para fornecer um backup que seja facilmente acessível ao usuário através do sistema de arquivos.

Com o rsync, você pode usar o sinalizador --backup para preservar os backups dos arquivos que foram alterados, e com o sinalizador --suffix, você pode controlar quantas versões antigas dos arquivos são renomeadas. Isso facilita a criação de um backup em que você pode ter versões antigas de arquivos como

file_1.jpg
file_1.jpg.20101012
file_1.jpg.20101008
etc.

Você pode combinar isso facilmente com um cronjob contendo um comando find para limpar todos os arquivos antigos, conforme necessário.

Ambas as soluções devem ser capazes de preservar informações suficientes sobre os arquivos para funcionar como backup (o rsync fornece sinalizadores --perms, --owner etc.). Eu uso o rsync para fazer backup de grandes quantidades de dados entre os datacenters e estou muito feliz com a instalação.

O ZFS deve receber o recurso 'envio retomado', que permitirá continuar uma replicação interrompida em algum momento por volta de março deste ano. O recurso foi concluído por Matt Ahrens e algumas outras pessoas e deve ser disponibilizado em breve.

Talvez o dispositivo de compressão WAN fosse uma solução ...? usamos o Riverbed e estamos muito felizes com eles (por exemplo, o NetApp SnapMirror está sendo muito bem compactado, de 80 a 90%)