Backup automat WordPress: Strategii complete pentru protecția datelor

Backup automat WordPress: Strategii complete pentru protecția datelor, fiindcă o copie recentă este singura protecție reală împotriva pierderii site-ului: infecții, actualizări care strică, ștergeri din greșeală, defecțiuni ale serverului sau conturi suspendate. Un site WordPress construit în ani se pierde în minute, iar diferența dintre o dimineață proastă și o catastrofă este o copie recentă, păstrată în alt loc și testată. Ghidul descrie strategia pe trei niveluri pe care o aplicăm pe site-urile administrate, cu configurarea fiecăruia.

Copia unui site WordPress are două părți: fișierele (teme, module, imagini încărcate, wp-config.php) și baza de date (articole, pagini, setări, utilizatori, comenzi). Ambele sunt necesare pentru restaurare; o copie doar a fișierelor sau doar a bazei nu repune site-ul pe picioare.

Backup automat WordPress: strategii complete pentru protecția datelor

Cele trei niveluri

1. Nivelul aplicației: un modul WordPress (UpdraftPlus, BackWPup) sau WP-CLI din cron, cu trimitere în cloud. Îl controlați dumneavoastră, îl restaurați singur.
2. Nivelul contului de găzduire: copiile din cPanel (Backup, Backup Wizard, JetBackup unde există), pe server sau pe destinație externă.
3. Nivelul furnizorului: copiile pe care le face găzduirea pentru sine, de obicei zilnice, păstrate 7-30 de zile; le cereți prin tichet.

Fiecare nivel acoperă eșecurile celuilalt: modulul nu ajută dacă nu mai aveți acces la site, cPanel nu ajută dacă furnizorul a suspendat contul, furnizorul nu ajută dacă și-a pierdut serverul. Cu toate trei, o singură copie trebuie să funcționeze.

Nivelul 1: din WordPress

UpdraftPlus

Cel mai folosit modul de copii, cu peste 3 milioane de instalări active; versiunea gratuită acoperă site-urile obișnuite. După instalare, din Settings, UpdraftPlus Backups, fila Settings: programați fișierele zilnic sau săptămânal cu 3-7 copii păstrate, baza de date zilnic cu 7-14 copii, și alegeți o destinație externă: Google Drive, Dropbox, Amazon S3, FTP pe alt server. Autentificați destinația, salvați, apoi rulați o copie manuală și verificați că fișierele apar în cloud. Excludeți dosarele de cache din copie, ca arhiva să nu crească inutil.

BackWPup

Alternativă cu configurări mai fine: sarcini separate pentru fișiere și bază de date, formate tar.gz sau zip, verificarea integrității arhivei, destinații multiple. Potrivit când vreți copii diferite pentru părți diferite ale site-ului (baza de date la oră, fișierele săptămânal).

WP-CLI și cron, fără modul

Pe găzduirile cu acces la terminal și WP-CLI, două comenzi și un cron fac tot ce face un modul, fără cod suplimentar în site:

cd ~/public_html
wp db export ~/backup/baza-$(date +%F).sql.gz --add-drop-table 2>/dev/null || wp db export ~/backup/baza-$(date +%F).sql
tar -czf ~/backup/fisiere-$(date +%F).tar.gz --exclude='wp-content/cache' wp-content wp-config.php .htaccess
find ~/backup -type f -mtime +14 -delete

Programarea din cPanel, Cron Jobs, la 3:00, este descrisă în ghidul despre programarea sarcinilor cron în cPanel. Dosarul backup trebuie să fie în afara public_html, altfel arhivele sunt descărcabile de oricine le ghicește numele. Trimiterea pe alt server se face cu rsync, cum arătăm în ghidul despre copiile de siguranță cu cron și rsync.

Nivelul 2: din cPanel

Unealta Backup descarcă o copie completă a contului sau părți din el; Backup Wizard face același lucru ghidat. Pentru copii automate, unele găzduiri oferă JetBackup sau opțiunea de programare din WHM; dacă nu, o copie manuală lunară, descărcată local, rămâne obligatorie. Pașii, inclusiv restaurarea, sunt în ghidurile despre copiile manuale și copiile automate în cPanel. Copia completă cPanel include și e-mailul, pe care modulele WordPress nu îl ating.

Regula 3-2-1

Trei copii ale datelor, pe două tipuri de suport, dintre care una în alt loc. Pentru un site WordPress: copia de pe server (cPanel sau modul), copia din cloud (Google Drive, S3) și copia de pe un calculator sau server propriu, descărcată periodic. Stocarea copiilor doar pe serverul site-ului este cea mai frecventă greșeală: un atacator care intră pe server șterge sau criptează și copiile, iar o suspendare a contului le face inaccesibile.

Frecvența, pe tip de site

Tip de site	Baza de date	Fișierele	Păstrare
Magazin online	la fiecare oră	zilnic	30 de zile pentru baza de date, 14 pentru fișiere
Blog sau site de știri	zilnic	zilnic	14-30 de zile
Site de prezentare	săptămânal	săptămânal	3 luni, plus o copie înainte de orice modificare
Site cu cursuri sau membri	la fiecare oră	zilnic	30 de zile

Baza de date a unui magazin conține comenzile; o copie de ieri înseamnă comenzile de azi pierdute. Fișierele se schimbă rar (imagini noi, actualizări), deci pot fi copiate mai rar, dar complet.

Testul de restaurare

O copie netestată este o presupunere. O dată pe lună, restaurați copia pe un subdomeniu de test (test.exemplu.ro), într-o bază de date separată, și deschideți site-ul: prima pagină, o pagină de produs sau de articol, autentificarea în administrare, o încărcare de imagine. Cu WP-CLI, după restaurare:

wp db import ~/backup/baza-2026-09-01.sql
wp search-replace 'https://www.exemplu.ro' 'https://test.exemplu.ro' --skip-columns=guid
wp core verify-checksums
wp plugin verify-checksums --all

Ultimele două comenzi confirmă că fișierele WordPress și ale modulelor sunt cele originale, nu modificate; sunt și un test de malware. Notați data testului și durata restaurării; un client care știe că restaurarea durează 25 de minute nu intră în panică la un incident.

Ce conține de fapt o copie WordPress

Dosarul wp-content este partea care nu se poate reface din altă parte: uploads (imaginile și documentele încărcate, de obicei cea mai mare parte a copiei), themes (tema și modificările ei, mai ales dacă aveți o temă-copil), plugins (modulele, cu setările lor în baza de date, nu în dosar) și, uneori, languages sau dosare create de module (cache, copii, jurnale). Fișierul wp-config.php conține datele de conectare la baza de date și cheile de securitate; .htaccess conține regulile de rescriere și de securitate. Nucleul WordPress (wp-admin, wp-includes și fișierele din rădăcină) se poate descărca oricând de pe wordpress.org, deci copierea lui e opțională, dar simplifică restaurarea. Baza de date conține tot restul: conținutul, utilizatorii cu parolele lor criptate, setările modulelor, comenzile, comentariile.

O copie „a fișierelor” care sare peste uploads (fiindcă e mare) nu este o copie; la restaurare aveți site-ul fără nicio imagine. Verificați în arhivă că dosarul uploads este complet, cu subdosarele pe ani și luni.

Copii înainte de actualizări

Actualizările de nucleu, de temă și de module sunt cea mai frecventă cauză de site stricat, iar copia de dinainte este remediul de un minut. Modulele de copii au opțiunea de copie automată înainte de actualizări (UpdraftPlus o are în versiunea plătită, alte module gratuit); WP-CLI o face cu comenzile de export de mai sus, rulate înainte de wp core update și wp plugin update --all. Pe site-urile pe care le administrăm, actualizările se fac după o copie, pe un site de test întâi, apoi pe cel real, după procedura din ghidul despre actualizarea WordPress, a temelor și a modulelor.

Când se restaurează și când nu

• După o actualizare care a stricat site-ul: restaurați doar fișierele modulului sau temei, nu tot site-ul, ca să nu pierdeți conținutul adăugat între timp.
• După o infecție: nu restaurați peste fișierele existente; ștergeți site-ul, restaurați dintr-o copie de dinaintea infecției și actualizați totul înainte de a-l pune la loc, după pașii din ghidul despre detectarea și eliminarea malware-ului.
• După ștergerea unui articol sau a unei pagini: restaurați doar tabela sau rândul, dintr-un export, nu toată baza.
• La migrare: copia este punctul de plecare, iar pașii sunt în ghidul despre migrarea unui site WordPress.

Copiile și securitatea lor

O arhivă cu tot site-ul conține wp-config.php cu parola bazei de date și exportul bazei cu adresele de e-mail ale clienților. Tratați copiile ca pe date sensibile: destinația cloud cu autentificare în doi pași, dosarul de pe server în afara public_html și cu permisiuni 700, arhivele criptate dacă părăsesc infrastructura proprie (UpdraftPlus poate cripta baza de date în versiunea plătită; gpg o face gratuit din terminal). Un magazin online are, prin GDPR, obligația de a proteja și copiile, nu doar site-ul; regulile sunt în ghidul despre GDPR și securitatea datelor pentru WordPress.

Greșeli frecvente

• Modulul de copii instalat, dar destinația neautentificată: copiile rămân pe server.
• Copii care includ dosarul de cache și ajung la 5 GB, apoi eșuează din lipsă de spațiu.
• Copia bazei de date fără tabelele cu alt prefix (module care își fac tabele proprii).
• Parola de la destinația cloud salvată în modul și accesibilă oricui are acces de administrator la site.
• Nicio copie înainte de actualizări majore, deși durează un minut.
• Copii zilnice timp de trei ani, niciodată restaurate.

Copiile sunt jumătate din securitatea unui site WordPress; cealaltă jumătate, prevenția, este în ghidul despre securizarea unui site WordPress. Dacă administrăm noi site-ul, cele trei niveluri și testul lunar fac parte din întreținerea lunară.

Surse

• Documentația WordPress, copiile de siguranță: ce trebuie copiat și metodele recomandate.
• Documentația cPanel, Backup Wizard: copia completă și parțială a contului.