Um servidor caiu e é preciso pôr os sites WordPress de volta no ar. Quem manda é o relógio. No Laboratório 23, o Salvo trouxe tudo de volta, todas as mensagens inclusive, mas restaurou mais devagar que o JetBackup, e não ficamos satisfeitos. Este laboratório é o que veio depois: dá para restaurar uma conta inteira (site, banco e e-mail) mais rápido do que o pacote de backup do próprio painel, que já está no servidor? E várias contas ao mesmo tempo?
Por que isso importa para quem administra o servidor
- O relógio. Cada minuto de restauração é site WordPress fora do ar, e-mail parado e chamado aberto. Com 3 contas juntas, as 6 voltaram em pouco mais de 4 minutos; o JetBackup, na mesma janela, levou 14.
- Uma conta grande voltou mais rápido que o pacote do próprio painel, que já estava no servidor: 81 s contra 126 s numa conta de 3,2 GB. Sem esperar o storage e sem copiar tudo duas vezes.
- A confiança no que voltou. Restaurar rápido e perder e-mail não serve: em todas as rodadas do Salvo, todas as mensagens e todas as tabelas dos bancos voltaram iguais, conferidas uma a uma. Na mesma janela, o JetBackup deixou mensagens de fora em 4 das 6 contas, como já tinha feito no Laboratório 23.Veja:Laboratório 23
- O storage de backup. Para devolver as 6 contas, o JetBackup fez o disco do storage ler 192.900 vezes; o Salvo, com 3 juntas, 8.780 vezes: 22 vezes menos. Storage folgado aguenta os backups dos outros servidores na mesma hora. É o mesmo efeito que medimos no backup:Veja:Laboratório 04Laboratório 15
- O preço: mais restaurações juntas pesam mais no servidor. Com 3 juntas, a carga média foi 24,9, contra 18,4 do JetBackup, e o disco usou 8 GB a mais no pico, contra 1 GB. Por isso o padrão do Salvo espera a carga baixar antes da próxima conta, e o admin escolhe quantas rodam juntas.
- O caminho até aqui: a leitura do storage ficou rápida no Laboratório 21, e o Laboratório 23 mostrou onde ainda perdíamos.Veja:Laboratório 21Laboratório 23
Como ler: a linha cinza é o painel restaurando o próprio pacote; a azul, o Salvo. A altura é quanto o servidor grava no disco a cada segundo; o comprimento, quanto tempo levou. O painel terminou em 109 s. O Salvo criou a conta em 25 s e depois trouxe o conteúdo parte por parte, até 263 s, e ainda deixou coisas de fora. Gravou 10,7 GB no disco do servidor, contra 6,3 GB do pacote. Pior nas duas coisas.
Como ler: igual ao anterior. Agora o esqueleto vem pronto do backup, a conta existe em cerca de 20 s, e tudo voltou. Mas o conteúdo vinha para uma pasta ao lado e depois era movido para o lugar: o trecho do fim é mover 40 mil arquivos (66 s). O Salvo terminou em 152 s, contra 118 s do pacote, gravando 6,6 GB, contra 8,4 GB.
Como ler: igual aos anteriores. Assim que a conta existe, o Salvo grava o site e os e-mails direto no lugar, uma vez só, e importa os bancos ao mesmo tempo. Terminou em 81 s, contra 126 s do pacote, e gravou 6,0 GB no disco do servidor, contra 8,2 GB: o pacote do painel copia o conteúdo duas vezes.
Como ler: cada par é uma conta, do menor para o maior. Cinza é o pacote do painel, azul é o Salvo em duas trilhas, um logo depois do outro. Nas contas médias e grandes o Salvo ganha; nas pequenas, criar a conta já leva quase o tempo do pacote inteiro, e o painel empata ou ganha por alguns segundos.
Como ler: as 6 contas restauradas do storage, cada rodada logo depois da outra, na mesma janela. Nenhuma ferramenta esperou a carga do servidor baixar. O JetBackup trabalhou com 5 juntas, o padrão dele; o Salvo com 1, 3 e 6. Mais juntas termina antes, mas pesa mais no servidor (tabela abaixo). Nesta janela, o JetBackup foi bem mais lento do que de manhã, quando restaurou as mesmas 6 em 309 s:Veja:Laboratório 23
Como ler: cada ponto é quantas leituras por segundo o disco do storage de backup fez naqueles 10 segundos. Os quatro gráficos desta série usam a mesma escala. O JetBackup leu 7,6 GB do storage em 192.900 leituras, durante 14 minutos.
O Salvo, uma conta por vez: 4,6 GB lidos em 11.520 leituras, 17 vezes menos que o JetBackup, em 6 min 38 s.
O Salvo com 3 juntas, o padrão: 5,2 GB em 8.780 leituras, 22 vezes menos, em 4 min 11 s.
O Salvo com 6 juntas: 5,1 GB em 9.660 leituras, 20 vezes menos, em 2 min 58 s. Mais contas juntas não multiplicam as leituras do storage: o Salvo lê poucos arquivos grandes, em vez de muitos pedaços pequenos. Mais sobre o trabalho do storage:Veja:Laboratório 04Laboratório 15
| JetBackup 5 | Salvo 1 | Salvo 3 | Salvo 6 | |
|---|---|---|---|---|
| Tempo | 839 s | 399 s | 250 s | 179 s |
| Carga média | 18,4 | 18,2 | 24,9 | 30,9 |
| Carga máxima | 28,9 | 23,3 | 31,7 | 41,8 |
| Disco extra no pico | 1 GB | 6 GB | 8 GB | 8 GB |
| Leituras no storage | 192.900 | 11.520 | 8.780 | 9.660 |
| Lido do storage | 7,6 GB | 4,6 GB | 5,2 GB | 5,1 GB |
| Caixas iguais | 2 de 6 | 6 de 6 | 6 de 6 | 6 de 6 |
Método
As mesmas 6 contas reais do Laboratório 23, num cPanel de testes com 8 núcleos: duas pequenas (130 a 150 MB), duas médias (~1 GB) e duas grandes (~3,2 GB), 8,6 GB no total, com sites WordPress, bancos e caixas de e-mail.
Uma conta: cada tentativa do Salvo foi medida logo depois da restauração do pacote do próprio painel, na mesma janela, porque a carga do servidor mudava ao longo do dia. A conta foi apagada antes de cada rodada.
Várias contas: as 6 restauradas do storage, uma rodada depois da outra, na mesma janela. O JetBackup com o backup dele e 5 contas juntas; o Salvo com 1, 3 e 6. Para comparar, nenhuma das duas ferramentas esperou a carga do servidor baixar; o padrão do Salvo espera.
Depois de cada rodada, um retrato de cada conta contra o original: o hash de cada arquivo do cliente, o checksum de cada tabela dos bancos do WordPress e as mensagens de cada caixa. Em todas as rodadas do Salvo, 99,98% dos arquivos do cliente iguais; o que faltou é só o que a lista padrão de exclusões tira de propósito. O JetBackup ficou em 99,45%.
O servidor foi medido a cada 2 segundos durante todas as rodadas: carga, CPU e disco. Nas rodadas de várias contas, o disco do storage de backup também foi medido, a cada 10 segundos: leituras por segundo e volume lido. Fora das rodadas, o storage não fazia leitura nenhuma.
Como chegamos lá: o que tentamos e o que mudou no Salvo
O Laboratório 23 mostrou que a leitura do storage já estava resolvida. O tempo estava em copiar o site e os e-mails duas vezes: uma para montar o pacote do painel e outra quando o painel o restaura. A ideia: a conta nascer no painel só com o necessário (domínios, DNS, cron, contas de e-mail, usuários de banco) e, ao mesmo tempo, o Salvo trazer o conteúdo do backup e gravá-lo direto no lugar. Tentativa 1: o painel criou a conta a partir desse esqueleto em 25 s, mas trazer o conteúdo parte por parte levou 229 s e deixou coisas de fora: a caixa principal da conta, os arquivos padrão que o painel cria em conta nova e um banco de nome antigo. Mais lento que o pacote do painel (108 s) e incompleto. Tentativa 2: o esqueleto passou a ser guardado pronto no próprio backup (cerca de 10 MB), e a conta passou a existir em cerca de 20 s. O conteúdo vinha numa pasta ao lado e era movido para o lugar. Voltou tudo, mas levou 151 s, contra 118 s do pacote do painel: só mover os 40 mil arquivos levou 66 s. Tentativa 3: assim que a conta existe, o Salvo grava o site e os e-mails direto no lugar, uma vez só, e importa os bancos ao mesmo tempo. 80,6 s, contra 126 s do pacote do painel: 36% mais rápido, com o mesmo resultado. A conferência arquivo por arquivo achou dois defeitos do método novo, e os dois foram corrigidos antes das medições finais: arquivos do esqueleto que não voltavam por cima dos que o painel cria (133 de 140), e as caixas de um domínio antigo de uma conta com o grupo errado em dois arquivos, o que deixaria o e-mail dele fora do ar. Essa conta foi refeita depois da correção: 56 s, contra 68 s do pacote do painel. Com uma conta resolvida, várias juntas: 1, 3 e 6. O novo padrão é 3, o equilíbrio entre tempo e carga. Planejado: o Salvo escolher sozinho o caminho pelo tamanho da conta, porque nas pequenas o pacote do painel empata.