Backup automatici su cPanel inviati via FTP: come si fa, e perché non è abbastanza

cPanel è uno dei pannelli di controllo più diffusi per la gestione di hosting e server condivisi, ed è ancora oggi lo standard di fatto su buona parte degli hosting economici. Avendo gestito direttamente ambienti cPanel e WHM, posso dire che come strumento di produttività per sistemisti e sviluppatori fa bene il suo lavoro. Ha però una lacuna che si fa sentire proprio dove conta di più: i backup.

TL;DR

• Limite cPanel: i backup automatici pieni richiedono l'accesso WHM; con il solo account utente si pianificano via cron.
• Come: un cron job che chiama la UAPI Backup/fullbackup_to_remote verso una destinazione remota.
• Destinazione: mai sullo stesso hosting né in chiaro; preferisci SFTP o uno storage esterno cifrato.
• Problema vero: dipendere dal backup dell'hosting condivide il punto di fallimento con ciò che dovrebbe proteggere. Affianca un backup indipendente (es. restic cifrato con retention).
• Regole: 3-2-1, monitoraggio del successo (allarme se il segnale manca), e un backup non testato non è un backup.

La lacuna: backup automatici solo con accesso WHM

Il sistema di backup automatico di cPanel, quello che pianifica copie complete dell'ambiente e le invia a una destinazione remota, è una funzionalità che vive nel pannello di amministrazione WHM, accessibile in modalità root. Chi ha solo un account utente, cioè la stragrande maggioranza di chi sta su un hosting condiviso, da interfaccia grafica può creare un backup completo a mano, ma non trova un'opzione per schedularlo. Il backup, in pratica, esiste solo finché qualcuno si ricorda di generarlo.

È esattamente il tipo di situazione che porta ai disastri: un backup manuale è un backup che, statisticamente, non viene fatto. La persona che doveva ricordarsene è in ferie, il cliente "pensava lo facesse l'hosting", e quando serve davvero la copia più recente risale a sei mesi prima. Un backup che dipende dalla memoria di un essere umano non è una strategia, è una speranza.

La soluzione: pianificare il backup con i cron job di cPanel

La buona notizia è che la limitazione è solo dell'interfaccia grafica, non del sistema sottostante. cPanel espone una API, e mette a disposizione i cron job anche in modalità utente: combinando le due cose si automatizza ciò che il pulsante "Backup" fa a mano. L'approccio storico, che usavo da tempo, era costruire ad hoc le richieste HTTP verso il server cPanel per emulare l'azione manuale e far partire la routine di backup con invio a un server FTP remoto. Funziona, ma oggi c'è un modo più pulito e supportato.

cPanel fornisce un endpoint dedicato nella sua UAPI per generare un backup completo e inviarlo a una destinazione remota. La chiamata si può incapsulare in uno script ed eseguirla con un cron job pianificato dal pannello, ad esempio ogni notte. Lo scheletro dell'operazione, eseguito via curl con l'autenticazione a token, richiama il modulo di backup indicando il tipo di destinazione e i parametri di connessione:

# Cron job notturno: backup completo verso destinazione remota
curl -s -H "Authorization: cpanel UTENTE:TOKEN_API" \
  "https://server:2083/execute/Backup/fullbackup_to_remote?destination=ftp&host=..."

I nomi esatti dei parametri dipendono dalla versione di cPanel e dal tipo di destinazione, e vanno verificati sulla documentazione ufficiale, ma la logica è questa: una chiamata autenticata che innesca un full backup verso un remoto, schedulata da cron. Il riferimento autorevole, da tenere aperto invece di copiare frammenti da un forum, è la documentazione dell'API di cPanel, che elenca i moduli di backup e i parametri supportati dalla tua versione.

Su questo tipo di automazioni, dalla pianificazione dei backup alla loro verifica, lavoro da molti anni con chi gestisce ambienti di produzione e non può permettersi di scoprire un backup mancante nel momento sbagliato: nel mio profilo trovi il metodo con cui imposto le strategie di continuità, partendo sempre dalla domanda che conta più di tutte, cioè non "come faccio il backup" ma "sono sicuro di poterlo ripristinare".

Dove invio il backup, e perché la destinazione conta

L'approccio classico si fermava qui, con l'invio a un server FTP. Ed è proprio sulla destinazione che oggi serve un occhio più critico. L'FTP classico trasmette tutto in chiaro, credenziali comprese: spedire ogni notte una copia completa del proprio sito, con database e dati potenzialmente sensibili, attraverso un canale non cifrato è una cattiva pratica che nel 2018 si dava per normale e che oggi non lo è più.

La regola che applico è preferire sempre una destinazione cifrata: SFTP o SCP, che viaggiano dentro SSH, al posto dell'FTP semplice; e se la destinazione è uno storage a oggetti o un cloud, un trasferimento su TLS con i dati cifrati a riposo. La maggior parte degli hosting moderni supporta SFTP come destinazione di backup remoto anche quando l'interfaccia mette in evidenza solo "FTP": vale la pena cercarlo, perché cambia la postura di sicurezza dell'intera procedura senza costi aggiuntivi.

Il problema più grande: dipendere dal backup dell'hosting

Qui arrivo al punto che conta più di ogni dettaglio tecnico. Un backup di cPanel inviato a un server messo a disposizione dallo stesso hosting, o configurato dentro lo stesso ecosistema, condivide un punto di fallimento con ciò che dovrebbe proteggere. Se l'account viene sospeso, se l'hosting ha un problema serio, se il fornitore chiude o se le credenziali vengono compromesse, rischi di perdere nello stesso colpo sia il sito sia le sue copie. Ho visto aziende scoprire, nel momento del bisogno, che i loro "backup" erano sullo stesso provider che aveva appena disabilitato l'account.

La difesa è un backup indipendente dall'hosting: una copia che vive su un'infrastruttura che controlli tu, separata dal fornitore del sito. Strumenti come rclone o restic permettono di sincronizzare o archiviare i dati verso uno storage esterno, con cifratura, deduplica e versionamento, e si possono far girare da un piccolo server o da un VPS che fa da hub dei backup. La logica di un backup incrementale affidabile, recuperabile e senza impatto sul sistema in esercizio, l'ho descritta per i database in backup incrementale con recovery point senza blocchi, e gli stessi principi valgono per i file e l'intero ambiente.

Tra i due, per i backup veri e propri preferisco restic, perché è nato esattamente per questo scopo e fa tre cose che un semplice mirror non fa: cifra i dati prima che lascino il tuo sistema, li deduplica così che le parti immutate non occupino spazio a ogni esecuzione, e mantiene snapshot che permettono di tornare a un punto preciso nel tempo. Una volta scaricato in locale il full backup di cPanel, o i dati estratti dall'account, lo si archivia in un repository restic su uno storage esterno con un comando semplice:

export RESTIC_PASSWORD="..."   # da un file protetto, mai in chiaro nello script
restic -r sftp:backup@storage:/repo backup /percorso/backup-cpanel
restic -r sftp:backup@storage:/repo forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Il secondo comando applica una politica di retention in un colpo solo: tiene sette snapshot giornalieri, quattro settimanali e sei mensili, ed elimina il resto liberando spazio. È il modo per avere profondità storica senza che i backup crescano all'infinito. Il riferimento per le opzioni è la documentazione ufficiale di restic, che descrive cifratura, repository e politiche di mantenimento.

Il database va trattato a parte

Un punto che il full backup di cPanel risolve ma che chi costruisce una strategia indipendente deve gestire esplicitamente è il database. I file di un sito dinamico sono solo metà della storia: il contenuto vero vive nel database, e un dump del database va preso in modo coerente, idealmente con una copia consistente che non blocchi le scritture in corso. Affiancare un mysqldump schedulato, o uno strumento di backup incrementale del database, al backup dei file è ciò che rende la copia davvero ripristinabile. Recuperare i file senza un dump del database allineato significa ritrovarsi con un sito che parte ma mostra contenuti vecchi o incoerenti.

Quanto costa, davvero

Spesso la resistenza a un backup esterno è il presunto costo, ma è un falso problema. Uno storage a oggetti o una StorageBox di un provider come Hetzner costano pochi euro al mese per centinaia di gigabyte, una frazione del valore dei dati che proteggono. Confrontare quei pochi euro con il costo reale di ricostruire un sito e un database persi, tra ore di lavoro, dati irrecuperabili e clienti scontenti, chiude la discussione. Il backup esterno è una delle spese con il miglior rapporto tra costo e rischio evitato che esistano in un'infrastruttura.

La regola 3-2-1, e perché un backup non testato non è un backup

C'è una regola che riassume tutto questo e che ripeto a ogni cliente: la regola del 3-2-1. Tre copie dei dati, su due supporti diversi, di cui almeno una fuori sede. Un backup di cPanel inviato a un FTP remoto è, da solo, una singola copia su una singola destinazione: meglio di niente, ma lontano da una strategia resiliente. Affiancargli una copia indipendente su storage che controlli tu è ciò che trasforma una procedura in una rete di sicurezza vera.

E poi c'è la verità più scomoda: un backup che non è mai stato ripristinato non è un backup, è un file di cui ti fidi senza prove. Le copie corrotte, i dump incompleti, le esclusioni sbagliate si scoprono solo provando a rimettere in piedi l'ambiente da zero, ed è un test che va fatto periodicamente, non la prima volta durante un'emergenza. Quando il momento arriva, sapere già che il restore funziona fa la differenza tra un'interruzione di un'ora e un disastro di giorni: la procedura per rimettere in piedi un sistema dopo un guasto, dalla diagnosi al recupero, la descrivo in ripristino di un filesystem corrotto su VPS, e averla provata prima è ciò che rende un'emergenza gestibile invece che catastrofica.

Come faccio a sapere se un backup è fallito?

C'è un anello che manca quasi sempre, e la sua assenza vanifica tutto il resto: il monitoraggio. Un backup automatizzato che gira ogni notte dà un falso senso di sicurezza, perché nessuno controlla che sia andato a buon fine finché non serve. E i backup falliscono in silenzio: lo spazio sulla destinazione si esaurisce, una credenziale scade, una modifica al server rompe il cron, e per settimane non viene salvato nulla senza che nessuno se ne accorga. La regola che applico è che ogni backup deve emettere un segnale di successo, non di fallimento: lo script invia una notifica, o fa un ping a un servizio di monitoraggio dead-man's-switch, e se quel segnale non arriva entro la finestra prevista scatta un alert. È controintuitivo ma fondamentale: non aspettare che qualcosa vada storto per ricevere un avviso, ma allarmarsi quando il segnale di "tutto ok" smette di arrivare.

Retention, cifratura e dati personali

Un'ultima dimensione che le aziende sottovalutano è quella normativa. Un backup completo di un sito contiene quasi sempre dati personali: anagrafiche clienti, email, ordini. Questo significa che le copie ricadono sotto le stesse regole di protezione dei dati dell'ambiente di produzione. In pratica: i backup vanno cifrati a riposo, l'accesso va limitato e tracciato, e la retention va definita con criterio, perché conservare backup all'infinito non è prudenza, è un rischio, dato che ogni copia è una superficie in più da proteggere e da cui i dati potrebbero trapelare. Una politica di mantenimento ragionata, come quella che restic applica automaticamente, non serve solo a risparmiare spazio: è anche conformità.

Cosa includere, cosa escludere, e ogni quanto

Un ultimo livello di consapevolezza riguarda il contenuto del backup. Un full backup di cPanel comprende i file della home, i database, gli account email e le configurazioni, ed è completo per definizione, ma proprio per questo può essere pesante e includere cose che non servono, come le cache rigenerabili. Su ambienti grandi conviene distinguere: un backup completo meno frequente, ad esempio settimanale, e backup più leggeri e frequenti dei soli dati che cambiano davvero, come il database e i file caricati dagli utenti. La frequenza giusta non è un valore assoluto: si decide in base a quanto lavoro sei disposto a perdere nel caso peggiore, ovvero al tuo obiettivo di punto di ripristino. Un negozio online che riceve ordini ogni ora non può permettersi di perderne un giorno intero e avrà bisogno di backup frequenti del database; un sito vetrina che cambia una volta al mese sta benissimo con una copia settimanale. Adattare la cadenza al ritmo reale con cui i dati cambiano, invece di applicare uno schema uguale per tutti, è ciò che distingue una strategia pensata da una procedura copiata. Per chi gestisce un VPS o un account hosting senza un team alle spalle, avere tutto questo scritto in una procedura da seguire sotto stress è ciò che evita gli errori: ne ho preparata una pensata per i momenti critici in checklist di emergenza per VPS Debian e Ubuntu non gestiti.

Automatizzare il backup di cPanel verso un remoto, quindi, è il primo passo giusto e va fatto, ma è solo il primo: la differenza tra un'azienda che dorme tranquilla e una che rischia sta nell'avere una copia indipendente, cifrata, versionata e soprattutto testata. Se vuoi impostare una strategia di backup che regga davvero a un guasto del tuo hosting, e non solo a una cancellazione accidentale di un file, scrivimi dal modulo di contatto: partiamo da dove sono oggi le tue copie e da cosa succederebbe, concretamente, se domani il tuo account venisse disabilitato.