Un backup website este una dintre cele mai importante măsuri de protecție pentru un proiect online, dar simpla existență a unei copii nu garantează că toate datele vor putea fi recuperate exact așa cum te aștepți.
Un backup poate fi prea vechi, poate conține deja fișiere compromise, poate fi incomplet sau poate restaura datele fără să rezolve problema care a provocat incidentul.
De aceea, atunci când vorbim despre backup trebuie să facem diferența dintre „există o copie” și „putem recupera serviciul în condițiile de care avem nevoie”.
Pe infrastructura NameBox sunt utilizate, în funcție de server și configurație, soluții precum JetBackup și Synconix Backup. În plus, cPanel permite utilizatorului să genereze manual un Full Account Backup.
Aceste mecanisme au roluri diferite și niciunul nu elimină necesitatea unei strategii corecte de backup și recuperare.
1. Backup-ul conține deja fișiere infectate
Să presupunem că un website WordPress este compromis luni, însă problema devine vizibilă abia după două săptămâni.
În această perioadă sunt realizate mai multe copii de siguranță.
Dacă fișierele malițioase existau deja în momentul realizării copiilor, restaurarea unei versiuni recente poate readuce și compromiterea.
De exemplu:
1 octombrie → website compromis 3 octombrie → backup 5 octombrie → backup 8 octombrie → backup 14 octombrie → malware-ul este descoperit
Dacă restaurăm pur și simplu copia din 8 octombrie, există riscul ca fișierele infectate să fie restaurate împreună cu website-ul.
Într-un astfel de caz trebuie identificat aproximativ momentul compromiterii și analizată copia aleasă pentru restaurare.
Trebuie eliminată și cauza inițială:
- plugin vulnerabil;
- temă compromisă;
- parolă furată;
- cont de administrator compromis;
- fișiere malițioase rămase în cont;
- Cron Job malițios;
- versiune veche a aplicației.
Altfel, chiar și un backup curat poate fi compromis din nou după restaurare.
Backup-ul este o metodă de recuperare, nu un înlocuitor pentru securitatea website-ului.
2. Backup-ul este prea vechi
Pentru un website de prezentare, pierderea modificărilor din ultimele câteva ore poate fi neplăcută, dar recuperabilă manual.
Pentru un magazin WooCommerce situația poate fi diferită.
Să presupunem că baza de date este restaurată dintr-o copie realizată ieri la ora 02:00.
Între timp magazinul a primit:
- 20 de comenzi;
- conturi noi de clienți;
- modificări ale stocului;
- actualizări de produse;
- note și statusuri de comandă.
Dacă baza de date este înlocuită cu versiunea din backup, informațiile create după acel punct nu vor exista în copia restaurată.
Aici apare noțiunea de RPO – Recovery Point Objective.
Pe scurt, RPO răspunde la întrebarea:
Cât de multă informație recentă ne permitem să pierdem?
Pentru un blog actualizat o dată pe săptămână, un punct de restaurare de ieri poate fi suficient.
Pentru un magazin care procesează permanent comenzi, necesitatea poate fi complet diferită.
Din acest motiv, frecvența și retenția backup-urilor trebuie raportate la modul în care website-ul este utilizat.
3. Backup-ul există, dar este incomplet sau inutilizabil
Un mesaj de tipul:
Backup completed successfully
este important, dar nu reprezintă singura verificare necesară.
Pot exista situații în care:
- arhiva este incompletă;
- anumite fișiere nu au fost incluse;
- baza de date nu poate fi importată corect;
- backup-ul a fost realizat în timpul unei operațiuni importante;
- spațiul disponibil nu a fost suficient;
- arhiva a fost deteriorată ulterior;
- datele de care ai nevoie nu făceau parte din backup.
cPanel avertizează, de exemplu, că generarea unui backup poate eșua pentru un cont care este aproape de limita de spațiu, deoarece sistemul poate să nu mai poată crea fișierele necesare procesului.
De aceea există o diferență între:
Backup creat
și:
Backup verificat și restaurabil
Cea mai bună verificare este un test de restaurare într-un mediu sigur, acolo unde proiectul și infrastructura permit acest lucru.
Pentru date foarte importante, este recomandat să verifici periodic dacă punctele de restaurare există și dacă datele necesare sunt prezente în ele.
4. Singura copie este în aceeași zonă de risc
O altă problemă apare atunci când singurul backup este păstrat în același loc cu datele originale.
De exemplu, creezi manual:
backup-site.tar.gz
și îl păstrezi în:
/home/username/
Ai o copie separată logic de website, dar aceasta se află tot în același cont și pe aceeași infrastructură.
Dacă problema afectează întregul cont sau spațiul unde este păstrată copia, backup-ul poate deveni indisponibil împreună cu datele originale.
Un principiu cunoscut pentru protejarea datelor este regula 3-2-1:
3 copii ale datelor 2 tipuri de medii sau locații de stocare 1 copie păstrată separat / off-site
Nu înseamnă că fiecare website personal trebuie să implementeze o arhitectură enterprise, dar principiul este foarte util: nu te baza pe o singură copie aflată în aceeași zonă de risc cu datele originale.
De exemplu, un utilizator cPanel poate genera periodic un Full Backup și îl poate descărca într-o locație externă protejată corespunzător.
5. Restaurarea reușește, dar website-ul tot nu funcționează
Restore-ul poate ajunge la 100% și fișierele pot exista din nou pe server, însă acest lucru nu înseamnă neapărat că website-ul este complet funcțional.
Pot exista probleme precum:
- versiunea PHP nu mai este compatibilă;
- un plugin sau o temă continuă să conțină o vulnerabilitate;
- DNS-ul este configurat greșit;
- o integrare externă nu mai răspunde;
- un API și-a schimbat configurația;
- un certificat sau alt element de infrastructură trebuie refăcut;
- cauza inițială a incidentului nu a fost eliminată.
Un exemplu simplu:
Fișiere restaurate ✔ Baza de date restaurată ✔ Website funcțional ✖
În acest caz, backup-ul și-a îndeplinit rolul de recuperare a datelor, dar mai este necesară depanarea aplicației sau infrastructurii.
Acesta este motivul pentru care trebuie să diferențiem restaurarea datelor de recuperarea completă a serviciului.
Ce este RTO?
Pe lângă RPO, în planificarea recuperării mai există o noțiune utilă: RTO – Recovery Time Objective.
În termeni simpli, RTO răspunde la întrebarea:
Cât timp ne permitem ca website-ul să rămână indisponibil?
Pentru un website personal, câteva ore pot fi acceptabile.
Pentru un magazin online care generează vânzări permanent, aceeași perioadă poate avea un impact important.
RPO discută despre cât de recente trebuie să fie datele recuperate, iar RTO despre cât de repede trebuie să revenim în funcțiune.
JetBackup, Synconix și Full Backup: Ce rol are fiecare?
În infrastructura NameBox sunt utilizate mai multe mecanisme de backup, iar acestea nu trebuie tratate ca fiind identice.
JetBackup
JetBackup este o platformă de administrare a backup-urilor integrată cu cPanel.
În funcție de configurația serverului și de permisiunile acordate contului, JetBackup poate permite vizualizarea și restaurarea unor elemente precum:
- fișiere și directoare;
- baze de date;
- utilizatori de baze de date;
- conturi de email;
- conturi FTP;
- Cron Jobs;
- zone DNS;
- certificate SSL;
- backup-uri ale contului.
Nu toate opțiunile trebuie să fie disponibile în orice implementare JetBackup. Conținutul, destinațiile, frecvența și retenția sunt stabilite prin configurația sistemului.
Pentru pașii de restaurare poți consulta tutorialul Cum să faci un restore din cPanel utilizând JetBackup.
Synconix Backup
Synconix Backup este o altă soluție utilizată în infrastructura NameBox.
Documentația Synconix descrie un sistem centralizat de backup cu restore points și posibilitatea restaurării selective a datelor.
În implementarea documentată pentru clienții NameBox, Synconix poate fi accesat din cPanel și permite restaurarea unor elemente precum:
- fișiere;
- foldere;
- baze de date MySQL.
Pentru fișiere, utilizatorul poate selecta restaurarea în locația originală sau, în anumite situații, într-o locație alternativă pentru verificare înainte de suprascrierea datelor existente.
Detalii găsești în tutorialul Cum facem restore din cPanel utilizând Synconix Backup.
Nu folosim în acest articol o perioadă fixă de retenție pentru Synconix sau JetBackup, deoarece numărul și perioada punctelor disponibile pot depinde de server și de politica de backup aplicată.
Full Backup din cPanel
cPanel permite utilizatorului să genereze manual o arhivă completă a contului.
Funcția poate fi accesată din:
cPanel → Files → Backup → Download a Full Account Backup
O astfel de arhivă poate conține numeroase elemente ale contului, inclusiv:
- fișierele din home directory;
- website-urile;
- baze de date MySQL;
- configurații ale contului;
- Cron Jobs;
- certificate SSL;
- date asociate serviciilor configurate în cont.
Arhiva este generată în format:
.tar.gz
Full Backup este foarte util înainte de:
- upgrade-uri importante;
- migrări;
- modificări majore;
- operațiuni cu risc asupra bazei de date.
Poți consulta pașii compleți în ghidul Cum să creezi o arhivă de Full Backup din cPanel.
Este important însă să reținem două lucruri.
În primul rând, generarea unui Full Backup este o acțiune manuală și nu trebuie confundată cu un sistem automat de backup.
În al doilea rând, cPanel precizează că un Full Account Backup nu poate fi restaurat automat de utilizator direct din cPanel. Restaurarea completă este o operațiune disponibilă administratorului prin WHM și poate necesita intervenția furnizorului de hosting.
De ce merită să descarci Full Backup în altă locație?
Dacă generezi arhiva și o lași doar în Home Directory, aceasta se află în continuare în contul de găzduire.
Pentru date importante este util să descarci copia într-o locație independentă, de exemplu un sistem de stocare propriu sau un serviciu cloud protejat corespunzător.
Astfel reduci dependența de un singur punct de stocare.
Ține cont și de spațiul disponibil: arhiva generată local poate ocupa o cantitate semnificativă din quota contului.
Ce ar trebui să verifici periodic?
O strategie simplă de backup poate include:
- verificarea periodică a punctelor de restaurare disponibile;
- confirmarea faptului că datele importante sunt incluse;
- păstrarea unei copii suplimentare pentru proiectele critice;
- generarea unui Full Backup înainte de modificări majore;
- verificarea perioadei de retenție disponibile;
- testarea restaurării atunci când proiectul permite;
- păstrarea unor evidențe suplimentare pentru comenzile și datele importante ale magazinelor online.
Un restore testat valorează mai mult decât simpla existență a unei arhive
Un backup este valoros numai dacă datele necesare există în el și pot fi recuperate atunci când ai nevoie de ele.
De aceea, o strategie bună nu se oprește la:
„Avem backup.”
Întrebările mai importante sunt:
Din ce moment avem backup? Ce date conține? Unde este păstrat? Poate fi restaurat? În cât timp putem reveni online? Câtă informație riscăm să pierdem?
JetBackup, Synconix Backup și Full Backup din cPanel oferă metode diferite prin care datele pot fi protejate și recuperate, însă alegerea punctului corect de restaurare și verificarea funcționării website-ului rămân la fel de importante.
Backup-ul nu trebuie privit ca o garanție absolută, ci ca o componentă esențială a unui plan mai larg de securitate și recuperare.
Pentru mai multe informații despre procesul de recuperare poți consulta și articolul nostru Backup website: Cum îți recuperezi site-ul după un incident.
Pe pagina noastră HelpDesk găsiți multe alte tutoriale utile pentru a gestiona mai ușor contul dvs. cPanel.