Backup

Databasement: backup-uri de baze de date self-hosted, cu program si restore

Exista o lectie pe care fiecare administrator o invata o singura data, si de obicei pe pielea lui: un snapshot al masinii virtuale nu e un backup de baza de date. Restaurezi VM-ul, baza porneste dintr-o stare inconsistenta la mijlocul unei tranzactii, si descoperi ca “aveam backup” nu inseamna “pot recupera datele”. Backup-ul corect de baza de date e un dump logic, consistent, luat de motorul bazei insusi, pastrat undeva in afara, si testat ca stii sa-l restaurezi. Problema e ca sa faci asta pentru zece baze pe cinci servere, cu program si retentie, se transforma repede intr-o mocirla de scripturi cron pe care nimeni nu le mai intelege.

Databasement , managerul open-source de backup-uri de baze de date scris de David Courty , rezolva exact aceasta mocirla cu o interfata web unica. E licentiat sub MIT, aduna peste 1.800 de stele pe GitHub, si il rulam noi self-hosted in datacenterul nostru din Bucuresti. Acest articol e raportul de teren.

Ce este, mai exact, Databasement

Databasement e un manager centralizat de backup-uri pentru baze de date. In loc de scripturi cron imprastiate pe fiecare server, ai o singura aplicatie web unde definesti serverele de baze de date, spui ce sa fie salvat si cat de des, unde sa ajunga backup-urile si cat sa fie pastrate, iar aplicatia se ocupa de restul: ruleaza dump-urile la program, le comprima, le urca in stocarea aleasa, si iti da un buton de restore cand ai nevoie.

Sloganul lui, “backup-urile tale merita un loc sigur in care sa traiasca”, nu e doar marketing. Ideea centrala e ca backup-ul e un flux, nu un fisier: se ia, se muta in afara, se pastreaza dupa o politica, si trebuie sa poata fi restaurat. Databasement modeleaza exact acest flux, cu vizibilitate pe fiecare pas.

Ce baze si ce destinatii acopera

Aici Databasement e surprinzator de complet pentru un proiect open-source. Suporta din cutie:

Baze de date: MySQL, MariaDB, PostgreSQL, Microsoft SQL Server, MongoDB, SQLite, Firebird si Redis/Valkey. Practic tot ce ai putea rula.
Destinatii de stocare: local, S3-compatibil (AWS, MinIO, Backblaze), Azure Blob, Samba/SMB, SFTP si FTP. Backup-ul care ramane pe acelasi server nu e un backup, iar Databasement iti da usor destinatii externe.
Compresie si criptare: gzip, zstd, sau AES-256 pentru backup-uri criptate.
Tunele SSH si agenti remote: ca sa ajungi la baze din spatele unui bastion sau dintr-o retea privata, fara sa expui portul bazei.
Notificari: email, Slack, Discord, Telegram, Pushover, Gotify si webhook-uri, ca sa afli imediat cand un backup a esuat.

Peste toate astea, are control de acces cu SSO (Google, GitHub, GitLab, OpenID Connect), 2FA si permisiuni pe roluri, plus un API REST si chiar un server MCP pentru automatizare. E mult mai mult decat “un cron cu UI”.

Instalare Databasement

Databasement e o aplicatie Laravel impachetata elegant intr-un singur container. Cea mai simpla varianta te pune pe picioare cu SQLite ca stocare de configurare interna, deci nu ai nevoie de o baza separata doar ca sa rulezi managerul de backup-uri:

docker run -d --name databasement -p 2226:2226 \
  -e DB_CONNECTION=sqlite \
  -e DB_DATABASE=/data/database.sqlite \
  -e ENABLE_QUEUE_WORKER=true \
  -e PUID=1000 -e PGID=1000 \
  -v ./databasement-data:/data \
  davidcrty/databasement:1

Ridici containerul, deschizi UI-ul pe portul 2226, iti creezi contul de admin la prima accesare, si de acolo adaugi serverele de baze de date si job-urile de backup din interfata.

Un detaliu care conteaza mult si merita subliniat: ENABLE_QUEUE_WORKER=true nu e optional daca vrei backup-uri programate. Databasement isi ruleaza scheduler-ul in acelasi proces cu worker-ul de coada. Fara flag-ul asta, aplicatia porneste, UI-ul merge, dar job-urile programate nu se declanseaza niciodata, pentru ca nu exista cine sa le execute. E capcana clasica in care cazi daca urmezi un compose minimalist. Noi il rulam exact in modul asta, single-container cu worker-ul pornit, tocmai ca scheduler-ul sa fie viu.

Ca la orice tool care detine credentiale catre toate bazele tale, nu il expune public fara autentificare. Are login nativ, dar noi il tinem si in spatele SSO-ului nostru, pentru ca o aplicatie care poate face restore-uri distructive pe productie merita dublu gard. Minim, restrictioneaz-o prin firewall si pune un reverse proxy cu TLS in fata.

Daca rulezi asta pe un VPS DreamServer , tine minte ca backup-urile in sine trebuie sa ajunga in stocare externa (S3, alt server), nu pe acelasi disc, altfel un incident ia si baza, si backup-ul odata.

Tipare de configurare care merita stiute

Cateva lucruri utile dincolo de default-uri.

Backup-ul trebuie sa plece de pe server

Regula de aur: un backup pe acelasi disc cu baza nu te salveaza de o defectiune de disc sau de un ransomware. Configureaza o destinatie externa (S3, SFTP catre alt server, SMB) de la prima zi. Databasement face asta parte din definitia job-ului, foloseste-o.

Testeaza restore-ul, nu doar backup-ul

Un backup pe care nu l-ai restaurat niciodata e o teorie, nu o siguranta. Foloseste functia de restore cross-server a Databasement ca sa restaurezi periodic un backup intr-o baza de test si sa confirmi ca datele sunt acolo. Ziua in care ai nevoie de restore nu e ziua in care vrei sa afli ca dump-ul era corupt.

Retentie pe niveluri

Nu pastra tot la infinit, dar nu pastra nici doar ultima copie. O politica sanatoasa e cateva zilnice, cateva saptamanale, cateva lunare. Databasement suporta politici de retentie pe job, exact ca sa nu-ti umple stocarea si sa ai totusi adancime istorica.

Tunele SSH pentru baze private

Nu expune niciodata portul 3306 sau 5432 la internet doar ca sa il atinga tool-ul de backup. Databasement se conecteaza prin tunel SSH sau printr-un agent remote, deci baza ramane in reteaua ei privata iar backup-ul tot ajunge la ea.

Unde Databasement nu e raspunsul potrivit

Merita sa fim onesti despre limite.

Nu e backup de fisiere sau de masina intreaga. Databasement face dump-uri de baze de date. Pentru fisiere, volume sau imagini de VM ai nevoie de alt tool (un Proxmox Backup , restic, borg). Cele doua se completeaza.
Nu inlocuieste replicarea. Un backup zilnic iti da un punct de recuperare de ieri, nu failover in timp real. Pentru disponibilitate ai nevoie de replicare sau cluster; backup-ul e plasa de siguranta, nu HA.
Restore-ul e responsabilitatea ta sa il testezi. Tool-ul iti da butonul, dar increderea vine doar din a-l apasa periodic pe date reale.
E inca un serviciu stateful de intretinut. Are propria baza SQLite, propriile credentiale, propriul UI de patch-uit. Merita, dar il tratezi ca infrastructura, cu backup al propriei configurari.

Alternative pe care le-am luat in calcul

Pentru completitudine: ne-am uitat si la scripturile clasice cu mysqldump/pg_dump plus cron (functioneaza, sunt gratis, dar devin repede o mocirla fara vizibilitate, notificari sau restore usor), la Bacula si Bareos (sisteme de backup de enterprise foarte capabile, dar grele si centrate pe fisiere, nu pe baze de date), si la solutiile native de cloud (RDS snapshots etc., excelente daca esti deja acolo, inutile self-hosted). Pentru “vreau un singur loc unde imi vad si programez backup-urile tuturor bazelor, cu restore cu un click”, Databasement e cel mai direct la tinta.

Deci, sa-l rulezi?

Daca administrezi mai mult de o baza de date si backup-ul tau actual e un script cron pe care nu l-ai mai verificat de luni, Databasement merita dupa-amiaza de setup. Prima data cand vezi in dashboard toate bazele tale cu ultimul backup verde langa fiecare, cu program si retentie si stocare externa, si stii ca poti restaura oricare cu un click, vei intelege diferenta dintre “sper ca am backup” si “stiu ca pot recupera”.

Noi rulam Databasement single-container, cu worker-ul pornit ca scheduler-ul sa fie viu, in spatele SSO-ului, pentru bazele infrastructurii noastre. Daca vrei sa-l incerci pe infrastructura pe care nu trebuie sa o construiesti tu intai, planurile noastre VPS sunt perfecte pentru un mic manager de backup-uri, iar serviciul de administrare server acopera instalarea, destinatiile de stocare si testarea restore-ului daca preferi sa sari peste curba de invatare.

Oricum ai alege, sa-ti pui backup-urile bazelor in ordine e cea mai buna asigurare ieftina din IT. Codul e pe GitHub, exista un demo public pe care il poti atinge acum, si vei sti intr-o ora daca isi castiga un loc in infrastructura ta.