Un backup pe care chiar îl poți folosi
Cele mai multe firme află că backupul nu funcționează abia când se produce dezastrul. De aceea îți recomandăm să tratezi backupul ca pe un proces, nu ca pe o bifă: copii automate, păstrate separat de serverul de producție, și restaurări testate periodic. Pe cPanel backupul zilnic rulează automat și îl restaurezi din panou; pe VPS și pe serverele dedicate, echipa DevOps poate configura teste de restaurare programate, din orele tale incluse.
Ce backup include fiecare plan
Găzduirea cPanel are backup zilnic automat, pe care îl restaurezi din panou. Un VPS are snapshoturi — copii complete ale stării serverului —, fără o frecvență garantată. Serverele dedicate nu includ backup implicit: discurile NVMe vin în pereche, iar RAID-ul se configurează la instalare, dar RAID-ul nu e backup. Backupul extern, PITR pentru baze de date și testele de restaurare le configurează echipa din orele DevOps incluse (5–10 h/lună pe dedicate).
| Plan | Backup | Restaurare | Locație |
|---|---|---|---|
| Găzduire cPanel | Backup zilnic automat | Din panoul de client | UE (Frankfurt) |
| VPS | Snapshoturi, fără frecvență garantată | Dintr-un snapshot | UE (Frankfurt) |
| VPS — backup extern | La cerere, din orele DevOps | După strategia configurată | Stabilită cu echipa |
| Server dedicat | Neinclus implicit — configurat la cerere | După strategie (3-2-1, PITR) | UE (Frankfurt) + stocare externă la cerere |
RPO și RTO — valorile pe care e bine să ți le stabilești
În loc de „facem backup cât mai repede", merită să fixezi două valori concrete. RPO (Recovery Point Objective) îți spune câte date îți permiți să pierzi. RTO (Recovery Time Objective) îți spune cât are voie să dureze restaurarea. Echipa configurează strategia pornind de la aceste valori.
Pierderea maximă de date pe care o poți accepta. Un backup zilnic înseamnă până la o zi pierdută; cu streaming WAL, o bază de date coboară sub un minut — configurat la cerere.
Durata restaurării depinde de volumul datelor și de strategia aleasă. Nu garantăm un RTO — singura cifră de încredere e cea măsurată la un test de restaurare.
Scenarii de dezastru — și cum te protejezi
Dezastrele sunt rare, dar au impact mare. Mai jos, scenariile cele mai frecvente și măsura de protecție pe care o recomandăm pentru fiecare. Pe VPS și pe serverele dedicate, echipa configurează aceste măsuri din orele DevOps incluse.
Defecțiune hardware (disc, memorie)
Cea mai frecventă cauză de pierdere a datelor. Pe serverele dedicate, discurile NVMe vin în pereche, cu RAID configurat la instalare, iar treptele EPYC și Xeon au memorie ECC. RAID-ul ține serverul în funcțiune când cade un disc, dar nu înlocuiește backupul — o copie externă rămâne necesară.
Protecție: RAID + backup externRansomware sau cont compromis
Atacatorul criptează fișierele de pe server — și orice copie la care serverul are acces. De aceea, cel puțin o copie trebuie să stea în afara serverului, unde contul de producție nu o poate modifica (imutabilă sau offline). O configurăm la cerere, din orele DevOps.
Protecție: copie izolatăȘtergere accidentală de date
Un „DROP TABLE users" rulat din greșeală pe producție. Cea mai frecventă eroare umană. Dacă baza de date are configurată recuperarea la un moment dat (PITR), revii la momentul de dinaintea greșelii; un backup zilnic te duce doar la ultima copie.
Protecție: PITR la cerereCăderea completă a centrului de date
Incendiu, inundație sau avarie prelungită la operator. Protecția e o copie într-o altă locație, de exemplu într-un al doilea centru de date. Replicarea și failoverul nu sunt incluse implicit; echipa le configurează la cerere, din orele DevOps.
Protecție: copie în altă locațieUn bug din aplicație corupe datele
O lansare introduce un bug care strică înregistrările din baza de date. Cu un backup separat al bazei de date restaurezi doar baza, nu tot serverul — fișierele aplicației rămân, datele se întorc în urmă.
Protecție: backup separat al bazeiMutarea pe alt server
Ai depășit planul actual. Un VPS trece pe o treaptă superioară, cu mai multe vCPU, RAM și disc; pentru mutarea pe alt server planificăm migrarea din timp, ca întreruperea să fie scurtă.
Sfat: planifică migrarea din timpBackup pentru baze de date — strategii per motor
Un backup complet al VPS-ului nu e întotdeauna suficient. Bazele de date au mecanisme proprii de recuperare la un moment dat (PITR), care te duc înapoi exact la momentul ales, nu doar la ultimul snapshot. Le configurăm la cerere, din orele DevOps incluse.
Ce e inclus — și ce se configurează la cerere
Nu există un „backup premium" vândut separat: ce e inclus scrie la fiecare plan, iar tot ce trece de atât îl construiește echipa din orele DevOps ale abonamentului tău. Orele peste cotă se facturează separat, la oră.
- cPanel: backup zilnic automat, restaurare din panou — inclus
- VPS: snapshoturi, fără frecvență garantată — inclus
- Servere dedicate: discuri NVMe în pereche, RAID configurat la instalare — backupul nu e inclus implicit
- Backup extern după regula 3-2-1 — la cerere, din orele DevOps (5–10 h/lună pe dedicate)
- PITR pentru baze de date (WAL, binlog, oplog) — la cerere, din orele DevOps
- Teste de restaurare și perioada de retenție — stabilite cu echipa și configurate din orele DevOps
Restaurarea unui backup — în 4 pași
Deschide panoul
Autentifică-te în panoul de client. Pe cPanel restaurezi de acolo backupul zilnic, iar pe VPS alegi un snapshot.
Alege momentul
Alege copia cu starea de dinaintea problemei. Cea mai recentă nu e întotdeauna cea bună, dacă eroarea există de mai mult timp.
Apasă „Restaurează"
Restaurarea suprascrie starea curentă. Dacă nu ești sigur, cere echipei să restaureze mai întâi într-un mediu separat, ca să poți compara.
Verifică rezultatul
Verifică dacă aplicația funcționează și datele sunt la locul lor. Cât durează restaurarea depinde de volumul datelor.
Întrebări frecvente
Snapshotul presupune oprirea serverului?
De regulă, nu: snapshotul unui VPS se face cu serverul pornit. Pentru o bază de date însă, snapshotul unui server în funcțiune nu e întotdeauna consistent, așa că recomandăm un backup separat al bazei (dump sau WAL/binlog), pe care echipa îl configurează la cerere.
Cât durează restaurarea unui snapshot foarte mare, de exemplu 500 GB?
Depinde de volumul datelor, de disc și de locul unde stă copia — dintr-o copie externă durează mai mult decât dintr-una locală. Nu promitem o durată fixă: cifra realistă o dă un test de restaurare, pe care îl putem face împreună cu tine.
Backupurile sunt criptate?
Criptarea backupurilor externe face parte din strategia pe care o configurăm la cerere — de exemplu copii care pleacă de pe server doar criptate, cu cheile păstrate separat de producție. Spune-i echipei cerințele tale când soliciți configurarea.
Ce fac dacă am nevoie de retenție mai mare de 30 de zile?
Retenția backupurilor externe se stabilește când echipa configurează strategia, în funcție de nevoile tale și de obligațiile legale de arhivare. Spațiul pentru o retenție mai lungă îl stabilești cu echipa; planurile le găsești pe pagina de prețuri.
Pot descărca local un snapshot?
Pe VPS și pe serverele dedicate ai acces root și îți copiezi datele cu uneltele pe care le preferi (rsync, tar). Echipa poate configura, din orele DevOps, și copii automate către o stocare externă, de exemplu AWS S3, Google Cloud Storage ori Azure Blob.
Datele tale sunt prea valoroase ca să le lași la voia întâmplării
cPanel include backup zilnic, iar VPS-ul snapshoturi. Pe serverele dedicate, echipa construiește strategia de backup din orele DevOps incluse. Vezi pagina de prețuri pentru detalii.
Vezi planurile →