Restaurar

Restaurar um backup substitui seu banco de dados e arquivos de mídia atuais pelo conteúdo de um arquivo de backup. Restaure de um arquivo enviado, de um backup armazenado neste servidor, de uma cópia remota no DO Spaces, ou pela API.

O que é substituído

Uma restauração substitui:

o banco de dados
o diretório de mídia
arquivos de tema e templates de site, quando o backup os contém
metadados de tema, quando incluídos

A ação não pode ser desfeita, então a interface o avisa antes de qualquer coisa mudar e pede que você confirme.

De onde você restaura

Envie um arquivo de backup do formulário Restore from Backup na tela de Backups. O arquivo deve ser um arquivo .tar.gz de no máximo 50 MiB.

Restaure um backup local da lista de arquivos salvos no servidor, pelo seu botão Preview ou Restore. Os arquivos de backup locais são reconhecidos pelo padrão de nome chinaski_backup_<timestamp>.tar.gz.

Restaurar do DO Spaces , se o Spaces está configurado em Settings → Integrations, você pode restaurar de uma lista de backups remota. Numa instância air-gapped, a restauração remota está desabilitada.

Restauração por API , um endpoint permite que clientes com uma chave de API de escrita restaurom um backup local nomeado, incluindo a mesma prévia de dry-run que as telas de admin usam.

Sempre prévia primeiro

Clique em Preview (dry run) antes de restaurar. Um dry run lê o arquivo e reporta, sem mudar nada:

o tipo, data de criação, hostname e versão do CMS do backup
sua versão de schema comparada à sua atual , uma divergência é destacada e garante que a restauração abortará
o que o arquivo inclui (mídia, temas, templates de site)
o resultado de uma checagem de integridade no banco de dados do backup
quaisquer falhas de validação ou avisos de backup legado

Backups feitos por uma versão recente incluem um manifest de checksum. Se está presente, a restauração verifica cada arquivo dentro do arquivo contra seu checksum SHA-256 registrado; divergências abortam a restauração com “backup may be corrupted or tampered with”. Backups “legado” mais antigos restauram bem, mas avisam que os checksums não foram verificados.

Para backups enviados, a verificação executa contra o arquivo em estágio exato que você prévia, de modo que o que você confirma é o que é aplicado. Se novas prévias substituem aquele envio em estágio, a confirmação mais antiga é recusada.

O que é imposto

Estes portões executam antes de qualquer coisa ser mudada:

A versão de schema deve corresponder exatamente. Um backup de uma versão de schema diferente aborta a restauração inteiramente antes que qualquer coisa mude.
O arquivo deve conter o arquivo de banco de dados , qualquer coisa que não seja um backup Chinaski é recusada.
Os arquivos devem ficar dentro do arquivo. A extração percorre a lista de localizações e aborta se qualquer entrada tenta escapar do diretório de extração (truques de symlink ou path traversal).
Os checksums devem corresponder. Quando o arquivo carrega um manifest, cada arquivo listado é verificado por SHA-256.
Um timeout de 120 segundos aplica-se a downloads e extração; uma restauração que não termine no tempo é descartada em vez de aplicada com atraso.

O que é mostrado em sucesso, e o que você precisa fazer

Uma vez que uma restauração começa a aplicar, o banco de dados é substituído primeiro, de forma atômica. Então mídia, temas e templates de site seguem:

Numa restauração limpa você vê “Backup restored , database, media, and themes have been replaced”. As restaurações remotas/API dizem o mesmo e acrescentam: reinicie o serviço para recarregar o banco de dados. Reiniciar após qualquer restauração é uma prática sensata.
Se apenas o banco de dados restaurou mas a mídia não pôde ser trocada (raro, normalmente permissões), a mensagem diz para reexecutar a restauração e tentar de novo o passo de mídia.
Se a restauração de temas ou templates de site falhou enquanto todo o resto funcionou, o flash nomeia o que checar duas vezes.
Restaurações bem-sucedidas são registradas no audit log com a origem do backup.