Backup automat pentru baza de date de producție

Toate comenzile clienților, produsele, textele editate din panou și conturile de admin stau într-un singur fișier SQLite, pe un singur volum Docker, pe un singur server. Nu există nicăieri un mecanism de copiere a lui. Dacă discul cedează, dacă volumul e șters din greșeală la un redeploy sau dacă baza se corupe, datele pur și simplu nu mai există — nu e o pierdere din care ne revenim cu muncă.

Ce am găsit

Toată baza de producție e un singur fișier, pe un singur volum

docker-compose.prod.yml:11 fixează calea bazei pe volumul persistent:

      DATABASE_URL: file:/data/hyperice.db

iar docker-compose.prod.yml:13-15 montează cele două volume care țin tot ce e viu:

    volumes:
      - hyperice_db:/data
      - hyperice_uploads:/app/uploads

Nu există replică, nu există a doua copie.

Niciun job de backup, nicăieri în repo

Joburile definite în .gitlab-ci.yml sunt lint (:41), test:frontend (:63), test:backend (:81), build:backend-image (:104), build:frontend-image (:130), deploy:develop (:150), deploy:production (:179), smtp:config (:310), smtp:config:production (:328), seed:live (:358) și seed:production (:450). Niciunul nu face backup.

Căutarea după backup|restore|cron în repo întoarce doar textul checklistului de lansare, adică cerința, nu implementarea ei.

Ce nu se poate stabili din repo: dacă hostingul face deja snapshot-uri ale mașinii sau ale volumelor. Un backup „din hosting" nu apare niciodată într-un repo, iar serverul de producție e infrastructură pe care nu o inspectăm direct.

De făcut

• Confirmă cu deținătorul serverului dacă există deja snapshot-uri de volum din hosting și cu ce frecvență.
• Job programat (cron pe server sau job CI programat) care rulează, din interiorul containerului backend, sqlite3 /data/hyperice.db ".backup /backups/hyperice-$(date +%F).db". Comanda .backup e sigură pe o bază în uz; o copiere cu cp nu e. Rularea se face prin container, pentru că runner-ul nu poate scrie direct în mapa de producție.
• Scoaterea copiilor de pe mașină, prin rsync sau stocare de obiecte, cu păstrare de minim 7 copii zilnice și 4 săptămânale.
• O restaurare făcută efectiv o dată, pe o copie a stivei, nu pe producție.

Criteriu de acceptare

Există cel puțin 7 copii cu dată diferită, în afara serverului de producție. Restaurarea a fost făcută o dată pe o copie a stivei: baza restaurată pornește, iar numărul de comenzi și de produse din ea e egal cu cel din producție la momentul copiei.

Depinde de

Nici cron-ul de pe server, nici spațiul de stocare în afara mașinii nu se pot pune din repo. E nevoie de acces la serverul de producție și de o decizie despre unde se țin copiile; Vitalie confirmă cine deține serverul și cine execută partea de infrastructură.