Restaurar um banco
Traz de volta um banco MySQL de uma conta a partir de um backup: para um banco novo, ao lado do atual (o padrão), ou substituindo o atual. Também dá para trazer só algumas tabelas, ou restaurar só para conferir que o backup abre e depois apagar a cópia.
● disponível ● Só para testar e Apagar o banco restaurado: 0.4.175 ● Restaurar em fluxo: 0.4.201 cPanel e DirectAdmin (a partir de backup do JetBackup: só cPanel).
Na tela
Contas › a conta › o backup › o banco › Restaurar. Baixar .sql baixa o dump sem restaurar nada.
| Opção | O que faz |
|---|---|
| Para um banco novo (padrão) | cria o banco (sugestão: <banco>_restDDMM, com o prefixo da conta; no cPanel pelo painel, no DirectAdmin direto no MySQL, com acesso para os usuários da conta); o banco atual não é tocado; os mesmos usuários ganham acesso ao novo |
| Só para testar (só com Para um banco novo) | depois de conferir as linhas, o Salvo apaga o banco novo (o resultado fica no histórico). Só com o banco inteiro: se marcar algumas tabelas, fica desligada |
| Substituir o banco db | o conteúdo atual é trocado pelo do backup; marque Entendo que…. Antes, o Salvo guarda uma cópia de segurança comprimida do banco atual (em <estado>/safety); um banco apagado é recriado |
| Só estas tabelas (opcional) | marque as tabelas; as outras ficam como estão. Com Substituir, a cópia de segurança continua sendo do banco inteiro. Rotinas, eventos e views não voltam com tabelas |
Clique em Restaurar o banco (ou Restaurar as tabelas). A restauração abre com as tabelas e as linhas antes e depois. Com Só para testar, termina com Banco de teste apagado depois da conferência.
Em fluxo ou pela pasta de trabalho
Por padrão, o banco inteiro sai do storage e entra no MySQL ao mesmo tempo, sem passar pela pasta de trabalho, e a restauração mostra a tabela da vez (0.4.201). As etapas são Ler do backup e importar, Conferir as linhas de cada tabela e, com Só para testar, Apagar o banco de teste (0.4.207). Para voltar ao caminho antigo (exportar o banco inteiro para a pasta de trabalho e só depois importar): Configurações › Restauração › Restaurar banco em fluxo › Não › Salvar (0.4.202). Restaurar só algumas tabelas e restaurar de um backup do JetBackup usam sempre a pasta de trabalho.
Tabelas importadas ao mesmo tempo ao restaurar um banco (mesma tela, de 1 a 8, padrão 2; 0.4.204): na restauração em fluxo, as tabelas entram no MySQL por até este número de conexões ao mesmo tempo, cada uma usando um núcleo. Cada tabela MyISAM grande vai para uma conexão própria; as InnoDB ficam juntas numa só. 1 = uma tabela por vez. Mais conexões, mais carga no servidor durante a restauração.
Medido com o mesmo banco de 6,4 GB (94 tabelas), num servidor de 2 núcleos e 3,6 GB de RAM; todas as rodadas conferiram 94 de 94 tabelas, sem diferença de linhas:
| Como | Tempo | Pasta de trabalho no pico |
|---|---|---|
| Pela pasta de trabalho | 46 min 51 s | 14,3 GB |
| Em fluxo | 46 min 38 s | 0 |
| Em fluxo, refazendo o índice de uma tabela MyISAM grande uma vez só (0.4.203) | 30 min 35 s | 0 |
| Em fluxo, com 2 conexões (0.4.204) | 24 min 56 s | 0 |
Apagar o banco restaurado
Quando uma restauração para um banco novo termina e o banco continua no servidor, a restauração mostra O banco X continua no servidor com Apagar o banco restaurado. Ele pede confirmação (Apagar agora) e o código do app, e vai para a Auditoria. Só apaga o banco que a restauração criou, nunca o original nem um banco que já existia (no DirectAdmin, só banco com o prefixo da conta).
A partir de um backup do JetBackup
Os backups que o JetBackup deixou no storage são restaurados do mesmo jeito (só cPanel): Contas › a conta ›
Backups do JetBackup › o backup › Restaurar banco. As mesmas opções: Para um banco novo (sugestão:
<banco>_jb<DDMM do backup>), Só para testar, Substituir o banco e Só estas tabelas (opcional, uma por
linha) (0.4.176).
# os backups do JetBackup da conta (ID = o id do backup)
/var/lib/salvo/salvo jb-legacy-backups --account USUARIO
# só para testar, ou com --table T (repetível), ou --mode replace
/var/lib/salvo/salvo jb-legacy-restore-database --account USUARIO --backup ID --database BANCO --mode new --test
Pela linha de comando
# para um banco novo (o prefixo da conta é posto), só para testar: apagado depois da conferência das linhas
/var/lib/salvo/salvo restore-database --job ID --account USUARIO --database BANCO --mode new --target BANCONOVO --test
# para um banco novo, que fica
/var/lib/salvo/salvo restore-database --job ID --account USUARIO --database BANCO --mode new --target BANCONOVO --note "por quê"
# substituir o banco atual (antes, uma cópia de segurança); --execution N escolhe um backup mais antigo
/var/lib/salvo/salvo restore-database --job ID --account USUARIO --database BANCO --mode replace --execution N
# só algumas tabelas (repita --table)
/var/lib/salvo/salvo restore-database --job ID --account USUARIO --database BANCO --mode new --target BANCONOVO --table wp_posts --table wp_postmeta
# apagar o banco que uma restauração para banco novo criou (N = o número da restauração)
/var/lib/salvo/salvo restore-drop-database --restore N
# voltar ao caminho antigo (exportar para a pasta de trabalho e depois importar); sim religa o fluxo
/var/lib/salvo/salvo config --set restore_banco_fluxo=nao
# tabelas importadas ao mesmo tempo na restauração em fluxo (de 1 a 8, padrão 2)
/var/lib/salvo/salvo config --set restore_banco_conexoes=2
--testsó vale com--mode newe o banco inteiro: com--mode replaceé recusado.- Um banco restaurado que fica ocupa espaço no servidor e tem os mesmos usuários do original. Se era só para conferir, apague quando terminar.
- Um banco que o próprio Salvo apagou (Apagar o banco restaurado ou Só para testar) não gera o aviso de banco que sumiu da conta nos backups seguintes (0.4.177). Se algum backup pegou esse banco, ele continua restaurável até a retenção apagá-lo.