O backup incremental está rodando de madrugada e o storage não dá conta: os backups de todos os servidores atrasam, e a restauração que alguém precisar naquela hora também. Por que um storage com discos mecânicos em RAID com paridade sofre na janela de um backup incremental feito com rsync e hardlinks?
Por que isso importa para quem administra o servidor
- O storage trabalha mesmo quando nada mudou: com rsync e hardlinks, cada arquivo que não mudou ganha um hardlink novo toda noite. Num servidor com centenas de milhares de arquivos, são centenas de milhares de escritas aleatórias, justamente o que RAID com paridade faz mal.
- Pela estimativa, um array de 6 discos aguenta cerca de 150 a 225 dessas escritas por segundo. Quando o storage satura, quem paga é a janela de backup de todos os servidores que gravam nele, e qualquer restauração na mesma hora.
Ver os dados em tabela
| Operação | Por segundo | Conta |
|---|---|---|
| Um disco mecânico | ~150 | referência |
| Leitura, 6 discos | ~900 | 6 × 150 |
| Escrita pequena, RAID 50 | ~225 | 900 ÷ 4 |
| Escrita pequena, RAID 60 | ~150 | 900 ÷ 6 |
Método
A comparação acontece no storage: para cada arquivo de cada conta, o rsync consulta tamanho e data no snapshot anterior. Milhões de consultas espalhadas pelo disco, toda noite.
Arquivo sem mudança também gera escrita: com --link-dest, cada arquivo inalterado ganha um hardlink novo no snapshot do dia, e o contador de links é atualizado.
A retenção repete o custo: apagar o snapshot mais antigo remove milhões de hardlinks.
A reindexação percorre a árvore inteira de snapshots: a mesma tempestade de leituras aleatórias.
O que decidimos
No Salvo, a decisão “mudou ou não” é tomada no próprio servidor de origem, com um índice em cache local; o storage não é consultado arquivo a arquivo. Ele recebe poucos arquivos grandes, gravados em sequência, que é a escrita que RAID com paridade faz bem. E não existe reindexação: o índice faz parte do repositório.