Un plan robust de salvare și recuperare în caz de dezastru (Disaster Recovery) este piatra de temelie a oricărei infrastructuri de producție. Pierderile de date pot apărea dintr-o pană hardware, un ransomware sau o simplă eroare umană (DROP TABLE sau DELETE fără clauza WHERE). Acest ghid explică cum să implementați o strategie completă compusă din backup-uri complete consistente și jurnale binare (Binary Logs) pentru a recupera datele până la milisecunda dinaintea incidentului.
# Executarea unui backup complet InnoDB fără a bloca traficul web (fără downtime!)
mysqldump \
--user=dexter_admin \
--password \
--single-transaction \
--quick \
--routines \
--triggers \
--events \
--source-data=2 \
--hex-blob \
numebd | gzip > /backups/mysql_numebd_$(date +%F_%H%M%S).sql.gzDe ce sunt esențiale aceste flag-uri:
| Opțiune mysqldump | Rol & Importanță Critică |
|---|---|
--single-transaction |
Pornește o tranzacție cu nivelul REPEATABLE READ. Permite salvarea unei stări perfect consistente a tuturor tabelelor InnoDB fără a emite LOCK TABLES! Aplicația web poate continua să scrie și să citească liber în timpul dump-ului. |
--quick |
Forțează mysqldump să citească rândurile pe măsură ce sosesc din server, în loc să încarce tot tabelul în memoria RAM a clientului. Previne blocarea memoriei pe tabele de zeci de gigaocteți. |
--source-data=2(anterior --master-data=2) |
Scrie în header-ul fișierului de dump poziția exactă a fișierului binar log în momentul tranzacției (ex: -- CHANGE REPLICATION SOURCE TO SOURCE_LOG_FILE='binlog.000045', SOURCE_LOG_POS=789123;) sub formă de comentariu. Acest rând este esențial pentru PITR! |
--routines --triggers --events |
Include procedurile stocate, funcțiile, trigger-ele și joburile programate în backup. |
--hex-blob |
Descarcă coloanele binare (BLOB, VARBINARY, imagini) în format hexazecimal, prevenind coruperea de caractere speciale la restaurare. |
Ce sunt Binary Logs și de ce sunt obligatorii?
Fișierele Binary Log (binlog) înregistrează toate evenimentele care modifică starea bazei de date (instrucțiuni DDL precum CREATE TABLE și instrucțiuni DML precum INSERT, UPDATE, DELETE). Fără binlog activat, un backup realizat la ora 02:00 noaptea înseamnă că dacă serverul pică la 15:00, ați pierdut ireversibil 13 ore de activitate!
Pentru activare, asigurați-vă că aveți în /etc/my.cnf sau mysql.cnf:
[mysqld]
server_id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW
binlog_expire_logs_seconds = 604800 # Păstrează logurile timp de 7 zile
sync_binlog = 1 # Scriere sincronă pe disc la fiecare commit (fiabilitate maximă)Scenariu Real: Restaurare Point-in-Time Recovery (PITR)
Imaginați-vă următorul incident: la ora 14:35:22, un dezvoltator a rulat din greșeală pe producție DELETE FROM clienti;. Ultimul backup complet automat a fost generat noaptea trecută la ora 02:00:00.
# Pasul 1: Izolăm baza de date și restaurăm ultimul backup complet nocturn
gunzip < /backups/mysql_numebd_2026-10-24_020000.sql.gz | mysql -u root -p numebd
# Pasul 2: Citim poziția de pornire din dump-ul nocturn
grep "CHANGE REPLICATION SOURCE" /backups/mysql_numebd_2026-10-24_020000.sql
# Output: SOURCE_LOG_FILE='binlog.000012', SOURCE_LOG_POS=415;
# Pasul 3: Extragem toate modificările din binlog începând de la poziția respectivă
# și ne oprim EXACT cu o secundă înainte de comanda dezastruoasă (ora 14:35:21)
mysqlbinlog \
--start-position=415 \
--stop-datetime="2026-10-24 14:35:21" \
--database=numebd \
/var/log/mysql/binlog.000012 /var/log/mysql/binlog.000013 > /tmp/recuperare_tranzactii.sql
# Pasul 4: Aplicăm tranzacțiile salvate
mysql -u root -p numebd < /tmp/recuperare_tranzactii.sql
# Datele au fost recuperate complet fără comanda distructivă de DELETE!Verificarea și Automatizarea Backup-urilor
Un backup care nu este testat periodic nu oferă nicio garanție. Implementați un script automat (de exemplu un cron săptămânal) care descarcă cel mai recent fișier de dump, îl restaurează pe o instanță de test/staging izolată, execută interogări de integritate (CHECK TABLE) și raportează succesul pe Slack/Email.