Tworzenie kopii zapasowych i przenoszenie weblate¶
Project level backups¶
Added in version 4.14.
Ostrzeżenie
Restoring backups is only supported when using PostgreSQL or MariaDB 10.5+ as a database.
The project backups all translation content from Weblate (project, components, translations, string comments, suggestions or checks). It is suitable for transferring a project to another Weblate instance.
You can perform a project backup in Manage ↓ Backups. The backup can be restored when creating a project (see Dodawanie projektów i komponentów tłumaczeniowych).
The backups currently do not include access control information and history.
The comments and suggestions are backed up with an username of 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.
The generated backups are kept on the server as configured by
PROJECT_BACKUP_KEEP_DAYS and PROJECT_BACKUP_KEEP_COUNT
(it defaults to keep at most 3 backups for 30 days).
Use the generated file to import project when Dodawanie projektów i komponentów tłumaczeniowych.
Informacja
Restoring of the backup might fail if the restoring server has different set
of Definicje języków or different configuration of
SIMPLIFY_LANGUAGES. The restore will tell you which language
codes could not be processed and you can then add missing language
definitions manually.
Automated backup using BorgBackup¶
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 from the Backups tab.
Zmienione w wersji 4.4.1: Both PostgreSQL and MySQL/MariaDB databases are included in the automated backups.
The backups using Borg are incremental and Weblate is configured to keep following backups:
Codzienne kopie zapasowe przez 14 dni wstecz
Weekly backups for 8 weeks back
Monthly backups for 6 months back
Klucz szyfrujący Borg¶
BorgBackup creates encrypted backups and you wouldn’t be able to restore them without the passphrase. The passphrase is generated when adding a new backup service and you should copy it and keep it in a secure place.
If you are using Weblate provisioned backup storage, please backup your private SSH key too, as it’s used to access your backups.
Zobacz także
Dostosowywanie kopii zapasowej¶
Kopia zapasowa bazy danych może być skonfigurowana za pomocą
DATABASE_BACKUP.The backup creation can be customized using
BORG_EXTRA_ARGS.
Weblate provisioned backup storage¶
The easiest way of backing up your Weblate instance is purchasing the backup service at weblate.org. This is how you get it running:
Kup Usługę tworzenia kopii zapasowych na https://weblate.org/support/#backup.
Enter the obtained key in the management interface, see Integracja wsparcia.
Weblate connects to the cloud service and obtains access info for the backups.
Turn on the new backup configuration from the Backups tab.
Wykonaj kopię zapasową swoich poświadczeń Borg, aby móc przywrócić kopie zapasowe, patrz Klucz szyfrujący Borg.
Podpowiedź
The manual step of turning everything on is there for your safety. Without your consent no data is sent to the backup repository obtained through the registration process.
Korzystanie z niestandardowego magazynu kopii zapasowych¶
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.
Zobacz także
General w dokumentacji
Lokalny system plików¶
It is recommended to specify the absolute path for the local backup, for example /path/to/backup. The directory has to be writable by the user running Weblate (see Uprawnienia systemu plików). If it doesn’t exist, Weblate attempts to create it but needs the appropriate permissions to do so.
Podpowiedź
When running Weblate in Docker, please ensure the backup location is exposed as a volume from the Weblate container. Otherwise the backups will be discarded by Docker upon restarting the container it is in.
One option is to place backups into an existing volume, for example
/app/data/borgbackup. This is an existing volume in the container.
You can also add a new container for the backups in the Docker Compose file
for example by using /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 won’t be able to write the backups there.
Zdalne kopie zapasowe¶
For creating remote backups, you will have to install BorgBackup onto another server that’s accessible for your Weblate deployment via SSH using the Weblate SSH key:
Prepare a server where your backups will be stored.
Install the SSH server on it (you will get it by default with most Linux distributions).
Install BorgBackup on that server; most Linux distributions have packages available (see Installation).
Choose an existing user or create a new user that will be used for backing up.
Add Weblate SSH key to the user so that Weblate can SSH to the server without a password (see Weblate Klucz SSH).
Skonfiguruj lokalizację kopii zapasowej w Weblate jako
użytkownik@host:/ścieżka/do/backupówlubssh://użytkownik@host:port/ścieżka/do/backupów.
Podpowiedź
Weblate provisioned backup storage provides you automated remote backups without any effort.
Zobacz także
Przywracanie z BorgBackup¶
Restore access to your backup repository and prepare your backup passphrase.
List all the backups on the server using
borg list REPOSITORY.Restore the desired backup to the current directory using
borg extract REPOSITORY::ARCHIVE.Restore the database from the SQL dump placed in the
backupdirectory in the Weblate data dir (see Zrzucone dane do kopii zapasowych).Copy the Weblate configuration (
backups/settings.py, see Zrzucone dane do kopii zapasowych) to the correct location, see Dostosowywanie konfiguracji.When using Docker container, the settings file is already included in the container and you should restore the original environment variables. The
environment.ymlfile might help you with this (see Zrzucone dane do kopii zapasowych).Copy the whole restored data dir to the location configured by
DATA_DIR.Korzystając z kontenerów Dockera, umieść dane w wolumenie danych, zobacz Woluminy kontenerów platformy Docker.
Please ensure the files have correct ownership and permissions, see Uprawnienia systemu plików.
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:
Zobacz także
Ręczna kopia zapasowa¶
Depending on what you want to save, back up the type of data Weblate stores in each respective place.
Podpowiedź
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")
Baza danych¶
The actual storage location depends on your database setup.
Podpowiedź
The database is the most important storage. Set up regular backups of your database. Without the database, all the translations are gone.
Natywna kopia zapasowa bazy danych¶
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
Aktualizacja Weblate on more detailed info on how to upgrade between versions.
Kopia zapasowa bazy danych Django¶
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 Wywoływanie poleceń zarządzania):
weblate shell
>>> from weblate.auth.models import User
>>> User.objects.get(username='anonymous').delete()
Pliki¶
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.
Zrzucone dane do kopii zapasowych¶
Zmienione w wersji 4.7: The environment dump was added as environment.yml to help in
restoring in the Docker environments.
Przechowywane w 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 Zadania w tle korzystające z Celery). Currently, this includes:
Weblate settings as
settings.py(there is also expanded version insettings-expanded.py).Kopia zapasowa bazy danych PostgreSQL jako
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
Repozytoria kontroli wersji¶
Przechowywane w DATA_DIR /vcs.
The version control repositories contain a copy of your upstream repositories with Weblate changes. If you have Przesyłaj przy commitowaniu 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.
Klucze SSH i GPG¶
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.
Pliki przesłane przez użytkownika¶
Przechowywane w DATA_DIR /media.
You should back up all user uploaded files (e.g. Kontekst wizualny dla ciągów).
Zadania 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.
Zobacz także
Wiersz poleceń do ręcznego tworzenia kopii zapasowych¶
Using a cron job, you can set up a Bash command to be executed on a daily basis, for example:
$ tar -Jcf ~/backup/weblate-backup-$(date -u +%Y-%m-%d_%H%M%S).xz backups vcs ssh home media fonts secret
You can adjust the list of folders and files to your needs. To avoid saving the translation memory (in backups folder), you can use:
$ 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
Przywracanie ręcznej kopii zapasowej¶
Restore all data you have backed up.
Update all repositories using
updategit.weblate updategit --all
Przenoszenie instalacji Weblate¶
Relocate your installation to a different system by following the backing up and restoration instructions above.