Antes de propor outro jeito de fazer backup, precisávamos ver onde vai, de verdade, a noite de um servidor cPanel com centenas de contas. O que o JetBackup 5 faz, passo a passo, durante o backup noturno de um servidor cPanel?
371contas em 2h10, até 5 em paralelo (4 ou 5 em 88% do tempo)
87%do tempo é transferência; 13% é preparo, quase todo dump de banco
Por que isso importa para quem administra o servidor
- Uma noite de 2h10 para 371 contas é a janela em que os sites dividem o servidor com o backup e o storage recebe tudo. Quanto maior a janela, maior a chance de ela invadir o horário de uso.
- 87% do tempo é transferência: é ali que um backup novo precisa ganhar, mandando menos dados e dando menos trabalho ao storage. Os 13% de preparo são quase todos dump de banco.
- Saber o que falhou, e onde, é o que evita o chamado do dia seguinte: por isso o status do Salvo diz qual caixa, qual banco, qual tabela.
Mediana
47 s
90% das contas em até
190 s
A conta mais lenta
19,5 min
Fonte: observação passiva, JetBackup 5.4.1.4 · 13/10/2026
Ver os dados em tabela
| O que vimos | Valor | Detalhe |
|---|---|---|
| Contas na noite | 371 | 2h10, até 5 em paralelo |
| Limite de CPU | CPUQuota=200% | pelo systemd; carga perto de 11 |
| Status final | parcial | 17 contas: 16 com caixas sem senha (143 caixas, estado normal), 1 com erro real de banco |
| Dump de banco | --skip-lock-tables | sem --single-transaction |
| Dump antes do envio | .sql.gz | gravado no disco local |
| As 10 contas mais lentas | 22% | do tempo da noite |
Método
Observação passiva de um servidor cPanel em produção com cerca de 370 contas, JetBackup 5.4.1.4.
Durante 2h10, a cada 30 segundos, registramos processos, arquivos abertos, uso de disco e de rede: 266 amostras.
Nada foi gravado no servidor e nenhum processo foi rastreado com strace.
O que decidimos
O status do Salvo diz o que falhou (qual caixa, qual banco, qual tabela) e separa estado normal de erro real. E a cópia de bancos MySQL usa --single-transaction: dump que não chega ao fim é tratado como falha, não como backup.
O que ainda não sabemosÉ uma noite, num servidor. Outras configurações do JetBackup (destinos, agendas, limites) podem se comportar de outro jeito. Amostras a cada 30 s não pegam eventos curtos; os tempos por conta têm essa margem.
Quer ver o Salvo no seu servidor?Entre na lista de espera do beta. Avisamos quando houver vaga.
Como se liga aos outros laboratórios
Menos trabalho (IOPS) para o storage
1Um hardlink novo por arquivo, toda noite: por que o storage saturaLaboratório 04 · 14/10/2026~90Gravar no disco do storage foi tão rápido quanto jogar os dados foraLaboratório 05 · 15/10/2026166×O primeiro backup lado a lado: 45% menos tempo e 166× menos arquivos no storageLaboratório 14 · 16/10/2026152×O incremental logo depois: 152× menos leituras no disco do storageLaboratório 15 · 16/10/2026