O storage enche de coisa que ninguém vai restaurar: cache de plugin do WordPress, logs, o backup do próprio site guardado dentro da conta. Quanto se economiza deixando de fora o que não precisa de backup (caches, logs, compactados e dumps antigos, backups de plugins), e de onde vem essa lista?
Por que isso importa para quem administra o servidor
- 35% menos lendo é 35% menos trabalho no disco do servidor durante o backup; 31% menos gravando é espaço que sobra no storage, noite após noite.
- O e-mail fica fora da lista: o que se economiza é o que ninguém restaura, não dado do cliente. E o admin edita a lista por job.
Ver os dados em tabela
| Sem exclusões | Com a lista padrão | |
|---|---|---|
| Arquivos | 157.827 | 142.162 (−9,9%) |
| Dados lidos | 6.269 MB | 4.064 MB (−35,2%) |
| Gravado no storage | 2.955 MB | 2.052 MB (−30,6%) |
Método
De onde vem a lista: 29 padrões recomendados pelo JetBackup, 16 acréscimos nossos (pastas do Magento, cache do LiteSpeed, lixeira, sockets do painel) e 1 exclusão fixa do JetBackup para o CloudLinux. São 46 padrões, editáveis pelo administrador em cada job, como no JetBackup.
Uma diferença de propósito: o JetBackup tira /mail da pasta da conta porque copia o e-mail em separado. O Salvo copia o e-mail junto com a conta, então o e-mail não entra na lista.
Servidor cPanel em produção. As mesmas 6 contas WordPress de cerca de 1 GB do Laboratório 09, 3 ao mesmo tempo, primeiro backup, medidas sem exclusões e com a lista padrão no mesmo dia. A comparação vale para os bytes; o tempo não é comparável, porque sem exclusões as contas rodaram em grupos diferentes. Com a lista, as 6 contas levaram 49 s.
O que decidimos
A lista vem ativa em todo job novo de contas cPanel; o administrador edita por job: tira, acrescenta ou volta ao padrão. Em jobs de pastas comuns (Linux sem painel), não vem nada por padrão.