Fazer backup e mover o Weblate¶
Backup automatizado¶
Novo na versão 3.9.
Weblate has built-in support for creating service backups using BorgBackup. Borg creates space-effective encrypted backups which can be safely stored in the cloud. The backups can be controlled in the management interface on the Backups tab.
Aviso
Apenas o banco de dados PostgreSQL está incluído nos backups automatizados. Outros mecanismos de banco de dados devem ter seus backups criados manualmente. Recomenda-se migrar para o PostgreSQL, sendo o único banco de dados suportado na versão 4.0. Consulte Migrating from other databases to PostgreSQL.
Usar armazenamento de backup provisionado do Weblate¶
A abordagem mais fácil para fazer backup da sua instância do Weblate é comprar o serviço de backup em weblate.org. O processo de ativação pode ser realizado em poucas etapas:
Compre o serviço de backup em https://weblate.org/support/#backup.
Insira a chave obtida na interface de gestão, veja Integrando o apoio.
Weblate vai se conectar ao serviço de nuvem e obter informações de acesso para os backups.
Ativar a nova configuração de backup na guia Backups.
Faça backup das credenciais do Borg para conseguir restaurar os backups, veja Chave de criptografia do Borg.
Dica
Existe um passo manual a ativar para sua segurança. Sem o seu consentimento, nenhum dado é enviado ao repositório de backup obtido através do processo de registo.
Usar armazenamento de backup personalizado¶
Também pode usar o seu próprio armazenamento para backups. SSH pode ser usado para armazenar cópias de segurança no destino remoto, o servidor de destino precisa do BorgBackup instalado.
Veja também
General na documentação do Borg
Chave de criptografia do Borg¶
BorgBackup cria backups criptografados e sem uma palavra-passe você não será capaz de restaurar o backup. A palavra-passe é gerada ao adicionar um novo serviço de backup e você deve copiá-lo e mantê-lo num lugar seguro.
No caso de que esteja a usar Usar armazenamento de backup provisionado do Weblate, também faça um backup da sua chave SSH privada — ela é usada para acessar seus backups.
Veja também
Restaurar do BorgBackup¶
Restaurar o acesso ao repositório de backup e preparar sua palavra-passe de backup.
Liste o backup existente no servidor usando
borg list REPOSITÓRIO.Restaure o backup desejado para o diretório atual usando
borg extract REPOSITÓRIO::PACOTE.Restaure o banco de dados do despejo de SQL posto no diretório
backupno diretório de dados do Weblate (veja :ref:”backup-dumps”).Copie a configuração do Weblate e o diretório de dados para o local correto.
A sessão de Borg podia parecer com isso:
$ borg list /tmp/xxx
Enter passphrase for key /tmp/xxx:
2019-09-26T14:56:08 Thu, 2019-09-26 14:56:08 [de0e0f13643635d5090e9896bdaceb92a023050749ad3f3350e788f1a65576a5]
$ borg extract /tmp/xxx::2019-09-26T14:56:08
Enter passphrase for key /tmp/xxx:
Veja também
Backup manual¶
Dependendo do que deseja gravar, faça backup do tipo de dados que o Weblate armazena em cada lugar.
Dica
No caso de fazer backups manuais, pode silenciar avisos do Weblate sobre a falta de backups adicionando weblate.I028 a SILENCED_SYSTEM_CHECKS em settings.py ou WEBLATE_SILENCED_SYSTEM_CHECKS para o Docker.
SILENCED_SYSTEM_CHECKS.append("weblate.I028")
Banco de dados¶
O local de armazenamento real depende da configuração do seu banco de dados.
O banco de dados é o armazenamento mais importante. Configure backups regulares do seu banco de dados, sem o qual toda a sua configuração de tradução desaparecerá.
Backup nativo do banco de dados¶
A abordagem recomendada é de fazer o despejo do banco de dados usando ferramentas nativas, tais como pg_dump ou msqldump. Esta abordagem normalmente tem um desempenho melhor do que o backup do Django e restaura tabelas completas com todos os dados.
Pode restaurar esse backup na versão mais nova do Weblate, ele executará quaisquer migrações necessárias ao executar em migrate. Consulte Upgrading Weblate sobre informações mais detalhadas sobre como realizar a atualização entre as versões.
Backup do banco de dados do Django¶
Alternativamente, pode fazer backup do banco de dados pelo comando dumpdata do Django. Dessa forma o backup é agnóstico de banco de dados e pode ser usado caso queira alterar o backend do banco de dados.
Antes de restaurar, deve estar a usar exatamente a mesma versão do Weblate que foi usada ao fazer backups. Isso é necessário, pois a estrutura do banco de dados muda entre as versões e você acabaria corrompendo os dados de alguma forma. Depois de instalar a mesma versão, execute todas as migrações do banco de dados usando migrate.
Uma vez feito isto, algumas entradas já serão criadas no banco de dados e as terá no backup do banco de dados também. A abordagem recomendada é excluir essas entradas manualmente usando o shell de gestão (veja Invoking management commands):
weblate shell
>>> from weblate.auth.models import User
>>> User.objects.get(username='anonymous').delete()
Ficheiros¶
Se tiver espaço de backup suficiente, basta fazer backup de todo o DATA_DIR. Esta é uma situação segura, mesmo que inclua alguns ficheiros que você não queira. As secções a seguir descrevem em detalhes do que deve fazer backup e o que pode pular.
Dados despejados para os backups¶
Armazenados em DATA_DIR /backups.
O Weblate despeja vários dados aqui e você pode incluir esses ficheiros para backups mais completos. Os ficheiros são atualizados diariamente (requer um servidor de «beats» do Celery em execução, consulte Background tasks using Celery). Atualmente, isto inclui:
Configurações do Weblate como
settings.py(existe também a versão expandida emsettings-expanded.py).Backup de banco de dados PostgreSQL como
database.sql.
The database backups are by default saved as plain text, but they can also be compressed
or entirely skipped by using DATABASE_BACKUP.
Repositórios de controle de versão¶
Armazenados em DATA_DIR /vcs.
Os repositórios de controle de versão contêm uma cópia dos seus repositórios upstream com alterações do Weblate. Se tiver o push ao fazer commit ativado para todos os seus componentes de tradução, todas as alterações do Weblate são incluídas upstream e não precisa fazer backup dos repositórios no lado do Weblate. Eles podem ser clonados novamente dos locais upstream sem perda de dados.
Chaves SSH e GPG¶
Armazenados em DATA_DIR /ssh e DATA_DIR /home.
Se está a usar chaves de SSH ou GPG geradas pelo Weblate, deve fazer backup destes locais; caso contrário, vai perder as chaves privadas e terá que gerar outras novamente.
Ficheiros enviados pelo utilizador¶
Armazenados em DATA_DIR /media.
Deve fazer o backup dos ficheiros enviados pelo utilizador (por exemplo, Visual context for strings).
Linha de comando para backup manual¶
Usando uma tarefa de cron, pode configurar um comando bash a ser executado diariamente, por exemplo:
$ XZ_OPT="-9" tar -Jcf ~/backup/weblate-backup-$(date -u +%Y-%m-%d_%H%M%S).xz backups vcs ssh home media fonts secret
A cadeia entre aspas após XZ_OPT permite que escolha suas opções do xz, por exemplo, a quantidade de memória utilizada para compressão; veja https://linux.die.net/man/1/xz
Pode ajustar a lista de pastas e ficheiros às suas necessidades. Por exemplo, para evitar gravar a memória de tradução (na pasta backups), pode usar:
$ XZ_OPT="-9" tar -Jcf ~/backup/weblate-backup-$(date -u +%Y-%m-%d_%H%M%S).xz backups/database.sql backups/settings.py vcs ssh home media fonts secret
Tarefas do Celery¶
The Celery tasks queue might contain some info, but is usually not needed for a backup. At most you will lose updates that have not yet been processed to translation memory. It is recommended to perform the fulltext or repository updates upon restoring anyhow, so there is no problem in losing these.
Veja também
Restaurar backup manual¶
Restaure todos os dados dos quais tenha feito backup.
Atualize todos repositórios usando o
updategit.weblate updategit --all
Mover uma instalação do Weblate¶
Realoque a instalação de um sistema diferente, seguindo as instruções de backup e restauração acima.