Copierea de rezervă și mutarea Weblate¶

Backup automatizat folosind BorgBackup¶

Nou în versiunea 3.9.

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: Atât bazele de date PostgreSQL, cât și MySQL/MariaDB sunt incluse în copiile de rezervă automate.

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

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 Integrating support.
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 Filesystem permissions). 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

Directorul în care vor fi stocate copiile de rezervă trebuie să fie deținut de UID 1000, altfel Weblate nu va putea scrie copiile de rezervă acolo.

Remote backups¶

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 SSH key).
Configure the backup location in Weblate as user@host:/path/to/backups.

Sugestie

Stocarea de backup provizionată Weblate provides you automated remote backups without any effort.

Vezi și

Weblate SSH key

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 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 Date descărcate pentru copii de rezervă).
Copiați întregul director de date restaurat în locația configurată prin DATA_DIR.

When using Docker container place the data into the data volume, see Docker container volumes.

Please make sure the files have correct ownership and permissions, see Filesystem permissions.

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

borg list, borg extract

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¶

Abordarea recomandată este să salvați o copie a bazei de date utilizând instrumente native pentru baze de date, cum ar fi pg_dump sau mysqldump. De obicei, se comportă mai bine decât backup-ul Django și restaurează tabelele complete cu toate datele lor.

Puteți restaura această copie de rezervă într-o versiune Weblate mai nouă, aceasta va efectua toate migrările necesare atunci când este rulată în migrate. Vă rugăm să consultați Upgrading Weblate pentru informații mai detaliate despre cum să faceți upgrade între versiuni.

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.

Înainte de restaurarea bazei de date, trebuie să rulați exact aceeași versiune Weblate pe care a fost efectuată copia de rezervă. Acest lucru este necesar deoarece structura bazei de date se schimbă între versiuni și ați putea ajunge să corupeți datele într-un fel sau altul. După instalarea aceleiași versiuni, rulați toate migrările bazei de date folosind 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 Invoking management commands):

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: The environment dump was added as environment.yml to help in restoring in the Docker environments.

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 Background tasks using 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.
Environment dump as 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 dabase 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 Împingeți pe 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(s) 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.

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, Visual context for strings).

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

Background tasks using Celery

Linie de comandă pentru backup manual¶

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

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

Șirul de caractere dintre ghilimele după XZ_OPT vă permite să alegeți opțiunile xz, de exemplu cantitatea de memorie folosită pentru compresie; vedeți https://linux.die.net/man/1/xz

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:

$ 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

Restaurarea backup-ului manual¶

Restaurați toate datele pe care le-ați salvat.
Actualizați toate depozitele folosind 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

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