O servidor caiu, ou alguém apagou as contas: o cliente quer o site WordPress de volta, e quer o e-mail inteiro, com as mensagens que ainda nem leu. Com contas reais de clientes (sites WordPress, lojas, caixas de e-mail de verdade), o que acontece quando se faz o backup, se perde tudo e se restaura, pelo JetBackup e pelo Salvo, no mesmo servidor e no mesmo storage?
Por que isso importa para quem administra o servidor
- E-mail é onde o cliente percebe primeiro. Receber a conta de volta sem as mensagens não lidas, sem o spam e sem a lixeira vira chamado no mesmo dia. No Salvo, as 19.667 mensagens voltaram; no JetBackup, faltaram 648, que não estavam no backup dele. Como conferimos cada arquivo e cada mensagem contra o original, em outras restaurações:Veja:Laboratório 16Laboratório 18Laboratório 19Laboratório 21
- Espaço: as mesmas 6 contas ocuparam 5,26 GB no Salvo e 6,70 GB no JetBackup, 21% a menos já no primeiro backup. E o backup terminou em 60 s, contra 98 s. Para entender de onde vem a economia: a compressão e um repositório por conta (Laboratório 02), o que não precisa de backup (Laboratório 10) e os 166× menos arquivos no storage (Laboratório 14).Veja:Laboratório 02Laboratório 10Laboratório 14
- 199 arquivos voltaram com dono ou permissão diferente no JetBackup, e nenhum no Salvo. Permissão errada é site WordPress com erro e cliente abrindo chamado.
- Onde o Salvo perdeu: a restauração. Uma conta por vez, esperando a carga do servidor baixar, ele levou mais tempo no relógio. Com 5 juntas, como o JetBackup, ficou perto no tempo, mas pesou mais no servidor. Está tudo abaixo, com o que já mudou no Salvo por causa disso. Não ficamos satisfeitos, e isso levou a novas melhorias. As opções novas vieram do Laboratório 21, e o passo seguinte está no Laboratório 24:Veja:Laboratório 21Laboratório 24
Como ler: cinza é o JetBackup, azul é o Salvo. É o primeiro backup das mesmas 6 contas, as duas ferramentas com 3 contas ao mesmo tempo, gravando no mesmo storage. O Salvo terminou 38 s antes e ainda ocupou 21% menos espaço (5,26 GB contra 6,70 GB).
Como ler: cada barra é a restauração das 6 contas. Azul é o tempo restaurando. Cinza é o Salvo parado de propósito: antes de cada conta, ele espera a carga do servidor baixar, para não pesar nos sites dos outros clientes. O JetBackup não espera: restaurou 5 contas juntas e levou a carga do servidor, que tem 8 núcleos, a 24,5. Da 2ª para a 3ª barra, as opções novas de leitura cortaram o tempo restaurando quase pela metade (19 min 06 s para 10 min 35 s); a espera cresceu porque essa rodada caiu no horário de mais uso do servidor.
Como ler: aqui o Salvo trabalhou como o JetBackup, 5 contas juntas e sem esperar a carga baixar. Ficou 59 s atrás e pesou mais no servidor: carga máxima de 37,3, contra 23,0, e 19 GB a mais de disco no pico, contra 7 GB. Por isso o Salvo não usa 5 juntas como padrão. Não ficamos satisfeitos com esses resultados. Eles nos levaram a repensar a forma de restaurar e a novas melhorias no Salvo, medidas com as mesmas 6 contas no Laboratório 24.Veja:Laboratório 24
| JetBackup | Salvo | |
|---|---|---|
| 1º backup das 6 contas (3 juntas) | 98 s | 60 s |
| Espaço no storage | 6,70 GB | 5,26 GB |
| Arquivos do cliente idênticos (125.661) | 99,45% | 99,98% |
| Mensagens de e-mail (19.667) | faltaram 648 | todas |
| Tabelas dos bancos do WordPress (321) | idênticas | idênticas |
| Arquivos com dono ou permissão diferente | 199 | 0 |
| Restaurar as 6, cada um no seu padrão | 309 s, 5 juntas | 635 s de trabalho + 833 s esperando a carga baixar, uma por vez |
| Carga máxima nessa restauração | 24,5 | 23,0 (o servidor já estava em 12) |
| Restaurar as 6, os dois com 5 juntas | 363 s | 422 s |
| Carga máxima, 5 juntas | 23,0 | 37,3 |
| Disco extra no pico, 5 juntas | +7 GB | +19 GB |
Método
Seis contas de um servidor de produção, copiadas para um cPanel de testes com 8 núcleos: duas pequenas (130 a 150 MB, site WordPress e banco), duas médias (~1 GB, WordPress, bancos, caixas de e-mail e vários domínios) e duas grandes (~3,2 GB, WordPress, até 3 bancos e de 10 a 18 caixas de e-mail).
Antes de tudo, um retrato de cada conta, que serviu de gabarito: o hash de cada arquivo, o checksum de cada tabela e as mensagens de cada caixa. São 125.661 arquivos do cliente (sites, arquivos enviados, mensagens e configuração das caixas), 321 tabelas e 19.667 mensagens. Os arquivos que o sistema recria sozinho (índices do e-mail, caches do painel, logs) ficam fora da conta.
Backup das seis pelo JetBackup e pelo Salvo, um depois do outro, as duas ferramentas com 3 contas ao mesmo tempo, no mesmo storage. O JetBackup rodou com a configuração de um job real, sem ajustes para o teste.
Depois, as seis contas foram apagadas e restauradas, comparando com o retrato a cada vez: pelo JetBackup (5 juntas, o padrão dele); pelo Salvo com as opções antigas e com as opções novas de leitura do storage (várias conexões, o backup trazido inteiro antes), uma conta por vez; e, por fim, as duas ferramentas com 5 contas juntas, uma logo depois da outra.
O servidor foi medido do começo ao fim de cada fase, a cada 2 segundos; o espaço no storage, ao fim do primeiro backup.
O que descobrimos e mudamos no Salvo durante o teste
Este laboratório não foi uma medição só: cada rodada mostrou alguma coisa, e o Salvo mudou no caminho. 1. Para montar o teste, era preciso restaurar 6 pacotes do cPanel de uma vez, e o Salvo não fazia isso. Passou a fazer: vários pacotes numa fila, pela tela, pela linha de comando e pela API. 2. A conferência depois da restauração avisava que faltavam mensagens quando o pacote guardava mensagens repetidas como hardlink. Era aviso falso: as mensagens estavam lá. Corrigido, com um teste automático para não voltar. 3. A fila mostrava a previsão de início mesmo quando estava esperando a carga do servidor baixar. Corrigido. 4. Restaurando uma conta por vez com as opções antigas, o Salvo gastou mais de 12 minutos só lendo o backup das 6 contas no storage. Com as opções que nasceram no Laboratório 21 (várias conexões e o backup trazido inteiro antes), a mesma leitura caiu para 40 segundos. O que sobrou é o tempo do painel recriando cada conta. 5. Mesmo assim, o relógio quase não mudou (25 min 08 s para 24 min 28 s): antes de cada conta, a fila espera a carga do servidor baixar, e essa rodada caiu no horário de mais uso. A espera foi maior que o próprio trabalho. 6. Pusemos então o Salvo nas mesmas condições do JetBackup, 5 contas juntas e sem esperar: 422 s contra 363 s, com carga de 37,3 e 19 GB a mais de disco. Não compensa. Não ficamos satisfeitos com esses resultados. Eles nos levaram a uma nova forma de restaurar e a mais melhorias no Salvo, que medimos com as mesmas 6 contas no Laboratório 24. O que não precisou mudar: em todas as rodadas do Salvo, as mensagens, os bancos e as permissões voltaram certos. O que faltou foi só o que a lista padrão de exclusões tira de propósito (25 arquivos .sql, .zip e .wpress guardados dentro do site, e pastas temporárias de plugins), e o JetBackup também tira esses.