Ghid complet pentru backup automat în cPanel

Ghid complet pentru backup automat în cPanel, pentru proprietarii de conturi care vor copii de siguranță fără să se gândească la ele. cPanel are unealta Backup pentru copii manuale, dar automatizarea depinde de ce a activat furnizorul: unii oferă JetBackup sau copii zilnice cu restaurare din panou, alții doar copiile lor interne, la care nu aveți acces direct. Ghidul arată ce verificați în cont, cum automatizați singur cu cron când lipsește opțiunea, unde trimiteți copiile și cum vă asigurați că se pot restaura.

Principiul de la care pornim: copia furnizorului este pentru furnizor; copia dumneavoastră, în alt loc, este pentru dumneavoastră. Aveți nevoie de amândouă.

Ghid complet pentru backup automat în cPanel

Ce poate oferi panoul

Unealtă	Ce face	Automat?	Cine restaurează
Backup / Backup Wizard	copie completă sau parțială, la cerere	nu	dumneavoastră (parțiale), furnizorul (completă)
JetBackup (dacă e instalat)	copii programate ale contului, cu restaurare pe fișiere, baze, e-mail	da	dumneavoastră, din panou
Copiile furnizorului (WHM Backup Configuration)	copii zilnice sau săptămânale ale serverului	da	furnizorul, prin tichet; uneori din panou
Cron + script propriu	export baze de date și arhivă fișiere, trimise în alt loc	da	dumneavoastră
Module în aplicație (UpdraftPlus etc.)	copii ale site-ului WordPress în cloud	da	dumneavoastră, din aplicație

Pasul 1: verificați ce aveți

Files: dacă există JetBackup sau o unealtă numită Backups cu listă de puncte de restaurare, furnizorul oferă copii automate accesibile; deschideți-o și verificați data ultimei copii și perioada de păstrare. Dacă există doar Backup și Backup Wizard, copiile automate ale furnizorului sunt invizibile din panou; întrebați prin tichet: cât de des, cât păstrează, cât durează o restaurare și dacă e gratuită. Răspunsurile vagi înseamnă că nu vă bazați pe ele.

Pasul 2: copia proprie automată, cu cron

Funcționează pe orice cont cu Cron Jobs, indiferent de furnizor. Scriptul exportă bazele de date și arhivează fișierele site-ului în dosarul backup din dosarul personal (în afara public_html), păstrează 14 zile și, opțional, trimite copia în alt loc. Salvați-l ca ~/bin/backup.sh cu permisiuni 700:

#!/bin/bash
set -e
AZI=$(date +%F)
DEST=$HOME/backup
mkdir -p "$DEST"
# bazele de date ale contului (numele lor le vedeți în MySQL Databases)
for B in cont_site cont_magazin; do
  mysqldump --single-transaction "$B" | gzip > "$DEST/$B-$AZI.sql.gz"
done
# fișierele site-urilor, fără cache
tar -czf "$DEST/public_html-$AZI.tar.gz" -C "$HOME" --exclude='public_html/wp-content/cache' --exclude='*.log' public_html
# rotație: păstrăm 14 zile
find "$DEST" -type f -mtime +14 -delete
echo "$AZI ok $(du -sh "$DEST" | cut -f1)" >> "$DEST/jurnal.txt"

Parola bazei de date nu stă în script; se pune în fișierul ~/.my.cnf (secțiunea [client], cu user și password), cu permisiuni 600, iar mysqldump o citește singur. Programarea din Cron Jobs, zilnic la 3:00, cu ieșirea în jurnal, după ghidul despre programarea sarcinilor cron. Pe un cont cu WP-CLI, exportul bazei se poate face și cu wp db export, cum arătăm în ghidul despre terminalul cPanel și WP-CLI.

Pasul 3: copia în alt loc

O copie pe același server dispare odată cu serverul sau cu contul. Opțiunile, de la simplu la solid:

• Descărcare manuală săptămânală a ultimei arhive, prin File Manager sau SFTP, pe calculatorul dumneavoastră; funcționează, dacă chiar o faceți.
• Trimitere automată prin SFTP sau rsync spre alt server sau spre un spațiu de stocare (unele găzduiri permit rsync spre exterior din cron); scriptul complet cu instantanee este în ghidul despre copiile de siguranță cu cron și rsync.
• Trimitere în cloud (Google Drive, Dropbox, S3) cu rclone, dacă este instalat pe server sau îl puteți rula din dosarul personal; o linie în script după arhivare.
• Pentru site-uri WordPress, un modul care trimite copia în cloud, ca al doilea strat; strategiile sunt în ghidul despre copiile de siguranță automate pentru WordPress.

Pasul 4: rotația și spațiul

Copiile ocupă cotă: un site de 2 GB cu 14 copii zilnice complete înseamnă 28 GB. Soluții: copii zilnice ale bazei de date (mici) și săptămânale ale fișierelor; excluderea cache-ului și a jurnalelor; păstrare de 14 zile pe server și de 90 de zile în cloud; arhive comprimate. Verificați Disk Usage după prima săptămână; un cont care se umple de copii respinge e-mailul și blochează site-ul, exact opusul scopului.

Copiile pentru mai multe site-uri pe același cont

Un cont cu trei-patru domenii suplimentare are dosare separate pentru fiecare (Document Root din Domains) și mai multe baze de date; scriptul se extinde cu o listă de dosare și una de baze, iar arhivele primesc numele site-ului. Rotația se face pe fiecare, ca un site mare să nu șteargă copiile celorlalte prin spațiu. Copia completă a contului (Backup Wizard) le ia pe toate deodată, dar restaurarea ei este a întregului cont; pentru a restaura un singur site, copiile separate din script sunt cele utile. Inventarul site-urilor din cont, cu dosarul și baza fiecăruia, este primul rând al scriptului și se actualizează la fiecare site nou; site-urile uitate din script sunt cele care nu au copie exact când e nevoie.

Copiile și securitatea

Arhivele conțin fișierele de configurare cu parole și exporturile cu datele clienților; le tratați ca date sensibile: dosarul backup cu permisiuni 700, în afara public_html; arhivele criptate dacă părăsesc serverul spre un cloud public (gpg cu o cheie simetrică într-o linie de script, sau opțiunea de criptare a uneltei de sincronizare); accesul la ele doar prin cPanel cu al doilea factor sau prin SFTP cu cheie. O copie furată este o breșă la fel de mare ca site-ul spart, cu obligațiile GDPR aferente, descrise în ghidul despre GDPR și securitatea datelor.

Restaurarea

Baza de date: gunzip -c fisier.sql.gz | mysql cont_baza din terminal, sau din phpMyAdmin pentru fișiere mici; fișierele: dezarhivarea în dosarul personal și copierea peste public_html, cu atenție la fișierele adăugate între timp (nu se șterg singure). Pentru restaurarea completă a contului (e-mail, DNS, setări), copia completă din Backup Wizard, restaurată de furnizor; pașii detaliați, cu capcanele lor, sunt în ghidul despre crearea și restaurarea manuală a copiilor.

Testul lunar

1. Jurnalul scriptului are rânduri pentru fiecare zi; dimensiunea crește odată cu site-ul.
2. Arhiva se poate lista (tar -tzf) și fișierul SQL se poate decomprima (gunzip -t).
3. O dată pe lună, restaurați ultima copie pe un subdomeniu de test, într-o bază separată, și deschideți site-ul; notați durata.
4. Copia din cloud există și are aceeași dimensiune ca cea de pe server.

Fără testul de restaurare, aveți fișiere, nu copii de siguranță; am văzut exporturi trunchiate de luni de zile, descoperite exact când era nevoie de ele.

Ce cereți furnizorului

• Frecvența și perioada de păstrare a copiilor lui, în scris.
• Dacă restaurarea este gratuită și cât durează (ore sau zile).
• Dacă puteți restaura singur, din panou, fișiere sau baze individuale.
• Unde sunt stocate copiile (același server sau alt loc).
• Dacă permite rsync sau rclone din cron spre exterior.

Un furnizor bun răspunde la toate în cinci minute; unul care nu răspunde vă spune că sunteți singur cu copiile dumneavoastră, ceea ce ghidul de față rezolvă oricum.

Când site-ul e WordPress

Scriptul cu cron acoperă fișierele și baza; modulele de copii (UpdraftPlus, BackWPup) adaugă al doilea strat, cu trimitere în cloud și restaurare din interfață, iar WordPress Toolkit, unde există, al treilea. Regula 3-2-1 (trei copii, două suporturi, una în alt loc) se împlinește astfel fără efort suplimentar; particularitățile, inclusiv copia bazei la fiecare oră pentru magazine, sunt în ghidul despre copiile de siguranță automate pentru WordPress.

Greșeli frecvente

• Scriptul rulează, dar eșuează tăcut (parolă schimbată, spațiu plin), iar jurnalul nu e citit de nimeni; puneți o alertă pe e-mail dacă fișierul zilei lipsește.
• Copiile în public_html, descărcabile de oricine.
• Exportul bazei fără --single-transaction pe un magazin activ: fișier inconsistent.
• Rotația care șterge totul când scriptul nu mai creează copii noi (find -mtime +14 pe un dosar în care nu mai intră nimic).
• Nicio copie înainte de actualizări majore, deși scriptul se poate rula manual în zece secunde.

Întrebări frecvente

1. Cât de des? Zilnic baza de date; fișierele zilnic pentru site-uri cu încărcări dese, săptămânal pentru site-uri de prezentare.
2. Copia completă din Backup Wizard poate fi automatizată? Nu din cPanel; doar furnizorul, din WHM. Scriptul cu cron acoperă fișierele și bazele, adică ce se pierde cel mai des.
3. E-mailul intră în copia cu cron? Da, dacă adăugați dosarul mail la arhivă; crește mult dimensiunea, deci separat, săptămânal.
4. Pot restaura fără terminal? Da: fișierele prin File Manager (Extract), baza prin phpMyAdmin (Import), pentru dimensiuni mici.

Copiile sunt ultimul strat de securitate, cel care funcționează când celelalte au picat; celelalte straturi, de la parole la firewall, sunt în ghidul despre securitatea contului cPanel.

Surse

• Documentația cPanel, Backup Wizard: copia completă și parțială, destinațiile și restaurarea.
• Documentația cPanel: uneltele Backup, Cron Jobs și Disk Usage.