Quando um cliente perde a conta inteira (site WordPress, banco e 13 caixas de e-mail, 10 GB), ele fica no telefone esperando. Medimos quanto tempo o Salvo levava para devolver essa conta no pior momento possível: a hora em que o storage de backup está mais ocupado, recebendo ao mesmo tempo os backups de vários outros servidores. O servidor da conta estava tranquilo; o gargalo era o storage. Resultado: 29 min 47 s. Não gostamos. Fomos atrás do motivo, melhoramos a restauração do Salvo em dois pontos e medimos de novo, com a mesma conta, na mesma hora.
| No pior momento do storage de backup | Antes das melhorias | Melhoria 1 (8 conexões) | Melhorias 1 e 2 (backup de uma vez) |
|---|---|---|---|
| Buscar o backup no storage | 26 min 57 s | 4 min 44 s | 2 min 39 s |
| O cPanel recriando a conta | 2 min 48 s | 2 min 57 s | 3 min 03 s |
| Da conta apagada à conta de volta | 29 min 47 s | 7 min 44 s | 5 min 45 s |
| Mais rápido que antes | — | 3,9× | 5,2× |
Método
Uma conta real: site WordPress com banco de 12 tabelas, 13 caixas com 15,5 mil mensagens e 24,9 mil arquivos. Cerca de 10 GB no storage e 11 GB depois de restaurada.
O backup fica num storage remoto, acessado por SSH, que também recebe o backup de outros servidores. As três restaurações rodaram na mesma hora, a de maior carga desse storage: a conta foi apagada e restaurada sem as melhorias; com a melhoria 1; e com as melhorias 1 e 2.
Antes e depois de cada restauração, um retrato completo da conta: o hash de cada arquivo, o checksum de cada tabela e as mensagens de cada pasta. Nas três, a conta do cliente voltou idêntica: 23.801 de 23.801 arquivos do cliente (site, arquivos enviados e mensagens), 100%, o banco com o mesmo checksum e o e-mail igual, caixa por caixa. As únicas diferenças estão nos arquivos que o sistema recria sozinho: índices do servidor de e-mail, caches do painel e cópias do banco do webmail que o painel renomeia com a data da restauração.
Como chegamos ao gargalo. Na primeira medição, o pacote de backup padrão do painel, que já estava no próprio servidor, voltou em 3 min 04 s; o Salvo, buscando o backup no storage remoto, levou 58 min 40 s, e 93% desse tempo era ler o storage. Com o storage sem aquela carga, caiu para 7 min 53 s, e multiplicar as leituras quase não ajudava. Foi aí que vimos a fila de uma conexão só.
O que mudamos no Salvo
Primeiro, olhamos para onde ia o tempo. O cPanel recriando a conta leva cerca de 3 minutos em qualquer cenário: esse é o piso, e não depende do Salvo. Os outros 27 minutos eram o Salvo buscando o backup no storage. A causa: ele conversava com o storage por uma conexão só, um pedido de cada vez, como uma fila de banco com um caixa aberto; na hora mais cheia do storage, cada pedido demorava mais, e a fila andava devagar. Melhoria 1, oito caixas abertos: o Salvo passou a buscar o backup por 8 conexões ao mesmo tempo. Só isso levou a conta de 29 min 47 s para 7 min 44 s. Melhoria 2, o backup vem inteiro, de uma vez: em vez de buscar os pedaços aos poucos enquanto restaura, o Salvo copia o backup da conta para o servidor numa leva só (110 s, a 91 MB/s) e restaura a partir dali. Chegamos a 5 min 45 s, sem usar mais disco no pico. Com as duas, a restauração no pior horário ficou mais rápida do que a melhor que tínhamos medido com o storage livre (7 min 53 s). As duas melhorias já estão no Salvo e foram medidas aqui; por enquanto ficam ligadas só nos testes, e o padrão continua sendo uma conexão até decidirmos. E o backup? Ele não ganha com as conexões a mais (74 s com 1, 110 s com 8): no backup, quem limita é ler e comprimir os dados no servidor.