Quando o backup demora, a primeira suspeita é o disco do storage, e a primeira resposta é comprar disco. Antes, vale saber onde está o gargalo de verdade. Quando o backup envia dados para o storage, o que segura a velocidade: a rede, a criptografia do SSH ou o disco do storage?
Por que isso importa para quem administra o servidor
- O disco do storage gravou tão rápido quanto jogar os dados fora (91 MB/s contra 89 MB/s). Neste caso, trocar disco não deixaria o backup mais rápido.
- O teto estava na conexão SSH, cerca de 90 MB/s cada. É isso que decide quanto tempo leva uma conta grande, e mostra onde mexer: o Laboratório 06 achou a causa.
Ver os dados em tabela
| Etapa | O que mede | Velocidade |
|---|---|---|
| Envio pelo SSH, descartado no destino | rede e criptografia, sem disco | 89 MB/s |
| Envio por SFTP, gravado no disco | o caminho completo | 91 MB/s |
| Cópia dentro do storage, forçando a gravação | o disco lendo e gravando ao mesmo tempo | 75 MB/s |
| Leitura dentro do storage | pode ter vindo do cache do ZFS | 154 MB/s |
Método
Origem: servidor cPanel de testes (CentOS 7, 18 núcleos). Destino: storage de backup com ZFS, numa máquina virtual na rede interna, com placas virtuais nas duas pontas.
Arquivo de 4 GB com dados aleatórios, para a compressão do ZFS não “ajudar” e o número sair honesto.
Horário sem nenhum outro backup gravando no storage; prioridade baixa no servidor de origem.
O que decidimos
Nada muda no destino: o disco do storage dá conta do envio. No teste de cache, uma conta de 5,7 GB foi copiada em cerca de 50 s (mais de 100 MB/s lidos) e coube abaixo desse teto porque o motor envia menos do que lê: pedaços iguais dentro da conta não são enviados de novo.