Copierea de rezervă și mutarea Weblate¶

Copii de rezervă la nivel de proiect¶

Added in version 4.14.

Proiectul face o copie de rezervă a întregului conținut de traducere din Weblate (proiect, componente, traduceri, comentarii de șiruri, sugestii sau verificări). Este potrivit pentru transferul unui proiect către o altă instanță Weblate.

You can perform a project backup in Operations ↓ Backups. The backup can be restored when creating a project (see Adăugarea de proiecte și componente de traducere).

În prezent, copiile de rezervă nu includ informații privind controlul accesului și istoricul.

The comments and suggestions are backed up with the username of the 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.

Copiile de rezervă generate sunt păstrate pe server după cum este configurat prin PROJECT_BACKUP_KEEP_DAYS și PROJECT_BACKUP_KEEP_COUNT (în mod implicit se păstrează cel mult 3 copii de rezervă pentru 30 de zile).

Import validation of uploaded project backups can be tuned using PROJECT_BACKUP_IMPORT_MAX_MEMBERS, PROJECT_BACKUP_IMPORT_MAX_TOTAL_UNCOMPRESSED_SIZE, PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_SIZE, PROJECT_BACKUP_IMPORT_MIN_RATIO_SIZE, and PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_RATIO.

Use the generated file to import project when Adăugarea de proiecte și componente de traducere or in import_projectbackup.

Notă

Restoring of the backup might fail if the restoring server has different set of Definiții lingvistice 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.

Backup automatizat folosind BorgBackup¶

Weblate are un suport încorporat pentru crearea de copii de rezervă pentru servicii folosind BorgBackup. Borg creează copii de rezervă criptate, eficiente din punct de vedere al spațiului, care pot fi stocate în siguranță în cloud. Copiile de rezervă pot fi controlate în interfața de gestionare din fila Backups.

Schimbat în versiunea 4.4.1: PostgreSQL databases are included in the automated backups.

Copiile de rezervă care utilizează Borg sunt incrementale, iar Weblate este configurat să păstreze următoarele copii de rezervă:

Backup-uri zilnice pentru 14 zile înapoi
Backup-uri săptămânale pentru 8 săptămâni în urmă
Backup-uri lunare pentru 6 luni în urmă

Cheia de criptare Borg¶

BorgBackup creează copii de rezervă criptate și nu le veți putea restaura fără fraza de acces. Fraza de acces este generată la adăugarea unui nou serviciu de backup și ar trebui să o copiați și să o păstrați într-un loc sigur.

Dacă folosiți Stocarea de backup provizionată Weblate, vă rugăm să faceți o copie de rezervă și pentru cheia SSH privată, deoarece aceasta este folosită pentru a accesa copiile de rezervă.

Vezi și

borg init

Personalizarea copiei de rezervă¶

Salvarea bazei de date poate fi configurată prin DATABASE_BACKUP.
Crearea copiilor de rezervă poate fi personalizată folosind BORG_EXTRA_ARGS.

Stocarea de backup provizionată Weblate¶

Cel mai simplu mod de a face o copie de siguranță a instanței Weblate este achiziționarea serviciului backup la weblate.org. Iată cum îl puneți în funcțiune:

Achiziționați serviciul Backup pe https://weblate.org/support/#backup.
Introduceți cheia obținută în interfața de management, a se vedea Integrarea sprijinului.
Weblate se conectează la serviciul cloud și obține informații de acces pentru copiile de rezervă.
Activați noua configurație de backup din fila Backups.
Faceți o copie de rezervă a acreditărilor Borg pentru a putea restaura copiile de rezervă, consultați Cheia de criptare Borg.

Sugestie

Pasul manual de a porni totul există pentru siguranța dumneavoastră. Fără consimțământul dvs. nu se trimite niciun fel de date către depozitul de backup obținut prin procesul de înregistrare.

Utilizarea stocării de rezervă personalizate¶

De asemenea, puteți utiliza propriul spațiu de stocare pentru copiile de rezervă. SSH poate fi folosit pentru a stoca copiile de rezervă în destinația la distanță, serverul țintă trebuie să aibă instalat BorgBackup.

Vezi și

General în documentația Borg

Sistem de fișiere local¶

Se recomandă să specificați calea absolută pentru copia de rezervă locală, de exemplu /path/to/backup. Directorul trebuie să poată fi inscripționat de către utilizatorul care rulează Weblate (a se vedea Permisiunile sistemului de fișiere). Dacă nu există, Weblate încearcă să îl creeze, dar are nevoie de permisiunile corespunzătoare pentru a face acest lucru.

Sugestie

Atunci când executați Weblate în Docker, asigurați-vă că locația de backup este expusă ca volum din containerul Weblate. În caz contrar, copiile de rezervă vor fi aruncate de Docker la repornirea containerului în care se află.

O opțiune este de a plasa copiile de rezervă într-un volum existent, de exemplu /app/data/borgbackup. Acesta este un volum existent în container.

Puteți, de asemenea, să adăugați un nou container pentru copiile de rezervă în fișierul Docker Compose, de exemplu, folosind /borgbackup:

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

The directory where backups will be stored has to be owned by UID 1000, otherwise Weblate won’t be able to write the backups there.

Copii de rezervă la distanță¶

Pentru a crea copii de rezervă la distanță, va trebui să instalați BorgBackup pe un alt server care este accesibil pentru implementarea Weblate prin SSH folosind cheia SSH Weblate:

Pregătiți un server pe care vor fi stocate copiile de rezervă.
Instalați serverul SSH pe acesta (îl veți primi în mod implicit cu majoritatea distribuțiilor Linux).
Instalați BorgBackup pe acel server; majoritatea distribuțiilor Linux au pachete disponibile (vezi Installation).
Alegeți un utilizator existent sau creați un utilizator nou care va fi utilizat pentru backup.
Add Weblate SSH key to the user’s .ssh/authorized_keys file, so that Weblate can SSH to the server without a password (see Cheie SSH Weblate).
Create a user-writable directory where Weblate can remotely set up the Borg backup repository, for example in the home directory (i.e. /home/borg/backups).
Configure the backup location in Weblate as user@host:/home/borg/backups or ssh://user@host:port/home/borg/backups.
Once enabled, the backups will be triggered automatically daily. You can also manually trigger a backup from the Weblate UI or using backup.

Sugestie

Stocarea de backup provizionată Weblate vă oferă backup-uri automate de la distanță.

Vezi și

Restaurarea din BorgBackup¶

Restaurați accesul la depozitul de copii de rezervă și pregătiți fraza de rezervă.
Listează toate copiile de rezervă de pe server folosind borg list REPOSITORY.
Restaurați copia de rezervă dorită în directorul curent folosind borg extract REPOSITORY::ARCHIVE.
Restaurați baza de date de la descărcarea SQL plasată în directorul backup din directorul de date Weblate (see Date descărcate pentru copii de rezervă).
Copiați configurația Weblate (backups/settings.py, see Date descărcate pentru copii de rezervă) în locația corectă, a se vedea Ajustarea configurației.

Atunci când utilizați containerul Docker, fișierul de setări este deja inclus în container și trebuie să restaurați variabilele de mediu originale. Fișierul environment.yml vă poate ajuta în acest sens (a se vedea Date descărcate pentru copii de rezervă).
Copiați întregul director de date restaurat în locația configurată prin DATA_DIR.

Atunci când utilizați containerul Docker, plasați datele în volumul de date, consultați Volumele containerelor Docker.

Vă rugăm să vă asigurați că fișierele au proprietatea și permisiunile corecte, consultați Permisiunile sistemului de fișiere.

Sesiunea Borg ar putea arăta în felul următor:

$ 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:

Vezi și

Restoring Docker based setup¶

The following steps assume the official Docker Compose setup using the bundled PostgreSQL and Valkey services, see Instalarea folosind Docker. If your deployment uses an external database or a customized Compose file, adapt the database and volume steps to that environment.

Start with a Docker Compose checkout matching the restored deployment. Restore your original Compose overrides, secrets, and environment variables. The environment.yml file from Date descărcate pentru copii de rezervă can help with this, but it is not imported automatically.

Restore the backup archive using Restaurarea din BorgBackup or unpack your manual backup so that the Weblate data directory and backups/database.sql are available.
Stop the services which can write to the database or data volume:
```
docker compose stop weblate cache
```
Recreate the PostgreSQL volume.
```
docker compose stop database
docker compose rm -v database
docker volume remove weblate-docker_postgres-data
```
The volume name depends on the Compose project name and can differ from weblate-docker_postgres-data. Check your setup before removing any volume.
Start the database service:
```
docker compose up -d database
```
Restore the database dump:
```
cat backups/database.sql | docker compose exec -T database psql --username weblate --dbname weblate
```
Check that the database name matches POSTGRES_DB and the user matches POSTGRES_USER in your Compose configuration.
Restore the Weblate data directory to the Docker data volume mounted as /app/data, see Volumele containerelor Docker. Files in this volume have to be owned by UID 1000, see Permisiunile sistemului de fișiere.
Start the remaining services and follow the logs:
```
docker compose up -d
docker compose logs -f
```
The Weblate container performs database migrations on startup. If you are also upgrading Weblate, follow Actualizarea containerului Docker.

Refresh the repositories after the restore:

docker compose exec --user weblate weblate weblate updategit --all

Vezi și

Backup manual¶

În funcție de ceea ce doriți să salvați, faceți o copie de rezervă a tipului de date pe care Weblate le stochează în fiecare loc respectiv.

Sugestie

Dacă efectuați copii de rezervă manuale, este posibil să doriți să reduceți la tăcere avertismentul Weblate privind lipsa de copii de rezervă adăugând weblate.I028 la SILENCED_SYSTEM_CHECKS în settings.py sau WEBLATE_SILENCED_SYSTEM_CHECKS pentru Docker.

SILENCED_SYSTEM_CHECKS.append("weblate.I028")

Baza de date¶

Locația efectivă de stocare depinde de configurația bazei de date.

Sugestie

Baza de date este cea mai importantă modalitate de stocare. Configurați în mod regulat copii de rezervă ale bazei de date. Fără baza de date, toate traducerile dispar.

Backup nativ al bazei de date¶

The recommended approach is to save a dump of the database using database-native tools such as pg_dump. 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 Actualizarea Weblate on more detailed info on how to upgrade between versions.

Copie de rezervă a bazei de date Django¶

Alternativ, puteți face o copie de siguranță a bazei de date folosind comanda dumpdata de la Django. În acest fel, copia de rezervă este agnostică față de baza de date și poate fi utilizată în cazul în care doriți să schimbați backend-ul bazei de date.

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.

Ulterior, unele intrări vor fi deja create în baza de date și le veți avea și în copia de rezervă a bazei de date. Abordarea recomandată este de a șterge manual astfel de intrări folosind shell-ul de management (a se vedea Invocarea comenzilor de gestionare):

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

Fișiere¶

Dacă aveți suficient spațiu de backup, faceți o copie de rezervă a întregului DATA_DIR. Acesta este un pariu sigur, chiar dacă include unele fișiere pe care nu le doriți. Următoarele secțiuni descriu în detaliu ce trebuie să salvați și ce puteți sări peste.

Date descărcate pentru copii de rezervă¶

Schimbat în versiunea 4.7: Descărcarea mediului a fost adăugată ca environment.yml pentru a ajuta la restaurarea în mediile Docker.

Stocat în DATA_DIR /backups.

Weblate descarcă diverse date aici și puteți include aceste fișiere pentru copii de rezervă mai complete. Fișierele sunt actualizate zilnic (necesită un server Celery beats în funcțiune, consultați Sarcini de fundal folosind Celery). În prezent, acestea includ:

Setări Weblate ca settings.py (există, de asemenea, o versiune extinsă în settings-expanded.py).
Copie de rezervă a bazei de date PostgreSQL ca database.sql.
Descărcarea mediului ca environment.yml.

În mod implicit, copiile de rezervă ale bazei de date sunt salvate ca text simplu, dar pot fi comprimate sau pot fi omise în întregime folosind DATABASE_BACKUP.

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

psql --file=database.sql weblate

Depozite de control al versiunilor¶

Stocat în DATA_DIR /vcs.

The version control repositories contain a copy of your upstream repositories with Weblate changes. If you have Încarcă la comitere 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 with no data loss.

Chei SSH și GPG¶

Stocate în DATA_DIR /ssh și DATA_DIR /home.

Dacă utilizați chei SSH sau GPG generate de Weblate, trebuie să faceți o copie de rezervă a acestor locații. În caz contrar, veți pierde cheile private și va trebui să regenerați altele noi.

Generated SSH wrapper scripts are stored in CACHE_DIR and do not need to be backed up.

Fișiere încărcate de utilizator¶

Stocat în DATA_DIR /media.

Ar trebui să faceți o copie de rezervă a tuturor fișierelor încărcate de utilizator (de exemplu, Screenshots and visual context).

Sarcini de celery¶

Sarcinile Celery pot conține unele informații, dar de obicei nu este necesară pentru o copie de rezervă. Cel mult veți pierde actualizările care nu au fost încă procesate în memoria de traducere. Se recomandă să se efectueze oricum actualizarea textului integral sau a depozitului la restaurare, astfel încât nu există nicio problemă în a le pierde.

Vezi și

Sarcini de fundal folosind Celery

Linie de comandă pentru backup manual¶

Folosind un cron job, puteți configura o comandă Bash care să fie executată zilnic, de exemplu:

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

Puteți ajusta lista de dosare și fișiere în funcție de nevoile dumneavoastră. Pentru a evita salvarea memoriei de traducere (în dosarul de copii de rezervă), puteți utiliza:

$ 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

Restaurarea backup-ului manual¶

Restaurați toate datele pe care le-ați salvat.
Update all repositories using updategit.
```
weblate updategit --all
```

Mutarea unei instalații Weblate¶

Mutați instalația pe un alt sistem, urmând instrucțiunile de backup și restaurare de mai sus.

Vezi și