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ă

../_images/backups.png

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ă

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:

  1. Achiziționați serviciul Backup pe https://weblate.org/support/#backup.

  2. Introduceți cheia obținută în interfața de management, a se vedea Integrarea sprijinului.

  3. Weblate se conectează la serviciul cloud și obține informații de acces pentru copiile de rezervă.

  4. Activați noua configurație de backup din fila Backups.

  5. 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

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.

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:

  1. Pregătiți un server pe care vor fi stocate copiile de rezervă.

  2. Instalați serverul SSH pe acesta (îl veți primi în mod implicit cu majoritatea distribuțiilor Linux).

  3. Instalați BorgBackup pe acel server; majoritatea distribuțiilor Linux au pachete disponibile (vezi Installation).

  4. Alegeți un utilizator existent sau creați un utilizator nou care va fi utilizat pentru backup.

  5. Adăugați cheia SSH Weblate la utilizator, astfel încât Weblate să poată accesa SSH la server fără parolă (vezi Cheie SSH Weblate).

  6. Configurați locația de backup în Weblate ca user@host:/path/to/backups sau ssh://user@host:port/path/to/backups.

Sugestie

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

Restaurarea din BorgBackup

  1. Restaurați accesul la depozitul de copii de rezervă și pregătiți fraza de rezervă.

  2. Listează toate copiile de rezervă de pe server folosind borg list REPOSITORY.

  3. Restaurați copia de rezervă dorită în directorul curent folosind borg extract REPOSITORY::ARCHIVE.

  4. 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ă).

  5. 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ă).

  6. 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:

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 Actualizarea 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 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.

Depozitele de control al versiunilor conțin o copie a depozitelor din amonte cu modificările Weblate. Dacă aveți activat Împingeți pe comitere pentru toate componentele de traducere, toate modificările Weblate sunt incluse în amonte. Nu este nevoie să faceți o copie de rezervă a depozitelor din partea Weblate, deoarece acestea pot fi clonate din nou din locația (locațiile) din amonte fără pierderi de date.

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, Context vizual pentru șiruri de caractere).

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.

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

  1. Restaurați toate datele pe care le-ați salvat.

  2. 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.