O copie de rezervă este o întrebare. O restaurare răspunde la ea.

Păstrați primul exercițiu deliberat mic

Acest exercițiu creează o bază de date de notițe jucărie și un atașament, le capturează pe ambele, apoi le restaurează într-o bază de date nouă și un director nou. Utilizați o mașină Linux de unică folosință cu server PostgreSQL 17 și utilitare client corespunzătoare, Bash și GNU coreutils. Nu trebuie să conțină date de producție și nu trebuie să aibă conexiune la aplicații de producție, mail de ieșire sau joburi programate. Utilizați doar arhiva creată în acest exercițiu.

Comenzile presupun un rol de bază de date preconfigurat, non-superuser, numit restore_lab, permis să creeze baze de date de test, și un login OS cu același nume care se poate autentifica local. Socket-ul PostgreSQL este /var/run/postgresql pe portul 5432. Rugați administratorul să pregătească acel cont în mediul de unică folosință; acest ghid nu modifică regulile de acces la baza de date. Verificați endpoint-ul înainte de a crea ceva:

psql -h /var/run/postgresql -p 5432 -U restore_lab -d postgres -c '\conninfo' &&
pg_dump --version &&
pg_restore --version

Opriți-vă dacă host-ul, contul sau versiunea sunt neașteptate. Păstrați clienții și serverul pe aceeași versiune majoră pentru acest prim drill. pg_dump nu poate face dump la un server mai nou decât propria versiune majoră, iar un target de restore mai vechi nu este în general garantat compatibil. Consultați limitele versiunii pg_dump. Rulați fiecare bloc separat și opriți-vă la o eroare. && protejează împotriva rulării comenzilor ulterioare dintr-un bloc lipit după un eșec; nu continuați niciodată la blocul următor după o creare eșuată de bază de date sau director.

Creați o înregistrare și fișierul ei corespunzător

Numele offvps_restore_source și offvps_restore_target trebuie să fie neutilizate. O bază de date existentă este un motiv să vă opriți și să alegeți un nou exercițiu izolat, nu un motiv să o ștergeți. Creați un workspace de fișiere nou și baza de date sursă:

umask 077 &&
lab=$(mktemp -d "$PWD/offvps-restore.XXXXXX") &&
mkdir "$lab/source" "$lab/source/uploads" "$lab/bundle" "$lab/restore" &&
createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_source

Workspace-ul nou evită suprascrierea unui director existent. mktemp creează un director unic; createdb creează o bază de date nouă din șablonul selectat. Salvați aceste două marcaje:

psql -X -v ON_ERROR_STOP=1 -h /var/run/postgresql -p 5432 \
  -U restore_lab -d offvps_restore_source \
  -c "CREATE TABLE notes (
        id integer PRIMARY KEY,
        body text NOT NULL,
        attachment text NOT NULL
      );
      INSERT INTO notes VALUES (1, 'restore-marker-01', 'marker.txt');" &&
printf '%s\n' 'restore-marker-01' > "$lab/source/uploads/marker.txt"

Înregistrarea spune ce fișier aparține notei, iar ambele conțin același marcaj. Astfel, un atașament lipsă sau o copie nepotrivită devine vizibilă. -X evită setările personale de pornire psql și ON_ERROR_STOP se oprește la o eroare SQL; consultați opțiunile de scripting psql. Nu există nicio aplicație care scrie în acest set de date jucărie.

Capturați baza de date și fișierele ca un singur set de recuperare

pg_dump -h /var/run/postgresql -p 5432 -U restore_lab \
  --format=custom --file="$lab/bundle/notes.dump" offvps_restore_source &&
cp -a "$lab/source/uploads" "$lab/bundle/uploads" &&
pg_restore --list "$lab/bundle/notes.dump"

Arhiva în format custom este citită de pg_restore; un dump SQL simplu urmează o procedură de restore diferită. Listarea arhivei ajută la confirmarea prezenței tabelului și intrărilor de date așteptate. Un dump consistent al bazei de date nu sincronizează automat încărcările externe. Pentru o aplicație reală, folosiți procedura documentată de mentenanță sau de pauză de scriere, astfel încât arborele de fișiere și baza de date să descrie același moment. Exercițiul jucărie este deja liniștit.

Înregistrați versiunea bazei de date, versiunea aplicației, începutul/sfârșitul capturii și calea fișierului lângă pachet. Păstrați credențialele reale separat, sub controale de acces adecvate. Un dump per bază de date nu captează rolurile globale și tabele spații; un plan real de recuperare trebuie să le ia în considerare și pe acestea. Domeniul este descris în ghidul de dump SQL al PostgreSQL.

Restaurați în target-uri noi fără a curăța unul existent

createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_target &&
pg_restore -h /var/run/postgresql -p 5432 -U restore_lab \
  --dbname=offvps_restore_target --no-owner --no-acl \
  --single-transaction "$lab/bundle/notes.dump" &&
mkdir "$lab/restore/uploads" &&
cp -a "$lab/bundle/uploads/." "$lab/restore/uploads/"

Baza de date target este creată goală. Restore-ul omite intenționat --clean, care ar putea elimina obiecte existente. --single-transaction face ca restore-ul acestei mici baze de date să reușească ca unitate sau să se oprească fără a aplica modificările parțiale; nu poate fi combinat cu joburi paralele. --no-owner și --no-acl simplifică proprietatea pentru acest rol de test, astfel încât acest drill nu validează rolurile sau permisiunile de producție ale aplicației. Consultați pg_restore.

Copierea fișierelor vizează noul director de restore, lăsând sursa intactă. GNU cp -a încearcă să păstreze atributele fișierelor; inspectați proprietatea și accesul pentru contul care va rula o aplicație reală. Copierea de octeți nu este un test al permisiunilor aplicației. Consultați opțiunea de arhivare a cp.

Verificați relația, nu doar codurile de ieșire

psql -X -h /var/run/postgresql -p 5432 -U restore_lab \
  -d offvps_restore_target -c "SELECT id, body, attachment FROM notes;" &&
cat "$lab/restore/uploads/marker.txt"

Rezultatele așteptate sunt un rând cu ID 1, corp restore-marker-01 și atașament marker.txt, plus un fișier care conține restore-marker-01. Verificați că sursa mai conține rândul și fișierul original. Pentru aplicația dvs. reală, de asemenea, îndreptați o instanță izolată către baza de date restaurată și directorul de încărcare, deschideți înregistrări reprezentative, preluați un atașament și testați permisiunile de login dorite. Păstrați callback-urile, mail-ul și joburile izolate în timp ce faceți acest lucru.

Notați ce ați dovedit și ce rămâne

Rezultatele așteptate de mai sus sunt criterii de exercițiu, nu rezultate deja observate de OffVPS. Deoarece primul drill păstrează toate fișierele pe o singură mașină, nu oferă protecție împotriva pierderii acelei mașini. Un plan real are nevoie de o copie protejată într-un domeniu de eșec separat, chei de decriptare utilizabile, retenție și o cale de recuperare testată. Examinați numele exacte ale bazei de date de unică folosință și directorul înainte de curățarea ulterioară; țineți producția în afara acelui proces.

Repetați exercițiul după schimbări importante și înregistrați eșecurile la fel de atent ca reușitele. Un serviciu de backup opțional nu dovedește timpul de recuperare al aplicației dvs. Continuați cu planificarea unei sarcini programate când sunteți gata să automatizați captura, păstrând în același timp un drill de restore separat.