Se você estiver hospedando seu próprio servidor, deve manter backups fora do local em caso de algum problema catastrófico com seu servidor. Imagine que seu provedor de servidor faliu um dia sem nenhum aviso, ou que você, de alguma forma, conseguiu deletar /var/discourse, apagando toda a sua instalação.
O Mínimo Necessário
Verifique se os backups estão ativados.
Configurações do Site a considerar:
enable backups: ligado (padrão: ligado)backup frequency: Quanto de dados você está disposto a perder? (Padrão: 7 dias). @pfaffman recomenda um diabackup time of day: Quando você deseja que seu fórum fique somente para leitura enquanto o backup é realizado?backup with uploads: Ligado, a menos que você armazene uploads em outro lugar ou os faça backup de outra forma. (Padrão: ligado)maxiumum backups: Quão paranoico você é? Quanto espaço em disco você tem? (Padrão: 5)
Isso permitirá que você restaure a partir de um backup recente caso seu banco de dados fique corrompido, mas não o protegerá se seu servidor Discourse desaparecer.
Backups Remotos
Para restaurar seu site em um novo servidor, no mínimo, você precisa do backup que o Discourse cria. Será muito mais fácil configurar um novo servidor se você tiver o(s) container(es) em /var/discourse//containers.
A forma exata de manter backups fora do local está um pouco além do escopo deste documento, mas um método é usar uma ferramenta como rsync para copiar os dados para um servidor remoto. Existem dezenas de guias sobre como fazer isso; encontre um que faça sentido para você.
Seu(s) arquivo(s) /var/discourse/containers muda(m) com pouca frequência, então fazer backup deles manualmente apenas quando você faz alterações não é tão doloroso. Eles geralmente contêm seu SMTP e plugins, que são razoavelmente fáceis de reconstruir de memória, mas você preferiria não ter que fazer isso em uma emergência. Se isso acontecesse, você ainda poderia colocar as coisas funcionando novamente, faltando alguns plugins e com o correio quebrado, e resolver o resto enquanto o site funciona com limitações.
Fazendo Backup para o S3
A maneira mais conveniente de manter backups fora do local é enviá-los para o S3, conforme descrito em Set up file and image uploads to S3. Se você fizer isso e mantiver suas configurações do S3 em algum lugar onde possa encontrá-las (ou no seu arquivo app.yml), poderá restaurar seu site diretamente do S3 quando tiver o novo servidor configurado.
É possível incorporar configurações no seu arquivo app.yml. Se você incluir algo assim na seção env do seu app.yml, essas configurações desaparecerão da interface web e você poderá Restore a backup from the command line sem precisar criar uma conta de administrador e fazer login.
DISCOURSE_S3_ACCESS_KEY_ID: 'key'
DISCOURSE_S3_SECRET_ACCESS_KEY: 'secret'
DISCOURSE_BACKUP_LOCATION: 's3'
DISCOURSE_ENABLE_S3_UPLOADS: true
DISCOURSE_S3_BACKUP_BUCKET: 'my-backup-bucket'
DISCOURSE_S3_REGION: 'us-west-1'
Se você também tiver uploads no S3 e confiar na estabilidade do seu provedor S3, poderia configurar o Discourse para fazer backup apenas do banco de dados (veja a configuração acima). Isso evitará que você armazene várias cópias de todos os seus uploads. Se optar por essa rota, você deve realizar uma restauração de teste para garantir que todos os seus uploads estão realmente no S3.
A Prática Leva à Perfeição
Embora ter uma cópia apenas do seu backup mais recente seja o mínimo necessário para restaurar em uma crise, se você quiser ter realmente certeza de que seus backups funcionam, deve testá-los pelo menos uma vez, se não periodicamente. Inicie um novo servidor e veja se consegue restaurar a partir de um backup.