Backing up and moving Weblate

Automated backup using BorgBackup

Nuevo en la versión 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.

Advertencia

Only PostgreSQL database is included in the automated backups. Other database engines have to be backed up manually. You are recommended to migrate to PostgreSQL, see Configuración de base de datos para Weblate and Migrating from other databases to PostgreSQL.

The backups using Borg are incremental and Weblate is configured to keep following backups:

  • 14 daily backups

  • 8 weekly backups

  • 6 monthly backups

../_images/backups.png

Borg encryption key

BorgBackup creates encrypted backups and without a passphrase you will not be able to restore the backup. The passphrase is generated when adding new backup service and you should copy it and keep it in a secure place.

In case you are using Weblate provisioned backup storage, please backup your private SSH key as well — it is used to access your backups.

Ver también

borg init

Weblate provisioned backup storage

The easiest approach to backup your Weblate instance is to purchase backup service at weblate.org. The process of activating can be performed in few steps:

  1. Purchase backup service on https://weblate.org/support/#backup.

  2. Enter obtained key in the management interface, see Integrating support.

  3. Weblate will connect to the cloud service and obtain access information for the backups.

  4. Turn on the new backup configuration on the Backups tab.

  5. Backup Borg credentials in order to be able to restore the backups, see Borg encryption key.

Consejo

The manual step of turning on is there for your safety. Without your consent no data is sent to the backup repository obtained through the registration process.

Utilizar un almacenamiento personalizado para los respaldos

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

Ver también

General en la documentación de Borg

Sistema de archivos local

Es recomendable especificar una ruta absoluta para la copia de respaldo local, como /ruta/al/respaldo. El directorio debe ser escribible por la cuenta de usuario que ejecute Weblate (vea Permisos del sistema de archivos). Si no existe la ubicación, Weblate intentará crearla, pero necesita permiso para hacerlo.

Consejo

Siempre que se ejecute Weblate en Docker, hay que asegurarse de que la ubicación de las copias de respaldo esté expuesta como volumen desde el contenedor de Weblate. De otro modo, Docker descartará las copias de respaldo al momento de reiniciar el contenedor.

One option is to place backups in existing volume. For example choose /app/data/borgbackup. This is existing volume in the container.

You can also add new container for the backups in the Docker compose file and use for example /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.

Copias de respaldo remotas

Se permite realizar copias de respaldo remotas a través de SSH. El servidor SSH debe tener instalado BorgBackup. Weblate se conecta con el servidor mediante la clave SSH, de modo que debe cerciorarse de que el servidor acepte la clave SSH de Weblate (vea Clave SSH de Weblate).

Consejo

Weblate provisioned backup storage le ofrece copias de respaldo automatizadas.

Restaurar a partir de BorgBackup

  1. Restore access to your backup repository and prepare your backup passphrase.

  2. List backup existing on the server using borg list REPOSITORY.

  3. Restore the desired backup to current directory using borg extract REPOSITORY::ARCHIVE.

  4. Restore the database from the SQL dump placed in the backup directory in the Weblate data dir (see Dumped data for backups).

  5. Copy Weblate configuration (backups/settings.py, see Dumped data for backups) to the correct location, see Adjusting configuration.

  6. Copy the whole restored data dir to location configured by DATA_DIR.

The Borg session might look like:

$ 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 también

borg list, borg extract

Copia de respaldo manual

Depending on what you want to save, back up the type data Weblate stores in each respective place.

Consejo

In case you are doing manual backups, you might want to silent Weblate warning about lack of backups by adding weblate.I028 to SILENCED_SYSTEM_CHECKS in settings.py or WEBLATE_SILENCED_SYSTEM_CHECKS for Docker.

SILENCED_SYSTEM_CHECKS.append("weblate.I028")

Base de datos

The actual storage location depends on your database setup.

The database is the most important storage. Set up regular backups of your database, without it all your translation setup will be gone.

Native database backup

The recommended approach is to do dump of the database using database native tools such as pg_dump or mysqldump. It usually performs better than Django backup and restores complete tables with all data.

You can restore this backup in newer Weblate release, it will perform any necessary migrations when running in migrate. Please consult Actualizar Weblate on more detailed information how to perform upgrade between versions.

Django database backup

Alternatively you can backup database using Django’s dumpdata command. That way the backup is database agnostic and can be used in case you want to change database backend.

Prior to restoring you need to be running exactly same Weblate version as was used when doing backups. This is necessary as the database structure does change between releases and you would end up corrupting the data in some way. After installing the same version, run all database migrations using migrate.

Once this is done, some entries will be already created in the database and you will have them in the database backup as well. The recommended approach is to delete such entries manually using management shell (see Invocar órdenes de gestión):

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

Archivos

If you have enough backup space, simply backup the whole DATA_DIR. This is safe bet even if it includes some files you don’t want. The following sections describe in detail what you should back up and what you can skip.

Dumped data for backups

Stored in DATA_DIR /backups.

Weblate dumps various data here, and you can include these files for more complete backups. The files are updated daily (requires a running Celery beats server, see Tareas en segundo plano con Celery). Currently, this includes:

  • Weblate settings as settings.py (there is also expanded version in settings-expanded.py).

  • PostgreSQL database backup as 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.

Version control repositories

Stored in DATA_DIR /vcs.

The version control repositories contain a copy of your upstream repositories with Weblate changes. If you have push on commit enabled for all your translation components, all Weblate changes are included upstream and you do not have to backup the repositories on the Weblate side. They can be cloned again from the upstream locations with no data loss.

SSH and GPG keys

Stored in DATA_DIR /ssh and DATA_DIR /home.

If you are using SSH or GPG keys generated by Weblate, you should back up these locations, otherwise you will lose the private keys and you will have to regenerate new ones.

Archivos cargados por los usuarios

Stored in DATA_DIR /media.

You should back up user uploaded files (e.g. Contexto visual para cadenas).

Tareas de 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.

Command line for manual backup

Con la ayuda de una tarea de cron es posible montar una orden de bash que se ejecute diariamente. Por ejemplo:

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

The string between quotes after XZ_OPT allows you to choose your xz options, for instance the amount of memory used for compression; see https://linux.die.net/man/1/xz

You can adjust the list of folders and files to your needs. For instance, to avoid saving the translation memory (in backups folder), you could use:

$ 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

Restoring manual backup

  1. Restore all data you have backed up.

  2. Update all repositories using updategit.

    weblate updategit --all
    

Moving a Weblate installation

Relocate your installation to a different system by following the backup and restore instructions above.