Resposta curta: em servidores de hospedagem, o backup costuma ficar lento por causa do storage de backup, e não da CPU nem da rede. O método mais comum copia cada arquivo dos sites para o storage como um arquivo separado, toda noite. Um servidor com algumas centenas de milhares de arquivos faz o storage executar centenas de milhares de operações pequenas, e isso se repete a cada backup incremental. Criamos o Salvo para tirar esse trabalho: ele envia poucos pacotes grandes em vez de uma árvore de arquivos pequenos, e confere o que mudou no próprio servidor de origem, não no storage.
De onde veio o Salvo
Nós operamos servidores de hospedagem, e o nosso problema era o storage de backup: o conjunto RAID que recebe os backups de muitos servidores ficava saturado, e os backups demoravam demais. Cada servidor novo era mais carga num conjunto de discos que já estava no limite.
A resposta óbvia era comprar discos mais rápidos. Em vez disso, medimos para onde vai o tempo. A resposta não era o volume de dados. Era o número de arquivos e as operações que cada arquivo custa no storage.
O problema é só nosso?
Não. O fabricante da ferramenta de backup mais usada em hospedagem publicou a mesma história em 2018: um provedor fazendo backup de 150 servidores e mais de 15 mil contas cPanel num único destino. As anotações dele, em ordem:
- "Há um gargalo grande de IO e de rede. Todos os servidores rodando ao mesmo tempo estão claramente deixando o backup mais lento." Aumentaram a janela de 7 para 12 horas e limitaram a 20 servidores ao mesmo tempo.
- No storage, os discos estavam no limite, e todos os servidores rodavam
findoucp, que "consumiam a maior parte do IO dos discos". - A solução final foi hardware: cache de escrita em SSD na frente de um RAID 5 de 10 discos.
Administradores de hospedagem descrevem o mesmo em fóruns públicos: "nosso servidor de backup roda backup 24 horas por dia" e "o número de inodes pesa mais que o tamanho dos dados no tempo de backup".
Quanto um snapshot com hardlinks custa ao storage
O método comum, por arquivo (rsync com hardlinks), guarda no storage uma cópia de cada arquivo dos sites. Cada backup incremental monta um snapshot novo: uma pasta nova para cada pasta de cada conta e um hardlink para cada arquivo que não mudou. Para saber o que mudou, o rsync confere cada arquivo contra a cópia anterior no storage.
Ou seja, o storage faz um trabalho proporcional ao número de arquivos, toda noite, mesmo quando quase nada mudou. A retenção soma mais: apagar um snapshot antigo é desfazer centenas de milhares de entradas.
O que medimos
O mesmo servidor cPanel em produção, as mesmas 10 contas (cerca de 55 GB e 660 mil arquivos), o mesmo storage, cada ferramenta num volume próprio e vazio, medido a cada 5 segundos (Laboratório 14 e Laboratório 15):
| No storage | Snapshots com hardlinks (JetBackup, destino SSH) | Salvo |
|---|---|---|
| Arquivos e pastas criados no primeiro backup | 701.685 | 4.217 |
| Latência média de escrita no primeiro backup | 90 ms | 42 ms |
| Leituras no disco no incremental seguinte | 23.580 | 155 |
| Arquivos e pastas novos nesse incremental | +46.044 | +221 |
| Tempo desse incremental | 3 min 57 s | 1 min 28 s |
É no storage que a diferença é maior: 166× menos arquivos e 152× menos leituras no disco. Menos arquivos também significa menos para conferir e menos para apagar quando a retenção roda.
Como o Salvo evita esse trabalho
- Poucos pacotes grandes em vez de uma árvore de arquivos. O Salvo junta os dados da conta em pacotes antes de enviar. O storage recebe alguns milhares de objetos, não centenas de milhares.
- A conferência acontece no servidor de origem. O Salvo guarda a lista de arquivos do backup anterior e pula, sem abrir, os que os metadados mostram que não mudaram. No Laboratório 15, ele leu 369 de 662 mil arquivos. O storage praticamente só recebe gravação.
- Comprimido e cifrado antes de sair do servidor. Menos dados na rede e nos discos.
O que o Salvo custa em troca
Publicamos também o lado ruim. A compressão custa CPU no servidor de origem: com 3 contas grandes ao mesmo tempo, a carga chegou a 23 num servidor de 8 núcleos, contra 14 do JetBackup, e o Salvo usou até 1,3 GB de memória, contra 50 MB (Laboratório 14). O Salvo roda com prioridade mínima, então os sites passam na frente, mas a carga é real.
O que isso significa para os seus backups
Se o seu storage de backup vive ocupado, confira três números antes de comprar discos:
- Quantos arquivos os backups criam no storage por noite (não quantos GB).
- Quantas leituras no disco o storage faz num incremental em que quase nada mudou.
- Quanto tempo leva a limpeza da retenção.
Se esses números crescem com a quantidade de arquivos, o gargalo é o método, não o hardware.
Perguntas frequentes
Por que os backups do meu cPanel demoram tanto? Normalmente pelo número de arquivos, não pelo tamanho. O backup incremental por arquivo confere e cria um link para cada arquivo no storage, toda noite.
Discos mais rápidos resolvem? Ajudam, como mostra o caso de 2018, mas o trabalho por arquivo continua. Quando entram mais servidores, ele cresce de novo.
Existe alternativa ao JetBackup que reduza a carga no storage? O Salvo está sendo feito para isso, e foi pensado para rodar ao lado do JetBackup durante a transição. Ele está em desenvolvimento, com beta fechado a caminho; cada teste que fazemos é publicado no Laboratório, com o método e o que ainda não sabemos.
O Salvo está em desenvolvimento. Entre na lista de espera para testar nos seus servidores.
Fontes: Laboratório 14 · Laboratório 15 · "A true story of a mission impossible", JetApps no blog do cPanel, 2018 (arquivado) · Fórum do cPanel: "Worth switching to Jetbackup?" · LowEndTalk, 2024