Respaldar y trasladar Weblate

Copias de seguridad a nivel del proyecto

Nuevo en la versión 4.14.

Advertencia

Restaurar las copias de seguridad solo es compatible cuando se usa PostgreSQL o MariaDB 10.5+ como base de datos.

El proyecto crea copias de seguridad de todo el contenido de la traducción en Weblate (proyectos, componentes, traducciones, comentarios de las cadenas, sugerencias o comprobaciones). También es posible transferir entre proyectos de Weblate.

Se puede realizar una copia de seguridad del proyecto en Manage ↓ Backups. La copia de seguridad se puede restaurar al crear un proyecto (véase Añadir proyectos y componentes de traducción).

Actualmente las copias de seguridad no incluyen la información de control de acceso ni el historial.

Los comentarios y las sugerencias se respaldan junto con el nombre de usuario de quién los creó. Al importar se le asigna al usuario correspondiente. Si no se encuentra el nombre de usuario, se le asigna a un usuario anónimo.

Las copias de seguridad se guardan en el servidos que se configuró como PROJECT_BACKUP_KEEP_DAYS y :setting:`PROJECT_BACKUP_KEEP_COUNT (por defecto se guardan hasta 3 copias de seguridad por 30 días).

Copia de respaldo automatizada utilizando BorgBAckup

Nuevo en la versión 3.9.

Weblate tiene soporte integrado para crear copias de seguridad de servicios usando BorgBackup. Borg crea copias de seguridad cifradas que ocupan poco espacio y que se pueden almacenar de forma segura en la nube. Las copias de seguridad se pueden controlar en la interfaz de gestión desde la pestaña Backups.

Distinto en la versión 4.4.1: Se incluyen las bases de datos de tanto PostgreSQL como MySQL/MariaDB en las copias de respaldo automatizadas.

Las copias de seguridad que utilizan Borg son incrementales y Weblate está configurado para mantener las siguientes copias de seguridad:

  • Copias de respaldo diarias para 14 días

  • Copias de respaldo semanales para 8 semanas

  • Copias de respaldo mensuales para 6 meses

../_images/backups.png

Clave de cifrado de Borg

BorgBackup crea copias de seguridad cifradas y no podrá restaurarlas sin la frase de contraseña. La frase de contraseña se genera al agregar un nuevo servicio de respaldo y debe copiarla y guardarla en un lugar seguro.

Si utilizas Almacenamiento de copia de seguridad proporcionado por Weblate, haz una copia de seguridad de tu clave SSH privada también, ya que se utiliza para acceder a tus copias de seguridad.

Ver también

borg init

Personalización de la copia de seguridad

  • La copia de seguridad de la base de datos se puede configurar mediante DATABASE_BACKUP.

  • La creación de copias de seguridad puede personalizarse mediante BORG_EXTRA_ARGS.

Almacenamiento de copia de seguridad proporcionado por Weblate

La forma más sencilla de hacer una copia de seguridad de su instancia de Weblate es adquirir el servicio de copia de seguridad en weblate.org. Así es como se pone en marcha:

  1. Compre el Servicio de copia de seguridad en https://welate.org/support/#backup.

  2. Introduzca la clave obtenida en la interfaz de gestión, consulte Integrating support.

  3. Weblate se conecta al servicio en la nube y obtiene información de acceso para las copias de seguridad.

  4. Active la nueva configuración de las copias de seguridad desde la pestaña Backups.

  5. Haga una copia de seguridad de sus credenciales de Borg para poder restaurar las copias de seguridad, consulte Clave de cifrado de Borg.

Consejo

El paso manual de encender todo está ahí para su seguridad. Sin tu consentimiento no se envía ningún dato al repositorio de copias de seguridad obtenido a través del proceso de registro.

Utilizar un almacenamiento personalizado para los respaldos

También puede utilizar su propio almacenamiento para las copias de seguridad. Se puede utilizar SSH para almacenar las copias de seguridad en el destino remoto, el servidor de destino necesita tener instalado BorgBackup.

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.

Una opción es colocar las copias de seguridad en un volumen existente, por ejemplo /app/data/borgbackup. Este es un volumen existente en el contenedor.

También puede añadir un nuevo contenedor para las copias de seguridad en el archivo Docker Compose, por ejemplo, utilizando /borgbackup:

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

El propietario del directorio donde se habrán de almacenar las copias de respaldo debe ser el UID 1000, o Weblate no podrá guardar las copias de respaldo allí.

Copias de respaldo remotas

Para crear copias de seguridad remotas, tendrá que instalar BorgBackup en otro servidor que sea accesible para su implementación de Weblate a través de SSH utilizando la clave SSH de Weblate:

  1. Prepare un servidor donde se almacenarán sus copias de seguridad.

  2. Instala el servidor SSH en él (lo tendrás por defecto con la mayoría de las distribuciones de Linux).

  3. Instale BorgBackup en ese servidor; la mayoría de las distribuciones de Linux tienen paquetes disponibles (véase Installation).

  4. Elija un usuario existente o cree un nuevo usuario que se utilizará para las copias de seguridad.

  5. Añade la clave SSH de Weblate al usuario para que Weblate pueda SSH al servidor sin necesidad de contraseña (ver Clave SSH de Weblate).

  6. Configure la ubicación de la copia de seguridad en Weblate como usuario@host:/ruta/a/backups o ssh://usuario@host:puerto/ruta/a/backups.

Consejo

Almacenamiento de copia de seguridad proporcionado por Weblate le proporciona copias de seguridad remotas automatizadas sin ningún esfuerzo.

Ver también

Clave SSH de Weblate, General

Restaurar a partir de BorgBackup

  1. Restablece el acceso a tu repositorio de copias de seguridad y prepara tu frase de acceso a las mismas.

  2. Listar todas las copias de seguridad en el servidor usando borg list REPOSITORY.

  3. Restaura la copia de seguridad deseada en el directorio actual utilizando borg extract REPOSITORY::ARCHIVE.

  4. Restore the database from the SQL dump placed in the backup directory in the Weblate data dir (see Datos volcados para las copias de respaldo).

  5. Copy the Weblate configuration (backups/settings.py, see Datos volcados para las copias de respaldo) to the correct location, see Adjusting configuration.

    When using Docker container, the settings file is already included in the container and you should restore the original environment variables. The environment.yml file might help you with this (see Datos volcados para las copias de respaldo).

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

    When using Docker container place the data into the data volume, see Volúmenes de contenedores Docker.

    Please make sure the files have correct ownership and permissions, see Permisos del sistema de archivos.

The Borg session might look like this:

$ 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

En función de lo que desee guardar, respalde los tipos de datos que Weblate almacena en cada sitio respectivo.

Consejo

If you are doing the manual backups, you might want to silence Weblate’s warning about a 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.

Consejo

El almacenamiento más importante es el de la base de datos. Configure copias de respaldo periódicas de la base de datos. Sin esta, todas las traducciones desaparecerán.

Native database backup

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

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

Django database backup

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

Prior to restoring the database you need to be running exactly the same Weblate version the backup was made on. 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.

Afterwards some entries will already be 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 the 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 back up the whole DATA_DIR. This is a safe bet even if it includes some files you don’t want. The following sections describe what you should back up and what you can skip in detail.

Datos volcados para las copias de respaldo

Distinto en la versión 4.7: The environment dump was added as environment.yml to help in restoring in the Docker environments.

Almacenados en 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.

  • Environment dump as environment.yml.

The database backups are saved as plain text by default, but they can also be compressed or entirely skipped using DATABASE_BACKUP.

To restore the database backup load it using database tools, for example:

psql --file=database.sql weblate

Repositorios de control de versiones

Stored in DATA_DIR /vcs.

The version control repositories contain a copy of your upstream repositories with Weblate changes. If you have Enviar al consignar enabled for all your translation components, all Weblate changes are included upstream. No need to back up the repositories on the Weblate side as they can be cloned again from the upstream location(s) with no data loss.

Claves SSH y GPG

Stored in DATA_DIR /ssh and DATA_DIR /home.

Si utiliza las claves SSH o GPG que Weblate genera, debe realizar copias de respaldo de esas ubicaciones. De lo contrario, podría perder las claves privadas y habrá de generar nuevas.

Archivos cargados por los usuarios

Stored in DATA_DIR /media.

Debe crear copias de respaldo de todos los archivos que cargan los usuarios (p. ej., Contexto visual para cadenas).

Tareas de Celery

The Celery task queue might contain some info, but is usually not needed for a backup. At most you will lose updates not yet been processed to translation memory. It is recommended to perform the fulltext or repository update upon restoration anyhow, so there is no problem in losing these.

Ver también

Tareas en segundo plano con Celery

Órdenes de interfaz de texto para efectuar copias de respaldo manualmente

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 the 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

Puede ajustar la lista de carpetas y de archivos para adecuarla a sus necesidades. Para evitar guardar la memoria de traducción (en la carpeta de las copias de respaldo), puede utilizar:

$ 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 una copia de respaldo manual

  1. Restaure todos los datos de los que ha hecho copia de respaldo.

  2. Actualice todos los repositorios mediante updategit.

    weblate updategit --all

Trasladar una instalación de Weblate

Para mudar su instalación a un sistema diferente, siga las instrucciones de respaldo y restauración anteriores.

Ver también

Upgrading from Python 2 to Python 3, Migrating from other databases to PostgreSQL