Fazendo backup e movendo o Weblate

Backup automatizado usando BorgBackup

Novo na versão 3.9.

O Weblate tem suporte embutido para criação de backups de serviços usando BorgBackup. Borg cria backups criptografados eficazes em termos de espaço que podem ser armazenados com segurança na nuvem. Os backups podem ser controlados na interface de gerenciamento na aba Backups.

Aviso

Apenas o banco de dados PostgreSQL está incluído nos backups automatizados. Outros mecanismos de banco de dados devem ter seus backups feitos manualmente. Recomenda-se migrar para o PostgreSQL. Consulte Migrating from other databases to PostgreSQL.

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

../_images/backups.png

Chave de criptografia do Borg

BorgBackup cria backups criptografados e sem uma senha você não será capaz de restaurar o backup. A senha é gerada ao adicionar novo serviço de backup e você deve copiá-lo e mantê-lo em um lugar seguro.

No caso de você estar usando Armazenamento de backup provisionado do Weblate, faça backup da sua chave SSH privada também — ela é usada para acessar seus backups.

Ver também

borg init

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:

  1. Compre o serviço de backup em https://weblate.org/support/#backup.

  2. Insira a chave obtida na interface de gerenciamento, veja Integrando suporte.

  3. Weblate vai se conectar ao serviço de nuvem e obter informações de acesso para os backups.

  4. Ative a nova configuração de backup na aba Backups.

  5. Faça backup das credenciais do Borg para conseguir restaurar os backups, veja Chave de criptografia do Borg.

Dica

O passo manual de ativar está lá para sua segurança. Sem o seu consentimento, nenhum dado é enviado ao repositório de backup obtido através do processo de registro.

Usando armazenamento de backup personalizado

Você também pode usar 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.

Ver também

General na documentação do Borg

Sistema de arquivos local

Recomenda-se especificar o caminho absoluto para o backup local, por exemplo /caminho/para/backup. O diretório deve poder ser escrito pelo usuário executando o Weblate (veja Permissões do sistema de arquivos). 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 contêiner Weblate. Caso contrário, os backups seriam descartados pelo Docker na reinicialização do contêiner.

Uma opção é colocar backups no volume existente. Por exemplo, escolha /app/data/borgbackup. Este é o volume existente no contêiner.

Você também pode adicionar novo contêiner para os backups no arquivo de composição do Docker e usar, por exemplo /borgbackup:

services:
  weblate:
    volumes:
      - /home/weblate/data:/app/data
      - /home/weblate/borgbackup:/borgbackup

O diretório onde os backups serão armazenados para serem possuídos por UID 1000, caso o contrário, Weblate não será capaz de escrever os backups lá.

Backups remotos

Há suporte para backups remotos usando SSH. O servidor SSH precisa ter BorgBackup instalado. O Weblate se conecta ao servidor usando 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.

Restaurando do BorgBackup

  1. Restaure o acesso ao repositório de backup e prepare sua senha de backup.

  2. Liste o backup existente no servidor usando borg list REPOSITÓRIO.

  3. Restaure o backup desejado para o diretório atual usando borg extract REPOSITÓRIO::PACOTE.

  4. Restaure o banco de dados a partir do despejo de SQL colocado no diretório backup no diretório de dados do Weblate (veja Dados despejados para os backups).

  5. Copie a configuração do Weblate (backups/settings.py, veja Dados despejados para os backups) até o local correto, veja Ajustando a configuração.

  6. Copie todo o diretório de dados restaurados para o local configurado por DATA_DIR.

A sessão dos Borg pode 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:

Ver também

borg list, borg extract

Backup manual

Dependendo do que você deseja salvar, faça backup do tipo de dados que o Weblate armazena em cada lugar.

Dica

No caso de você fazer backups manuais, você pode querer silenciar avisos do Weblate sobre a falta de backups adicionando weblate.I028 para 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 que toda a sua configuração de tradução tenha sumido.

Backup nativo do banco de dados

A abordagem recomendada é 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.

Você 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, você pode fazer backup do banco de dados utilizando o comando dumpdata do Django. Dessa forma o backup é agnóstico de banco de dados e pode ser usado caso você queira alterar o backend do banco de dados.

Antes de restaurar, você precisa estar usando 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 isso, algumas entradas já serão criadas no banco de dados e você as terá no backup do banco de dados também. A abordagem recomendada é excluir essas entradas manualmente usando o shell de gerenciamento (veja Invoking management commands):

weblate shell
>>> from weblate.auth.models import User
>>> User.objects.get(username='anonymous').delete()

Arquivos

Se você tiver espaço de backup suficiente, basta fazer backup de todo o DATA_DIR. Esta é uma aposta segura, mesmo que inclua alguns arquivos que você não quer. As seções a seguir descrevem em detalhes o que você deve fazer backup e o que você pode pular.

Dados despejados para os backups

Armazenados em DATA_DIR /backups.

O Weblate despeja vários dados aqui, e você pode incluir esses arquivos para backups mais completos. Os arquivos são atualizados diariamente (requer um servidor de “beats” do Celery em execução, consulte Tarefas de fundo usando Celery). Atualmente, isso inclui:

  • Configurações do Weblate como settings.py (existe também a versão expandida em settings-expanded.py).

  • Backup de banco de dados PostgreSQL como database.sql.

Os backups do banco de dados são, por padrão, salvos como texto simples, mas eles também podem ser comprimidos ou totalmente ignorados usando 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 de seus repositórios upstream com alterações do Weblate. Se você 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 você não precisa fazer backup dos repositórios no lado do Weblate. Eles podem ser clonados novamente a partir dos locais upstream sem perda de dados.

Chaves SSH e GPG

Armazenados em DATA_DIR /ssh e DATA_DIR /home.

Se você está usando chaves SSH ou GPG geradas pelo Weblate, você deve fazer backup destes locais; caso contrário, você vai perder as chaves privadas e você terá que gerar novamente as novas.

Arquivos enviados pelo usuário

Armazenados em DATA_DIR /media.

Você deve fazer o backup dos arquivos enviados pelo usuário (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, você perderá atualizações que ainda não foram processadas para a memória de tradução. Recomenda-se 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.

Linha de comando para backup manual

Usando uma tarefa de cron, você pode configurar um comando bash para 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

O texto entre aspas após XZ_OPT permite que você 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

Você pode ajustar a lista de pastas e arquivos às suas necessidades. Por exemplo, para evitar salvar a memória de tradução (na pasta backups), você 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

Restaurando backup manual

  1. Restaure todos os dados dos quais você tenha feito backup.

  2. Atualize todos repositórios usando o updategit.

    weblate updategit --all
    

Movendo uma instalação do Weblate

Realoque a instalação de um sistema diferente, seguindo as instruções de backup e restauração acima.