Atualmente, estou usando o método tradicional rsync + cp -al para criar backups incrementais / snapshots de nossa árvore de servidores. Os backups estão indo para um par de oito torres de disco conectadas à máquina de backup (uma máquina Sandy Bridge com 16 GB de RAM, rodando o CentOS 5.5) através de quatro conexões eSATA (quatro discos por conexão). Cada disco é um disco regular de 2 TB, portanto, temos 32 TB de espaço em disco conectado à máquina de backup. Estamos fazendo backup de cerca de 20 TB de dados nos servidores com isso.
O problema é que cada backup diário está demorando mais de 24 horas, eo tempo real killer não é o rsync real, mas o tempo que leva para executar um cp -al da árvore localmente na máquina de backup. Está demorando mais de 12 horas apenas para fazer a cópia de sombra da árvore, e tanto quanto eu posso dizer o backlog de performance está no disco (top mostra o cp usando muita memória RAM mas não muito CPU e principalmente ininterrupto estado de sono)
Temos os dados do servidor divididos em quatro volumes principais (e alguns menores), e cada um desses backups é executado em paralelo (com alguns deslocamentos no cron para tentar fazer com que alguns discos sejam feitos primeiro). Existem dois volumes na unidade de backup, ambos os volumes LVM distribuídos de 16 TB cada.
Então, obviamente, eu preciso melhorar o desempenho porque é inutilizável como está.
A primeira pergunta é: quando o CentOS 6 for lançado, com suporte para btrfs, a criação de snapshots de subvolumes com btrfs aumentará substancialmente esse desempenho?
O segundo é: existe uma maneira, com o ext3 ou qualquer outra coisa suportada no CentOS 5 ou 6, para 'encorajá-lo' a colocar os diretórios / inodes em uma parte de um volume (que poderia ser a parte que é em um SSD, via LVM) e os arquivos em outro? Isso presumivelmente resolveria o problema, mas não sei de maneiras de sugerir ext3 assim.