Fazer backup e mover o Weblate¶
Backup automatizado pelo BorgBackup¶
Novo na versão 3.9.
O Weblate tem suporte embutido para a criação de backups de serviços a usar BorgBackup. Borg cria backups encriptados, eficazes como espaço, que podem ser armazenados com segurança na nuvem. Os backups podem ser controlados na interface de gestão na guia Backups.
Alterado na versão 4.4.1: Both PostgreSQL and MySQL/MariaDB databases are included in the automated backups.
Os backups que usam o Borg são incrementais e o Weblate é configurado para manter os seguintes backups:
14 backups diários
8 backups semanais
6 backups mensais
Chave de criptografia do Borg¶
BorgBackup cria backups criptografados e sem uma palavra-passe não será capaz de restaurar o backup. A palavra-passe é gerada ao adicionar um novo serviço de backup e deve copiá-lo e mantê-lo num lugar seguro.
No caso de que esteja a usar Armazenamento de backup provisionado do Weblate, também faça um backup da sua chave SSH privada — é usada para acessar os seus backups.
Veja também
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 conectar-se ao serviço de nuvem e obter informações de acesso aos 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
Sistema de ficheiros local¶
Recomenda-se especificar o caminho absoluto ao backup local, por exemplo /caminho/para/backup. O diretório deve ser gravável pelo utilizador a executar o Weblate (veja Permissões do sistema de ficheiros). Caso não exista, o Weblate tentará criá-lo, mas precisa de permissões para fazê-lo.
Dica
Ao executar o Weblate no Docker, certifique-se de que o local de backup seja exposto como um volume do contentor Weblate. Caso contrário, os backups seriam descartados pelo Docker na reinicialização do contentor.
Uma opção é pôr backups no volume existente. Por exemplo, escolha /app/data/borgbackup. Este é o volume existente no contentor.
Também pode adicionar um novo contentor para os backups no ficheiro de composição do Docker e usar, por exemplo /borgbackup:
services:
weblate:
volumes:
- /home/weblate/data:/app/data
- /home/weblate/borgbackup:/borgbackup
The directory where backups will be stored have to be owned by UID 1000, otherwise Weblate will not be able to write the backups there.
Backups remotos¶
Há suporte para backups remotos a usar o SSH. O servidor SSH precisa ter BorgBackup instalado. O Weblate conecta-se ao servidor a usar uma chave SSH, então certifique-se de que a chave SSH do Weblate seja aceita pelo servidor (veja Weblate SSH key).
Dica
Armazenamento de backup provisionado do Weblate fornece backups remotos automatizados.
Restaurar do BorgBackup¶
Restaurar o acesso ao repositório de backup e preparar a sua palavra-passe de backup.
Liste o backup existente no servidor a usar
borg list REPOSITÓRIO.Restaure o backup desejado para o diretório atual a usar
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 (
backups/settings.py, veja Dados despejados para backups) até o local correto, veja Ajustar a configuração.Copie todo o diretório de dados restaurados para o local configurado por
DATA_DIR.
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 a adicionar weblate.I028 a SILENCED_SYSTEM_CHECKS em settings.py ou WEBLATE_SILENCED_SYSTEM_CHECKS ao 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 a usar 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 acabaria corrompendo os dados de alguma forma. Depois de instalar a mesma versão, execute todas as migrações do banco de dados a usar 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 é apagar essas entradas manualmente a usar 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 não queira. As secções a seguir descrevem em detalhes do que deve fazer backup e o que pode pular.
Dados despejados para backups¶
Armazenados em DATA_DIR /backups.
O Weblate despeja vários dados aqui e 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 Tarefas de fundo a usar o 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.
Os backups do banco de dados são gravados como texto simples por predefinição, mas também podem ser comprimidos ou totalmente ignorados a usar 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).
Tarefas do Celery¶
A fila de tarefas do Celery pode conter algumas informações, mas geralmente não é necessária para um backup. No máximo, perderá atualizações que ainda não foram processadas para a memória de tradução. Recomenda-se de realizar as atualizações de texto completo ou repositório ao restaurar de qualquer maneira, de modo que não há problema em perdê-las.
Veja também
Linha de comando para backup manual¶
Através de 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 as 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
Restaurar backup manual¶
Restaure todos os dados dos quais tenha feito backup.
Atualize todos repositórios a usar 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.