Backing up and moving Weblate¶
Depending on what you want to save, back up the type data Weblate stores in each respective place.
Where this is located 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.
If you have enough backup space, simply backup the whole
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
Dumped data for 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 Background tasks using Celery). Currently this includes:
- Translation memory dump, in JSON format.
Version control repositories¶
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¶
If you are using SSH or GPG keys generated by Weblate, you should back up these locations, otherwise you will loose the private keys and you will have to regenerate new ones.
User uploaded files¶
You should back up user uploaded files (e.g. Visual context for strings).
It is recommended to back up this content using
dump_memory in JSON-, instead of binary format, as that
might eventually change (and is also incompatible going from Python 2 to Python 3).
Weblate prepares this dump daily, see Dumped data for backups.
The Celery tasks queue might contain some info, but is usually not needed for a backup. At most your will loose updates that have not yet ben 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.