Skip to main content
Erros acontecem: uma alteração de esquema ruim, linhas excluídas ou uma sessão do Agent que deu errado. O Replit oferece um caminho de recuperação para cada banco de dados.

​
Restaure seu banco de dados de desenvolvimento

Você pode revertar seu app e banco de dados de desenvolvimento para um estado anterior usando o recurso de rollback. Isso restaura seu banco de dados para qualquer checkpoint criado pelo Agent.
Interface de rollback de checkpoint mostrando opções de rollback
Certifique-se de selecionar “Database” em “Additional rollback options” ao restaurar para o estado de um checkpoint. Isso restaura seu banco de dados para o estado em que estava no momento do checkpoint.

​
Restaure seu banco de dados de produção

Para bancos de dados de produção, você pode restaurar para um momento específico usando a restauração pontual.
Interface de rollbacks de banco de dados mostrando opções de rollback
Até que ponto no passado você pode restaurar depende do seu plano e da sua configuração de retenção. O plano Core retém até 7 dias de histórico, enquanto os planos Pro e Enterprise retêm até 28 dias. Todo plano começa com 7 dias, e você pode alterar essa janela nas configurações do seu banco de dados de produção. Janelas mais longas usam mais armazenamento, então aumentar a retenção eleva seus custos de uso. Se você fizer downgrade do Pro para o Core, sua janela de retenção é reduzida para 7 dias.
Restaurar seu banco de dados não restaura o código do seu app, e fazer rollback do seu app não restaura seu banco de dados. Para trazer os dois de volta ao mesmo momento: restaure o banco de dados e depois faça rollback para o checkpoint correspondente e publique seu app novamente.

​
Agende backups do banco de dados de produção

Os backups agendados criam um ponto de restauração completo por dia. O Replit agenda o backup próximo à meia-noite no fuso horário atual do seu navegador quando você ativa ou atualiza a programação.
  1. Abra a ferramenta Database e selecione o banco de dados de produção.
  2. Abra Settings, depois expanda Scheduled backups em Advanced.
  3. Para ativar os backups agendados, selecione um período de retenção em Keep backups for.
Os períodos de retenção disponíveis dependem do seu plano. O Core suporta até 7 dias. Pro e Enterprise suportam até 28 dias.

​
Custos de armazenamento

O Replit mede cada categoria de armazenamento do banco de dados de produção separadamente:
Os custos de armazenamento do banco de dados estão atualmente com desconto de 100%.
A cobrança de $0.35 pelo armazenamento lógico se aplica independentemente de você usar PITR, backups agendados ou ambos. O armazenamento de backup agendado custa menos por GiB do que o armazenamento PITR. Se pontos de restauração diários atenderem às suas necessidades, backups agendados com uma janela de PITR mais curta podem reduzir os custos de armazenamento de recuperação. Seu custo total de backup depende do volume de backup armazenado e do período de retenção. O PITR oferece mais pontos de restauração dentro da sua janela. Os backups agendados oferecem um ponto de restauração por dia, então selecione o método de recuperação que atenda às suas necessidades.
A programação usa seu deslocamento UTC atual. Uma mudança de horário de verão pode deslocar o horário do backup em uma hora até que você atualize a programação. Fusos horários com deslocamentos fracionários usam a hora mais próxima.

​
Restaure um backup agendado

  1. Abra Scheduled backups nas configurações do banco de dados de produção.
  2. Selecione View all backups.
  3. Selecione Restore para o ponto de restauração desejado.
  4. Digite restore, depois selecione Continue.
A restauração alterna seu banco de dados para os dados do backup selecionado. Isso não exclui os dados atuais, mas os serviços conectados podem reconectar brevemente.

​
Solução de problemas em falhas de publicação

Se a publicação falhar devido a problemas de banco de dados:
  1. Verifique os logs de publicação para mensagens de erro específicas sobre conectividade do banco de dados ou conflitos de esquema
  2. Revise as alterações recentes de esquema para possíveis conflitos com o código existente da aplicação
  3. Teste suas alterações em uma prévia de implantação antes de tentar republicar

​
Próximos passos