Kinder, backups mais fáceis no linux

Question

No início desta semana, tive um momento de 'tempestade perfeita' em meus servidores: dois trabalhos de backup (um para cada matriz RAID10 no sistema) estavam funcionando durante 18 horas, e então nós tivemos um aumento sustentado no tráfego no meu aplicativo intensivo de E / S. O resultado foi um desempenho inaceitavelmente lento e precisei forçar nosso administrador a cancelar o backup. (Ele não estava feliz com isso ... não em todos. "Eu não sou responsável se ..." )

O resultado final foi muito estresse, clientes insatisfeitos e um Stu muito rabugento.

O gargalo foi a utilização do disco. Uma vez que os trabalhos foram cancelados, tudo estava funcionando bem. O que posso sugerir aos meus administradores para diminuir o impacto em meus servidores?

Aqui estão alguns dos detalhes:

O próprio comando de backup (eu tirei isto de ps , mas realmente não sei o que isso significa.)

bpbkar -r 1209600 -ru root -dt 0 -to 0 -clnt xtx-le00 -class F_Full_on_Thursday
-sched Incr_Fri_to_Wed -st INCR -bpstart_to 300 -bpend_to 300 -read_to 300 
-blks_per_buffer 127 -stream_count 8 -stream_number 8 -jobgrpid 223932 -tir -tir_plus 
-use_otm -use_ofb -b svr_1259183136 -kl 28 -fso

O sistema

• RHEL4 de 64 bits
• 4 GB de RAM (~ metade usada por aplicativos)
• DL380G5 com duas partições SAS RAID10 anexadas, ~ 550 GB e ~ 825 GB

Os dados

• 1TB

• ~ 10 milhões de arquivos

A aplicação

• ocupado das 09:00 às 23:00 nos dias úteis
• I / O intensivo (99% de leitura) focado principalmente em algumas centenas de MB de arquivos

Answer 1

Não tenho certeza de como o bpbkar funciona realmente, mas eu usaria o rsync para fazer backup de todos os arquivos fora do local e mantê-los em sincronia, o que consumiria muito poucos recursos, pois somente os arquivos alterados são atualizados. Naturalmente, isso significa que levaria algum tempo para o backup inicial, mas você já diz que esteve "cantarolando por 18 horas".

Você simplesmente gerenciaria os dados de backup da outra máquina como quisesse.

Edição pequena: Se você optar por se afastar dos backups em fita para os backups em disco, talvez queira usar o RAID6, que oferecerá paridade dupla.

    

Answer 2

Nós temos um sistema onde nós rsync servidores ao vivo para servidores de backup (que são construídos a partir de discos SATA 1TB baratos), em seguida, fazer backups de fita completos dos servidores de backup. É excelente:

• Chaves e - todas as vantagens de ambos os backups
• reduz consideravelmente a carga de IO nos servidores ativos
• restaura mais rapidamente se você quiser apenas um ou dois arquivos
• conjunto completo de fitas para o arquivo externo

Answer 3

Se os backups levarem 18 horas para serem executados normalmente, a priorização deles provavelmente não resolverá o problema (a menos que você queira executar seus backups por alguns dias por vez). Eu estaria inclinado a configurar um mecanismo de replicação de disco para outra máquina (eu gosto de DRBD, eu mesmo) e, em seguida, usar o LVM para tirar um instantâneo pontual, fazer backup e seguir em frente. Porque ele está sendo executado em uma máquina separada, (a) pode martelar tanto quanto quiser sem afetar o aplicativo ao vivo, e (b) não vai competir com o aplicativo ao vivo para o disco IO, o que significa que ele provavelmente executará um muito mais rápido também.

Uma coisa eu posso dizer com certeza: qualquer coisa que você fizer na mesma máquina vai encrencar completamente o seu cache de disco - como o processo de backup lê todos os dados do disco para backup (mesmo que ele apenas verifique mtimes em vez de ler e verificar todos os arquivos), ainda há muitos blocos de metadados em execução no seu cache, e eles expulham dados úteis do cache e causam mais IO de disco do que o permitido.

    

Answer 4

bpbkar é o cliente de backup Veritas Netbackups. Ele suporta otimização, portanto, a combinação de E / S normal e E / S de backup não satura seus discos. Olhe aqui:

link

Existe alguma coisa que o impeça de fazer backups completos no final de semana, já que o sistema está ocupado principalmente durante a semana e backups incrementais durante a semana? Isso ajudaria você a fazer o backup durante o intervalo entre 2300 e 0900

    

Answer 5

Outra votação para rsync . Eu uso para backup diário 9TB de um servidor de arquivos muito pesado usado. nunca tive um problema.

Se você estiver preocupado com 'point in time', crie um instantâneo LVM, mount, rsync, umount, destroy. Um pouco mais de carga no servidor, mas ainda muito (muito!) Menos tempo do que uma cópia completa.

Se o administrador disser que deve ser absolutamente, absolutamente bpbkar , primeiro faça um rsync em um sistema menos usado e execute bpbkar dele. Não há necessidade de monopolizar o seu sistema de produção.

Um anectode do teste: quando nos aproximamos do limite de 8TB do ext3, fizemos alguns testes de 'puxar o plugue' para determinar como é possível corromper um arquivo por falha de hardware durante a cópia. puxou o plugue do servidor, as caixas de armazenamento e a fiação do SAN. copiou dezenas de milhões de arquivos.

Conclusões:

• ext3 tinha em média um arquivo ausente a cada 10 falhas.
• O XFS calculou a média de menos de 5 erros por falha no armazenamento (quase zero para falhas no servidor) (fiquei surpreso !, achei que o XFS sempre falhava rapidamente e com dificuldade na falha de hardware)
• O JFS estragou centenas de arquivos a cada vez.

em suma, rsync funciona muito bem. Qualquer erro pode ser melhor atribuído ao seu hardware e / ou sistema de arquivos. bpbkar não teria um desempenho melhor diante das mesmas falhas.

    

Answer 6

A julgar pelo comando que você postou, e olhando para as opções -class e -sched, parece que você está executando um backup completo na quinta-feira - provavelmente não é o melhor plano considerando seu cronograma de uso (900-2300 dias da semana).

Com conjuntos de dados enormes como esse, você deve analisar o tempo do seu backup completo, além do tipo de backup incremental realizado durante a semana. Existem 2 tipos de backups incrementais no NetBackup:

• Incremental cumulativo - faz o backup de todos os arquivos alterados desde o último backup completo
• Diferencial Incremental - faz o backup de todos os arquivos alterados desde o último backup (completo ou incremental)

Eu consideraria mudar sua estratégia de backup para esse sistema para um backup completo no sábado ou domingo e backups incrementais diferenciais para o restante da semana. Isso executaria um backup completo quando houver tempo de sobra (nenhum / poucos usuários) e incrementos curtos nas poucas horas de pouco uso que você tem. O problema com esse método é que as restaurações podem ser um pouco mais complicadas - você precisaria de mais fitas - a fita para o preenchimento completo, além de todos os incrementais, desde o ponto completo até o ponto em que você precisa restaurar os dados.

Da sua pergunta, parece que você não está muito familiarizado com o sistema de backup. Eu entendo separando os sysadmins dos operadores de backup, mas alguma discussão precisa acontecer entre eles. Se os operadores de backup não tiverem ideia de como o sistema está sendo usado, eles não poderão formar uma política e programação adequadas para o sistema.

    

Answer 7

Faça com que os administradores do NetBackup programem melhor os backups - faça backups completos em semanas alternadas para cada matriz RAID.

Você também pode querer ver os backups completos sintéticos para não precisar fazer tantos backups completos.

    

Answer 8

Algumas sugestões:

1. Faça backups completos com menos frequência. Se os seus dados forem estáticos, você provavelmente conseguirá backups completos uma vez por mês a cada dois meses e backups incrementais cumulativos no restante do tempo. Você precisaria de 2 fitas em vez de uma, mas isso não seria um grande problema.
2. Agende melhor os backups. Com o netbackup, é possível solicitar que o servidor tente fazer backups em uma determinada frequência e em determinadas janelas, mas deixe-o agendar quando os backups reais começarem e terminarem. Isso geralmente usa a infraestrutura de backup de forma mais eficiente do que se você tentar agendar manualmente as coisas sozinho.
3. Faça com que o netbackup copie os backups para o disco primeiro e depois duplique essas imagens para a fita depois que o backup for concluído.

As outras sugestões de rsync também são boas - não há razão para que a cópia rsynced dos dados não seja tão boa quanto a imagem no servidor primário, a menos que seja um aplicativo de banco de dados. Se for um tipo de aplicativo de banco de dados, você deve copiar os logs de transações e as imagens de backup para outro sistema assim que eles forem criados e fazer backup deles.

Eu faria o backup dos dados no alvo do rsync para o netbackup, mas também faria o backup do sistema operacional e tudo menos os dados do programa (as coisas que ocupam espaço) nos alvos primário e rsync. Fazer o backup do sistema operacional e dos dados do programa deve ser fácil e rápido, e provavelmente deve estar em uma política de backup diferente.

    

Answer 9

Existem dois problemas em jogo - um é da sua arquitetura e o outro é da sua implementação.

Você pode otimizar facilmente sua implementação fazendo coisas como alterar janelas de backup ou fazer backups com menos frequência ou comprar discos ou redes mais rápidos ou unidades de fita ou duplicando os dados em outro sistema. Essas mudanças são válidas, apropriadas e, com a lei de Moore do seu lado, elas podem manter seu serviço funcionando adequadamente para sempre.

Você também pode estar se deparando com uma situação em que vai se deparar com problemas de dimensionamento cada vez com mais frequência. Se você está um pouco preocupado com o fato de que você pode estar tendo problemas de escalonamento cada vez mais freqüentes, você precisará pensar em como redesenhar seu sistema para torná-lo escalável melhor. Essas coisas não são fáceis, mas, como não são fáceis, você precisa planejá-las bem antes de ter uma arma na cabeça.

Um exemplo de ajuste de sua arquitetura pode envolver a movimentação de todos os seus dados para um sistema de tipo NAS, como um arquivador NetApp ou uma caixa executando Solaris e ZFS. Com uma configuração como essa, você faz backup do servidor, que será basicamente seu programa e configuração, e usa os recursos de gerenciamento de dados da SAN para fazer o backup da SAN. Estas seriam coisas como instantâneos e registros de transações contra o instantâneo.

Você também pode fazer algo semelhante ao que o archive.org faz onde você armazena os dados em muitos sistemas diferentes, geralmente qualquer dado de dados existe em vários sistemas, e então você tem um farm de sistemas front-end que rotas os pedidos para qualquer sistema realmente hospeda os dados.

Por fim - tem certeza de que seus backups funcionam? Executar um backup por 18 horas em um sistema ativo resulta em um backup que reflete esse sistema durante essas 18 horas. O ideal é que um backup reflita um sistema em um único ponto atômico no tempo, e não um backup maluco onde algumas coisas são de um ponto no tempo e outras são de quase um dia inteiro depois. Se algum de seus dados depender ou apontar para outras partes dos dados em outro lugar, essas dependências ficarão desordenadas caso os backups sejam intercalados, e com um conjunto de dados tão grande, é 100% provável que você tenha esse cenário, se for possível, em cada backup que você tem.