Efetuar cópias de segurança e mover o Weblate

Cópias de segurança de nível de projeto

Added in version 4.14.

O projeto efetua cópias de segurança de todo o conteúdo da tradução do Weblate (projeto, componentes, traduções, comentários de cadeia de carateres, sugestões ou verificações). É indicado para transferir um projeto para outra instância do Weblate.

You can perform a project backup in OperationsBackups. The backup can be restored when creating a project (see Adicionar projetos e componentes de tradução).

Os backups atualmente não incluem informações de controle de acesso e histórico.

The comments and suggestions are backed up with the username of the user who did create them. Upon import it is assigned to a matching user. If there is no user with such username, it is assigned to anonymous user.

Os backups gerados são mantidos no servidor conforme configurado por PROJECT_BACKUP_KEEP_DAYS e PROJECT_BACKUP_KEEP_COUNT (o padrão é manter no máximo 3 backups por 30 dias).

Import validation of uploaded project backups can be tuned using PROJECT_BACKUP_IMPORT_MAX_MEMBERS, PROJECT_BACKUP_IMPORT_MAX_TOTAL_UNCOMPRESSED_SIZE, PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_SIZE, PROJECT_BACKUP_IMPORT_MIN_RATIO_SIZE, and PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_RATIO.

Utilize o ficheiro gerado para importar o projeto quando Adicionar projetos e componentes de tradução ou em import_projectbackup.

Nota

O restauro da cópia de segurança pode falhar se o servidor de restauro tiver um conjunto diferente de Definições de idioma ou uma configuração diferente de SIMPLIFY_LANGUAGES. O restauro irá informar quais os códigos de idioma que não puderam ser processados e depois pode adicionar manualmente as definições de idioma em falta.

Backup automatizado pelo BorgBackup

O Weblate tem suporte integrado para a criação de cópias de segurança do serviço utilizando BorgBackup. Borg cria cópias de segurança encriptadas eficazes em termos de espaço que podem ser guardadas com segurança na nuvem. As cópias de segurança podem ser controladas na interface de gestão no separador Cópias de Segurança.

Alterado na versão 4.4.1: PostgreSQL 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:

  • Cópias de segurança diárias para 14 dias

  • Cópias de segurança semanais para 8 semanas

  • Cópias de segurança mensais para 6 meses

../_images/backups.webp

Chave de encriptação Borg

BorgBackup cria cópias de segurança encriptadas e não conseguiria restaurá-las sem a frase-passe. Esta é gerada quando adicionar um novo serviço de cópias de segurança e deveria copiá-la e mantê-la num lugar seguro.

Se estiver a utilizar Armazenamento da cópia de segurança provisionado do Weblate, por favor, efetue também uma cópia de segurança da sua Chave SSH privada, porque esta é utilizada para aceder às suas cópias de segurança.

Veja também

borg init

Personalizando a cópia de segurança

  • A cópia de segurança da base de dados pode ser configurada via DATABASE_BACKUP.

  • A criação da cópia de segurança pode ser personalizada utilizando BORG_EXTRA_ARGS.

Armazenamento da cópia de segurança provisionado do Weblate

A forma mais fácil de fazer backup da sua instância do Weblate é comprar o serviço de backup em weblate.org. É assim que o faz funcionar:

  1. Compre o Serviço de Cópias de Segurança em https://weblate.org/support/#backup.

  2. Insira a chave obtida na interface de gestão, veja Integrando o apoio.

  3. Weblate se conecta ao serviço de nuvem e obtém informações de acesso para os backups.

  4. Ative a nova configuração de backup a partir da guia Backups.

  5. Faça backup das suas credenciais do Borg para conseguir restaurar os backups, veja Chave de encriptação Borg.

Dica

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

Utilizar o armazenamento de cópias de segurança personalizado

You can also use your own storage for the backups. SSH can be used to store backups in the remote destination, the target server needs to have BorgBackup installed.

Veja também

General na documentação de Borg

Sistema de ficheiros local

Recomenda-se que especifique o caminho absoluto para a cópia de segurança local, por exemplo /path/to/backup. A diretoria tem de ser gravável pelo utilizador a executar o Weblate (consulte Permissões do sistema de ficheiros). Se esta não existir, o Weblate tenta criá-la, mas precisa das permissões apropriadas para o fazr.

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 serão descartados pelo Docker na reinicialização do seu contentor.

Uma opção é pôr backups num volume existente. Por exemplo, /app/data/borgbackup. Este é um volume existente no contentor.

Também pode adicionar um novo contentor para os backups no ficheiro de composição do Docker, por exemplo, a usar /borgbackup:

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

The directory where backups will be stored has to be owned by UID 1000, otherwise Weblate won’t be able to write the backups there.

Cópias de segurança remotas

Para criar os backups remotos, terá que instalar o BorgBackup em outro servidor que seja acessível para sua implantação de Weblate via SSH a usar a chave SSH do Weblate:

  1. Prepare um servidor onde os seus backups serão armazenados.

  2. Instale o servidor SSH nele (receberá-o por padrão com a maioria das distribuições Linux).

  3. Instale o BorgBackup nesse servidor; a maioria das distribuições Linux tem pacotes disponíveis (veja Installation).

  4. Escolha um utilizador existente ou crie um novo que será usado para backup.

  5. Add Weblate SSH key to the user’s .ssh/authorized_keys file, so that Weblate can SSH to the server without a password (see Chave SSH do Weblate).

  6. Create a user-writable directory where Weblate can remotely set up the Borg backup repository, for example in the home directory (i.e. /home/borg/backups).

  7. Configure the backup location in Weblate as user@host:/home/borg/backups or ssh://user@host:port/home/borg/backups.

  8. Once enabled, the backups will be triggered automatically daily. You can also manually trigger a backup from the Weblate UI or using backup.

Dica

Armazenamento da cópia de segurança provisionado do Weblate fornece backups remotos automatizados sem qualquer esforço.

Restaurar do BorgBackup

  1. Restaurar o acesso ao repositório de backup e preparar a sua palavra-passe de backup.

  2. Liste todos os backups no servidor a usar borg list REPOSITÓRIO.

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

  4. Restaure a base de dados do despejo de SQL posto no diretório backup no diretório de dados do Weblate (veja Dados despejados para backups).

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

    Ao usar o contentor Docker, o ficheiro de configurações já está incluído no contentor e deve restaurar as variáveis de ambiente originais. O ficheiro environment.yml pode ajudá-lo com isso (veja Dados despejados para backups).

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

    Ao usar contentores do Docker, ponha os dados num volume de dados, veja Volumes de contentor Docker.

    Por favor, assegurar que os ficheiros têm o proprietário e as permissões corretas, veja Permissões do sistema de ficheiros.

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:

Veja também

Restoring Docker based setup

The following steps assume the official Docker Compose setup using the bundled PostgreSQL and Valkey services, see Instalar utilizando Docker. If your deployment uses an external database or a customized Compose file, adapt the database and volume steps to that environment.

Start with a Docker Compose checkout matching the restored deployment. Restore your original Compose overrides, secrets, and environment variables. The environment.yml file from Dados despejados para backups can help with this, but it is not imported automatically.

  1. Restore the backup archive using Restaurar do BorgBackup or unpack your manual backup so that the Weblate data directory and backups/database.sql are available.

  2. Stop the services which can write to the database or data volume:

    docker compose stop weblate cache
    
  3. Recreate the PostgreSQL volume.

    docker compose stop database
    docker compose rm -v database
    docker volume remove weblate-docker_postgres-data
    

    The volume name depends on the Compose project name and can differ from weblate-docker_postgres-data. Check your setup before removing any volume.

  4. Start the database service:

    docker compose up -d database
    
  5. Restore the database dump:

    cat backups/database.sql | docker compose exec -T database psql --username weblate --dbname weblate
    

    Check that the database name matches POSTGRES_DB and the user matches POSTGRES_USER in your Compose configuration.

  6. Restore the Weblate data directory to the Docker data volume mounted as /app/data, see Volumes de contentor Docker. Files in this volume have to be owned by UID 1000, see Permissões do sistema de ficheiros.

  7. Start the remaining services and follow the logs:

    docker compose up -d
    docker compose logs -f
    

    The Weblate container performs database migrations on startup. If you are also upgrading Weblate, follow Atualizando o contentor Docker.

  8. Refresh the repositories after the restore:

    docker compose exec --user weblate weblate weblate updategit --all
    

Backup manual

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

Dica

Se estiver a fazer os backups manualmente, pode silenciar os avisos do Weblate sobre a falta de backups a adicionar weblate.I028 para SILENCED_SYSTEM_CHECKS em settings.py ou WEBLATE_SILENCED_SYSTEM_CHECKS para o Docker.

SILENCED_SYSTEM_CHECKS.append("weblate.I028")

Base de dados

O local de armazenamento real depende da configuração da sua base de dados.

Dica

A base de dados é o armazenamento mais importante. Configure backups regulares da sua base de dados. Sem a base de dados, todas as traduções são perdidas.

Backup nativo da base de dados

The recommended approach is to save a dump of the database using database-native tools such as pg_dump. It usually performs better than Django backup, and it restores complete tables with all their data.

Pode restaurar esta cópia de segurança numa versão mais recente do Weblate, ela executará todas as migrações necessárias quando executar em migrate. Por favor, consulte Atualizando o Weblate para mais informação detalhada sobre como atualizar entre as versões.

Backup da base de dados do Django

Alternativamente, pode fazer backup da sua base de dados a utilizar o comando dumpdata do Django. Dessa forma o backup é agnóstico de bases de dados e pode ser usado caso queira alterar o backend da base de dados.

Antes de restaurar a base de dados, precisa usar exatamente a mesma versão do Weblate na qual o backup foi feito. Isto é necessário, pois a estrutura da base 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 da base de dados usando migrate.

Depois disso, algumas entradas já serão criadas na base de dados e também as terá no backup da base de dados. A abordagem recomendada é apagar essas entradas manualmente a usar o shell de gestão (veja Invocando comandos de gestão):

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 aposta segura, mesmo que inclua alguns ficheiro que não quer. As secções a seguir descrevem o que deve fazer backup e o que pode pular em detalhes.

Dados despejados para backups

Alterado na versão 4.7: O despejo do ambiente foi adicionado como environment.yml para ajudar na restauração nos ambientes Docker.

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 em settings-expanded.py).

  • Backup da base de dados PostgreSQL como database.sql.

  • Despejo do ambiente como environment.yml.

Os backups da base de dados são gravados como texto simples por padrão, mas eles também podem ser comprimidos ou totalmente ignorados a usar DATABASE_BACKUP.

Para restaurar o backup da base de dados, carregue-o usando ferramentas de banco de dados, por exemplo:

psql --file=database.sql weblate

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 Enviar ao submeter ativado para todos os seus componentes de tradução, todas as alterações do Weblate são incluídas no upstream. Não há necessidade de fazer backup dos repositórios no lado do Weblate, pois eles podem ser clonados novamente a partir do local do upstream sem perda de dados.

Chaves SSH e GPG

Armazenados em DATA_DIR /ssh e DATA_DIR /home.

Se está a usar chaves SSH ou GPG geradas pelo Weblate, deve fazer backup destes locais. Caso contrário, vai perder as chaves privadas e terá que gerar novamente as novas.

Generated SSH wrapper scripts are stored in CACHE_DIR and do not need to be backed up.

Ficheiros enviados pelo utilizador

Armazenados em DATA_DIR /media.

Deve fazer o backup de todos os ficheiros enviados pelo utilizador (por exemplo, Screenshots and visual context).

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 ainda não processadas para a memória de tradução. Recomenda-se realizar a atualização 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, pode configurar um comando do Bash para ser executado diariamente, por exemplo:

$ tar -Jcf ~/backup/weblate-backup-$(date -u +%Y-%m-%d_%H%M%S).xz backups vcs ssh home media fonts secret

Pode ajustar a lista de pastas e ficheiros às suas necessidades. Para evitar guardar a memória de tradução (na pasta «backups»), pode utilizar:

$ 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

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

  2. Atualize todos repositórios usando o updategit.

    weblate updategit --all
    

Mover uma instalação do Weblate

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