Backup rápido no teste e lento na vida real é a pior surpresa: o admin dimensiona a janela pelo teste, e o backup invade a manhã. Os incrementais rápidos dos outros testes aproveitaram arquivos que já estavam na memória do servidor. Como fica o backup do dia seguinte de verdade: de madrugada, horas depois do último acesso, com o cache do motor vazio?
Por que isso importa para quem administra o servidor
- De madrugada, a frio, horas depois do último acesso: 4 s para 21 mil arquivos. O tempo do teste vale para a noite de verdade.
- 301 arquivos lidos e 21.019 pulados sem abrir: o disco do servidor quase não trabalha, e os sites não sentem.
- A conta agendada tinha sido migrada, e o Salvo marcou a falha com o motivo. O admin descobre na hora, e não no dia em que precisa restaurar.
Ver os dados em tabela
| Tempo | Lido do disco | |
|---|---|---|
| Madrugada, tudo frio | 4 s | 105 MB (os arquivos que mudaram + a conferência) |
| Logo em seguida, disco quente | 2 s | 0 MB |
Método
Servidor cPanel de testes. Uma conta (13 mil arquivos, 762 MB) mais as configurações do sistema (8 mil arquivos), com o backup anterior feito três dias antes.
Rodou cerca de 7 horas depois do último backup noturno do servidor, com o cache do motor apagado antes, como no desenho do Salvo: o cache de cada conta é apagado ao fim do backup dela.
De 21.320 arquivos, só 301 foram lidos; os outros 21.019 foram pulados sem abrir, só conferindo tamanho e data.
O que aconteceu no caminho: o teste estava agendado para outra conta, que tinha sido migrada para outro servidor no dia anterior. O Salvo marcou a execução como falha, com o motivo (“a pasta não existe”), em vez de fingir que estava tudo certo. Refizemos com outra conta.
O que decidimos
O desenho continua o mesmo: o cache de cada conta é apagado ao fim do backup dela. Neste teste, isso não atrasou o backup do dia seguinte.