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#
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
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
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:
Compre el Servicio de copia de seguridad en https://welate.org/support/#backup.
Introduzca la clave obtenida en la interfaz de gestión, consulte Integrating support.
Weblate se conecta al servicio en la nube y obtiene información de acceso para las copias de seguridad.
Active la nueva configuración de las copias de seguridad desde la pestaña Backups.
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:
Prepare un servidor donde se almacenarán sus copias de seguridad.
Instala el servidor SSH en él (lo tendrás por defecto con la mayoría de las distribuciones de Linux).
Instale BorgBackup en ese servidor; la mayoría de las distribuciones de Linux tienen paquetes disponibles (véase Installation).
Elija un usuario existente o cree un nuevo usuario que se utilizará para las copias de seguridad.
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).
Configure la ubicación de la copia de seguridad en Weblate como
usuario@host:/ruta/a/backups
ossh://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
Restaurar a partir de BorgBackup#
Restablece el acceso a tu repositorio de copias de seguridad y prepara tu frase de acceso a las mismas.
Listar todas las copias de seguridad en el servidor usando
borg list REPOSITORY
.Restaura la copia de seguridad deseada en el directorio actual utilizando
borg extract REPOSITORY::ARCHIVE
.Restaure la base de datos desde el volcado de SQL colocado en el directorio
backup
en el directorio de datos de Weblate (ver Datos volcados para las copias de respaldo).Copie la configuración de Weblate (
backups/settings.py
, consulte Datos volcados para las copias de respaldo) en la ubicación correcta, consulte Adjusting configuration.Cuando se utiliza un contenedor Docker, el archivo de configuración ya está incluido en el contenedor y debe restaurar las variables de entorno originales. El archivo
environment.yml
podría ayudarte con esto (ver Datos volcados para las copias de respaldo).Copiar todo el directorio de datos restaurado en la ubicación configurada por
DATA_DIR
.Si utiliza un contenedor Docker, coloque los datos en el volumen de datos, véase Volúmenes de contenedores Docker.
Por favor, asegúrese de que los archivos tienen la propiedad y los permisos correctos, véase Permisos del sistema de archivos.
La sesión de Borg podría verse así:
$ 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
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
Si estás haciendo las copias de seguridad manuales, puede que quieras silenciar el aviso de Weblate sobre la falta de copias de seguridad añadiendo weblate.I028
a SILENCED_SYSTEM_CHECKS
en settings.py
o WEBLATE_SILENCED_SYSTEM_CHECKS
para Docker.
SILENCED_SYSTEM_CHECKS.append("weblate.I028")
Base de datos#
La ubicación real del almacenamiento depende de la configuración de su base de datos.
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.
Copia de seguridad de la base de datos nativa#
El enfoque recomendado es guardar un volcado de la base de datos utilizando herramientas nativas de la base de datos como pg_dump o mysqldump. Suele funcionar mejor que la copia de seguridad de Django, y restaura tablas completas con todos sus datos.
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.
Copia de seguridad de la base de datos de Django#
Alternativamente, puedes hacer una copia de seguridad de tu base de datos utilizando el comando dumpdata
de Django. De esta manera la copia de seguridad es agnóstica a la base de datos y puede ser utilizada en caso de que quieras cambiar el backend de la base de datos.
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
.
Después, algunas entradas ya estarán creadas en la base de datos y las tendrá también en la copia de seguridad de la base de datos. Lo recomendable es eliminar dichas entradas manualmente utilizando el shell de gestión (ver Invocar órdenes de gestión):
weblate shell
>>> from weblate.auth.models import User
>>> User.objects.get(username='anonymous').delete()
Archivos#
Si tiene suficiente espacio para hacer copias de seguridad, simplemente haga una copia de seguridad de todo el DATA_DIR
. Esto es una apuesta segura incluso si incluye algunos archivos que no quieres. Las siguientes secciones describen en detalle lo que debes respaldar y lo que puedes omitir.
Datos volcados para las copias de respaldo#
Distinto en la versión 4.7: El volcado del entorno se añadió como environment.yml
para ayudar en la restauración en los entornos Docker.
Almacenados en DATA_DIR
/backups
.
Weblate vuelca varios datos aquí, y puedes incluir estos archivos para obtener copias de seguridad más completas. Los archivos se actualizan diariamente (se requiere un servidor de beats Celery en funcionamiento, véase Tareas en segundo plano con Celery). Actualmente, esto incluye:
Configuración de Weblate como
settings.py
(también hay una versión ampliada ensettings-expanded.py
).Copia de seguridad de la base de datos PostgreSQL como
database.sql
.Volcado del entorno como
environment.yml
.
Las copias de seguridad de la base de datos se guardan como texto plano por defecto, pero también pueden comprimirse o saltarse por completo utilizando DATABASE_BACKUP
.
Para restaurar la copia de seguridad de la base de datos, cárguela utilizando las herramientas de la base de datos, por ejemplo:
psql --file=database.sql weblate
Repositorios de control de versiones#
Almacenado en DATA_DIR
/vcs
.
Los repositorios de control de versiones contienen una copia de tus repositorios upstream con los cambios de Weblate. Si tienes Enviar al consignar activado para todos tus componentes de traducción, todos los cambios de Weblate se incluyen en el flujo ascendente. No es necesario hacer una copia de seguridad de los repositorios en el lado de Weblate, ya que se pueden clonar de nuevo desde la(s) ubicación(es) de subida sin pérdida de datos.
Claves SSH y GPG#
Almacenado en DATA_DIR
/ssh
y 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#
Almacenado en 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#
La cola de tareas de Celery puede contener alguna información, pero normalmente no es necesaria para una copia de seguridad. A lo sumo se perderán las actualizaciones que aún no han sido procesadas en la memoria de traducción. Se recomienda realizar la actualización del texto completo o del repositorio en el momento de la restauración, por lo que no hay problema en perderlos.
Ver también
Ó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
La cadena entre comillas después de XZ_OPT permite elegir las opciones de xz, por ejemplo la cantidad de memoria utilizada para la compresión; véase 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#
Restaure todos los datos de los que ha hecho copia de respaldo.
Update all repositories using
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.