Cum se face o copie de rezervă și se restaurează o bază de date PostgreSQL Matrix Synapse

O recuperare Synapse fiabilă începe cu un dump PostgreSQL care poate fi citit, o bază de date destinație curată și fișierele homeserver corespunzătoare. Pentru o instalare tipică cu o singură bază de date, ghidul de backup al Synapse recomandă formatul personalizat de dump PostgreSQL și exclude conținutul e2e_one_time_keys_json. Restaurați într-o bază de date goală, nou creată; nu suprapuneți un dump peste tabelele lăsate de o instalare anterioară. Apoi, confirmați că Synapse pornește pe baza de date restaurată și că sunt prezente suporturile media locale și cheile de semnare.

Această prezentare generală presupune o gazdă Linux, o bază de date PostgreSQL numită synapseși un rol în baza de date numit synapse_user. Înlocuiți baza de date, rolul, calea de rezervă, numele serviciului și căile de configurare utilizate de implementarea dvs. Implementările Docker Compose, Kubernetes, PostgreSQL gestionat și Synapse cu mai multe baze de date necesită comenzi echivalente pentru mediul lor.

Ce protejează și ce nu protejează o dump a bazei de date

pg_dumpcapturează o bază de date PostgreSQL într-o instantanee consistentă, astfel încât PostgreSQL și Synapse pot rămâne online în timp ce rulează dump-ul. O arhivă în format personalizat ( -Fc) poate fi inspectată și restaurată cu pg_restore. Ghidul Synapse recomandă în mod specific excluderea datelor din tabelul cu chei unice: restaurarea cheilor utilizate mai vechi poate determina clienții să primească din nou chei și poate duce la erori de decriptare a mesajelor. Definiția tabelului poate apărea în continuare în arhivă; atunci când verificați lista de arhive, căutați intrări de date din tabel în loc să presupuneți că un tabel listat conține rânduri.

Un dump al bazei de date nu este o copie de rezervă completă a serverului de acasă. De asemenea, păstrați homeserver.yamltoate fișierele la care face referire, cheia de semnare a serverului și directorul depozitului media. Ghidul de backup Synapse identifică media încărcată local ca fiind importantă, deoarece serverul de acasă poate deține singura copie. Dacă configurația dvs. utilizează mai multe intrări în baza de date, planificați un dump pentru fiecare bază de date utilizată de Synapse.

Înainte de a începe

• Confirmați numele bazei de date configurate, utilizatorul, gazda, portul și dacă Synapse utilizează o bază de date sau mai multe.
• Verificați dacă utilitarele client PostgreSQL pg_dump, pg_restore, createdb, și psqlsunt instalate și compatibile cu serverul PostgreSQL.
• Alegeți o destinație de backup protejată cu suficient spațiu liber. Dump-urile pot conține mesaje private și date de cont; restricționați accesul și criptați backup-urile în repaus și în tranzit.
• Înregistrați directorul de configurare Synapse, calea cheii de semnare și media_store_pathfaceți copii de rezervă ale secretelor fără a le expune în istoricul shell-ului, chat sau jurnale.
• Decideți cum veți testa recuperarea. O restaurare de test pe o gazdă izolată sau pe o bază de date intermediară este o dovadă mai puternică decât o comandă de dump reușită.

Creați și verificați copia de rezervă PostgreSQL

1. Confirmați baza de date și rolul țintă

Pe o gazdă PostgreSQL autogestionată, conectați-vă ca administrator PostgreSQL și inspectați lista și relațiile bazei de date. Nu vă bazați pe un nume asumat copiat dintr-o configurație exemplu. Dacă serverul dvs. de acasă utilizează o bază de date la distanță sau gestionată, utilizați metoda de conectare aprobată și verificați dacă contul de dump are accesul de citire necesar.

2. Creați un dump în format personalizat

Creați un director pe care numai contul de rezervă sau administratorii îl pot citi. Exemplul de mai jos rulează pg_dumpca cont local al sistemului de operare PostgreSQL și scrie într-o cale protejată. Schimbați calea cu una care există și este inscriptibilă în configurația dvs.

sudo -u postgres pg_dump -Fc \
  --exclude-table-data e2e_one_time_keys_json \
  synapse -f /var/backups/synapse/synapse.dump

Dacă baza de date este la distanță, furnizați setările de conexiune cu metoda aprobată în mediul dvs., cum ar fi un .pgpassfișier protejat sau variabile de mediu libpq. Evitați să introduceți o parolă direct în linia de comandă. Păstrați opțiunea de excludere, cu excepția cazului în care aveți un motiv deliberat și documentat pentru a gestiona diferit tabelul cu chei unice.

3. Verificați arhiva și păstrați o sumă de control

Confirmați că fișierul dump există, este diferit de zero și poate fi citit ca o arhivă PostgreSQL. O listare reușită este o primă verificare utilă, dar nu dovedește că o restaurare se va finaliza sau că serverul principal complet poate deservi utilizatorii.

sudo -u postgres pg_restore --list /var/backups/synapse/synapse.dump
sha256sum /var/backups/synapse/synapse.dump

Stocați suma de control lângă înregistrarea de rezervă, apoi copiați dump-ul pe un sistem separat sau un serviciu de rezervă. Recalculați suma de control după copiere și comparați valorile. Pentru obiectivele de recuperare în producție, programați copii de rezervă regulate, păstrați mai multe generații, criptați-le și rulați exerciții de restaurare periodice.

Restaurare într-o bază de date curată

4. Opriți Synapse și pregătiți o destinație goală

Pentru o restaurare, opriți mai întâi Synapse, astfel încât să nu se poată reconecta în timp ce baza de date este înlocuită sau testată. Numele serviciului de mai jos este comun în unele instalări de pachete, dar variază; utilizatorii Docker ar trebui să oprească serviciul Synapse prin intermediul proiectului lor Compose, iar implementările orchestrate ar trebui să utilizeze procedura normală de întreținere. PostgreSQL în sine nu trebuie oprit.

Folosește o bază de date nouă, goală, pentru restaurare. Nu restaura peste o bază de date Synapse existentă sau peste una care conține deja tabele. Dacă trebuie să păstrezi baza de date curentă pentru revenire la configurație, las-o intactă și restaurează sub un nume temporar al bazei de date, apoi validează înainte de a modifica configurația Synapse.

sudo -u postgres createdb \
  --encoding=UTF8 --locale=C --template=template0 \
  --owner=synapse_user synapse

Proprietarul bazei de date și setările regionale ar trebui să corespundă cerințelor configurării Synapse. Dacă numele țintă există deja, opriți procesul și confirmați ce bază de date intenționați să utilizați; nu presupuneți că eliminarea acestuia este sigură. Creați mai întâi toate rolurile PostgreSQL necesare. O bază de date unică pg_dumpnu include roluri la nivel de cluster, așa că un administrator care se mută într-un nou cluster PostgreSQL poate avea nevoie și de o copie de rezervă globală protejată separat, realizată cu pg_dumpall --globals-only.

5. Restaurați arhiva și gestionați cheile de unică folosință

Încărcați arhiva personalizată în destinația goală. Opțiunea de eroare explicită face ca restaurarea să se oprească atunci când întâlnește o eroare, în loc să continue și să lase un rezultat incomplet, ușor de ratat.

sudo -u postgres pg_restore --exit-on-error \
  --dbname=synapse /var/backups/synapse/synapse.dump

Dacă dump-ul nu a exclus e2e_one_time_keys_json, conectați-vă la baza de date restaurată și trunchiați tabelul respectiv înainte de a porni Synapse. Aceasta este măsura de siguranță în caz de recuperare documentată de Synapse pentru copiile de rezervă care includ acele rânduri. Nu executați comanda fără să o executați pe o bază de date activă: aceasta elimină toate rândurile din tabelul respectiv.

sudo -u postgres psql -d synapse \
  -c 'TRUNCATE e2e_one_time_keys_json;'

Dacă ați utilizat excluderea recomandată, restaurarea nu conține rânduri vechi cu cheie unică folosință, iar acest pas de trunchiere este inutil. O intrare de tabel în pg_restore --listpoate reprezenta o definiție de tabel fără datele sale. Verificați dacă TABLE DATAexistă intrări atunci când revizuiți conținutul arhivei; cea mai sigură înregistrare operațională este comanda exactă de dump utilizată.

Readuceți Synapse și verificați recuperarea

6. Restaurați fișierele însoțitoare și porniți Synapse

Înainte de a reporni, asigurați-vă că punctele de configurare restaurate la baza de date dorită, cheia de semnare și depozitul media așteptate sunt disponibile pentru procesul Synapse. Dacă ați restaurat sub un nume de bază de date temporar, actualizați setarea bazei de date în mod sigur, validați fișierul și utilizați procesul normal de implementare pentru a-l activa. Păstrați baza de date veche și configurația anterioară disponibile până când noua instanță trece verificările.

Porniți serviciul folosind comanda corespunzătoare implementării dvs. Pe o gazdă systemd, inspectați starea serviciului și jurnalele recente. În containere, inspectați starea containerului și jurnalele. Un proces care rulează este un semnal inițial, nu o dovadă că utilizatorii pot citi camere, pot trimite mesaje sau pot prelua atașamente.

7. Funcții de testare de care depind utilizatorii

• Confirmă că Synapse pornește fără erori de migrare a bazei de date, permisiuni, setări regionale sau conexiune.
• Conectați-vă cu un cont de testare și citiți camerele existente; trimiteți un mesaj de testare dacă planul de întreținere permite.
• Verificați comportamentul federației și al serviciilor de aplicații dacă aceste caracteristici fac parte din implementarea dvs.
• Deschideți un atașament sau un avatar încărcat local cunoscut pentru a testa dacă depozitul media se potrivește cu baza de date restaurată.
• Verificați jurnalele Synapse și PostgreSQL pentru erori repetate după pornire, nu doar prima verificare reușită a stării de funcționare.

O restaurare poate avea succes din punct de vedere tehnic chiar dacă lipsesc fișiere media, configurații la care se face referire sau roluri. Dacă utilizatorii observă atașamente lipsă, verifică depozitul media configurat și restaurează copia de rezervă locală corespunzătoare. Dacă Synapse nu se poate conecta, comparați proprietarul bazei de date restaurate, acreditările, gazda, numele bazei de date, setările regionale și fișierul de configurare activ.

Semnale comune de eșec și când trebuie schimbată metoda

Dump-urile logice sunt portabile și simple pentru multe implementări mici și mijlocii, dar restaurarea lor poate dura ceva timp pe măsură ce baza de date crește. Pentru un serviciu mare sau cu disponibilitate ridicată, consultați documentația actuală de backup PostgreSQL și planificați un backup fizic testat sau un design de recuperare la un moment dat. Păstrați un dump logic independent dacă acesta servește unei nevoi separate de portabilitate sau audit. Nicio metodă nu protejează fișierele stocate în afara PostgreSQL, cu excepția cazului în care acestea sunt copiate separat.

Listă de verificare pentru recuperare

• Dumpul este lizibil pg_restore --listși suma sa de control se potrivește cu copia din afara gazdei.
• Restaurarea a fost efectuată într-o bază de date nouă, goală, cu codificarea, setările regionale, proprietarul și rolurile așteptate.
• Rândurile cu cheie unică au fost excluse sau tabelul a fost trunchiat înainte de repornirea Synapse.
• Fișierele de configurare, cheia de semnare și suporturile de stocare locale necesare au fost restaurate din copii de rezervă compatibile.
• Jurnalele sinapselor sunt suficient de curate pentru service, iar verificările la nivel de client sunt reușite pentru camere și media.
• Un exercițiu de restaurare a confirmat pașii de recuperare documentați și a măsurat timpul real de restaurare.

Referințe oficiale

• Ghid pentru backup-ul Synapse — sfaturi specifice bazei de date, gestionarea cheilor unice, configurare, chei de semnare și depozit media.
• Synapse: Utilizarea PostgreSQL — detalii despre configurarea și configurarea bazei de date.
• PostgreSQL: pg_dump , pg_restore și backup și restore PostgreSQL — opțiuni de arhivare și strategii mai ample de backup.

Documentația a fost verificată la 6 octombrie 2026. Numele comenzilor și gestionarea serviciilor variază în funcție de sistemul de operare, imaginea containerului, versiunea PostgreSQL și implementarea Synapse. Verificați instrucțiunile cu documentația pentru versiunile și metoda de împachetare pe care le executați.