--- title: "Backup VPS su Hetzner, OVH, Contabo, Digital Ocean e Aruba: strategie avanzate per aziende" description: "Strategia di backup 3-2-1-1-0 per VPS unmanaged: BorgBackup append-only, encryption AES-256, repo immutabile su Hetzner Storage Box, retention GFS e restore verificato." canonical: "https://www.mauriziofonte.it/blog/post/backup-vps-unmanaged-strategie-avanzate.html" author: "Maurizio Fonte" date: "2025-07-09T08:03:46+02:00" modified: "2026-06-25T13:18:48+02:00" section: "Business Continuity" tags: ["Business Continuity", "VPS & Hosting"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Business Continuity](https://www.mauriziofonte.it/blog/cat/business_continuity.html) [VPS & Hosting](https://www.mauriziofonte.it/blog/cat/vps.html) # [Backup VPS su Hetzner, OVH, Contabo, Digital Ocean e Aruba: strategie avanzate per aziende](https://www.mauriziofonte.it/blog/post/backup-vps-unmanaged-strategie-avanzate.html) Mercoledì 9 Luglio 2025, alle 08:03 ![Backup VPS su Hetzner, OVH, Contabo, Digital Ocean e Aruba: strategie avanzate per aziende](https://www.mauriziofonte.it/image/002040200-backup-vps-unmanaged-strategie-avanzate.jpg) Qualche mese fa mi ha contattato il responsabile IT di una PMI manifatturiera del Nord-Est dopo che un ransomware aveva cifrato l'intero filesystem di un VPS Contabo da 8 vCPU, 24 GB di RAM e SSD. Sul server girava il gestionale che coordinava la produzione di tre linee di assemblaggio, con un volume nell'ordine del centinaio di ordini al giorno: ogni ora di fermo si traduceva in ritardi sulle consegne e penali contrattuali nell'ordine delle migliaia di euro. Il backup esistente era un `mysqldump` schedulato ogni notte alle 02:00 e salvato in `/var/backups/`, **sullo stesso disco del server cifrato**. Inutile. Il secondo "backup" era una copia manuale che il responsabile scaricava via SFTP sul proprio portatile, quando se ne ricordava: l'ultimo download risaliva a oltre una settimana prima. Una settimana di ordini, fatture, note di produzione e modifiche ai listini, evaporata. Quel cliente ha ricostruito a mano i giorni mancanti incrociando email e copie cartacee, con un costo complessivo dell'incidente, tra fermo, lavoro di ricostruzione e penali, di gran lunga superiore a quello di un backup offsite configurato come si deve. Questo articolo è la strategia che ho implementato dopo quell'incidente e che oggi installo come standard su **ogni VPS unmanaged che gestisco**, su Hetzner, OVH, Contabo, Digital Ocean o Aruba. Non è teoria: è il protocollo operativo, con gli script reali, che separa un backup vero da una speranza schedulata. > Stai cercando un **Consulente Informatico** esperto per mettere in sicurezza i backup della tua infrastruttura prima che serva il ripristino? Nel mio [profilo professionale](https://www.mauriziofonte.it/pages/about) trovi l'esperienza concreta su VPS e server dedicati Hetzner, OVH, Contabo, Digital Ocean e Aruba, hardening Linux, disaster recovery e recupero di infrastrutture compromesse. ## Perché la regola 3-2-1 non basta più e cosa significa 3-2-1-1-0? La regola **3-2-1** (tre copie dei dati, su due supporti diversi, di cui una offsite) è stata per vent'anni il riferimento per la strategia di backup. Oggi non basta più, e la ragione è una sola: **il ransomware moderno caccia attivamente i backup**. Prima di cifrare, l'attaccante enumera e distrugge tutto ciò che il server compromesso può raggiungere con le proprie credenziali: share di rete montate, repository remoti accessibili con la stessa chiave SSH, bucket S3 senza object lock, snapshot del pannello provider se l'account è lo stesso. Se il tuo backup è raggiungibile e cancellabile dal server di produzione, non è un backup: è un secondo bersaglio che hai gentilmente etichettato. La risposta è il modello **3-2-1-1-0**, ormai adottato come standard di settore e formalizzato anche da vendor di backup come [Barracuda Networks](https://blog.barracuda.com/2026/03/31/world-backup-day--is-the-3-2-1-backup-rule-still-relevant-): tre copie, due supporti, una offsite, **una immutabile** (non cancellabile nemmeno con i privilegi di root del server di produzione) e **zero errori**, dove lo zero non è un auspicio ma il risultato di test di ripristino regolari. I due elementi nuovi sono il cuore della difesa anti-ransomware. L'immutabilità garantisce che, anche con il server compromesso al 100% (root, credenziali rubate, tutto), almeno una copia sopravviva. Lo zero garantisce che quella copia sia davvero ripristinabile, e non un archivio corrotto scoperto tale solo nel momento peggiore. > Un backup mai testato non è un backup, è una scommessa. La regola 3-2-1-1-0 esiste perché negli incidenti reali falliscono quasi sempre gli ultimi due numeri: l'immutabilità (il ransomware raggiunge i backup) e lo zero (il restore non era mai stato provato). ## Lo strumento di base: BorgBackup con repository cifrato Per i backup dei VPS che gestisco uso come standard [BorgBackup](https://www.borgbackup.org/), per tre ragioni concrete. La prima è la **deduplicazione a livello di blocco**: Borg spezza i file in chunk e archivia ogni chunk una sola volta, così la dimensione effettiva del repository resta vicina al volume dei dati *unici* anche tenendo decine di snapshot storici. La seconda è l'**encryption AES-256 lato client**: i dati vengono cifrati sul server prima di partire, lo storage di destinazione riceve solo blocchi cifrati e il provider non può leggerli. La terza è il supporto nativo alla modalità *append-only*, su cui costruisco l'immutabilità. L'inizializzazione di un repository cifrato è diretta: ```bash # Installazione (Debian/Ubuntu) apt install -y borgbackup # Inizializzazione con encryption: la chiave vive nel repo, protetta da passphrase borg init --encryption=repokey-blake2 ssh://backup@STORAGE_HOST/./borg-repo # CRITICO: esportare la chiave del repository in un luogo sicuro OFFLINE. # Senza chiave + passphrase, i backup cifrati sono irrecuperabili. Per sempre. borg key export ssh://backup@STORAGE_HOST/./borg-repo /root/borg-key-export.txt ``` La scelta di `repokey-blake2` rispetto al classico `repokey` non è cosmetica: l'algoritmo *BLAKE2* è più veloce di SHA-256 nell'hashing dei chunk e offre le stesse garanzie di integrità, un vantaggio misurabile su un VPS con CPU contesa. Ma il punto da fissare con un chiodo è un altro: **la chiave del repository va custodita offline, separata dal server**. Un backup cifrato la cui unica copia della chiave vive sul server cifrato dal ransomware ha lo stesso valore di nessun backup. Questa è la prima cosa che verifico quando faccio l'audit di un'infrastruttura altrui, ed è quella che manca più spesso. ## L'append-only mode: cosa protegge davvero (e cosa no) Qui c'è una sottigliezza che la maggior parte dei tutorial sbaglia, e che fa la differenza tra credere di essere protetti ed esserlo. Su un repository servito via SSH si forza il comando `borg serve` con il flag `--append-only` direttamente nel file `authorized_keys` dell'utente di backup, lato storage: ```text command="borg serve --restrict-to-path /home/backup/borg-repo --append-only",restrict ssh-ed25519 AAAAC3Nza...chiave_pubblica_del_vps... ``` Il flag `--append-only` istruisce `borg serve` ad accettare nuovi archivi e nuovi chunk, ma **non blocca del tutto le operazioni di cancellazione**. Come chiarisce la [documentazione ufficiale di Borg](https://borgbackup.readthedocs.io/en/stable/usage/notes.html), in append-only mode un client può ancora eseguire `borg delete` o `borg prune`: la differenza è che queste operazioni si limitano a *marcare* i dati come eliminati in una nuova transazione, senza rimuoverli fisicamente, perché la compattazione (`borg compact`) è vietata. Ogni transazione viene registrata con timestamp UTC nel file `transactions`. Cosa significa in pratica? Significa che l'append-only di Borg garantisce **reversibilità, non prevenzione assoluta**. Se un attaccante ottiene root sul VPS, trova la chiave SSH e lancia un `borg delete` malevolo, i dati *non* sono persi: l'amministratore dello storage può leggere il log delle transazioni, identificare il momento del compromesso, rimuovere i segment file creati dopo l'attacco e ripristinare lo stato precedente, poi rieseguire `borg check --verify-data` e `borg compact`. È un meccanismo solido, ma richiede un attore separato (lo storage, con credenziali diverse) che faccia da custode. > Append-only di Borg non vuol dire "il ransomware non può toccare i backup". Vuol dire "il ransomware non può distruggerli in modo irreversibile, e un secondo attore con credenziali separate può sempre tornare indietro". È una garanzia di reversibilità, e va progettata di conseguenza. Da qui derivano due decisioni di design che applico sempre. Primo: **il pruning non lo fa mai il VPS**. Il server di produzione ha una chiave append-only e può solo aggiungere; la rotazione della retention (l'unica operazione che cancella per davvero) gira lato storage, con credenziali che il VPS non possiede. Secondo: per i clienti dove il rischio lo giustifica, sotto Borg metto un secondo strato di immutabilità a livello di storage (object lock in modalità *compliance* su backend S3-compatibili, dove nemmeno l'amministratore dello storage può cancellare prima della scadenza della retention). Lo stesso principio vale se si preferisce [restic](https://restic.readthedocs.io/) come tool: il suo `rest-server` ha una modalità append-only equivalente, con i medesimi limiti, e l'object lock S3 resta la cintura di sicurezza più robusta. ## Quale storage di destinazione, provider per provider L'append-only e l'immutabilità hanno senso solo se la destinazione è **fisicamente separata** dal VPS di produzione, con credenziali distinte. La scelta del target dipende dal provider su cui gira il server, e ogni provider ha le sue specificità. Come destinazione standard per i clienti uso la **Hetzner Storage Box**: storage dedicato al backup con accesso SSH/SFTP/SCP/rsync nativo e supporto diretto a BorgBackup e restic, snapshot lato server inclusi e fino a 100 sub-account per isolare le chiavi. È perfetta come repository Borg append-only via SSH, e la uso anche come target per VPS che girano *altrove*: la latenza tra datacenter europei è trascurabile per un backup notturno. Per chi vuole il VPS di produzione su cloud UE self-managed con buon rapporto prezzo/prestazioni e datacenter in Germania o Finlandia, Hetzner resta il riferimento del mercato europeo (listino EUR sulle region eu-central, con la classe entry shared intorno ai 3-4 euro/mese IVA esclusa, rilevazione 2026-06-11 su hetzner.com/cloud). Sugli altri provider la logica non cambia, cambiano gli strumenti: - **OVHcloud** include su alcuni piani uno snapshot automatico del VPS, ma è tutto-o-niente e a grana grossa: utile come complemento, inadeguato come backup granulare. Per backup veri si appoggia uno storage esterno, ad esempio l'Object Storage S3-compatibile, sincronizzato con `rclone`. OVH è anche l'unico tra questi con una region 3-AZ a Milano e certificazioni di sovranità (SecNumCloud, qualifica ACN per la PA italiana). - **Contabo** ha pricing aggressivo sul VPS ma nessuna soluzione di backup integrata di livello: il mio default è puntare gli script Borg verso una Storage Box esterna. Da tenere a mente, separato dai fatti tecnici: Contabo ha una reputazione consolidata di oversubscription sui piani shared, quindi sul VPS di produzione conviene non tirare troppo. - **Digital Ocean** offre Spaces (object storage S3-compatibile) come target per i backup Borg via `rclone`, più i backup automatici dei Droplet a sovrapprezzo. Attenzione però: è una società USA, quindi piena esposizione al CLOUD Act anche per i Droplet in region UE, un fattore da pesare se i dati di backup sono sensibili. - **Aruba Cloud** ha datacenter di proprietà in Italia e object storage S3-compatibile, scelta naturale quando il vincolo è la residenza del dato sul territorio nazionale. > La regola che non negozio mai: backup e server di produzione non condividono né infrastruttura né credenziali né account. Se un singolo compromesso può raggiungere entrambi, non hai un backup, hai due copie dello stesso bersaglio. Per le PMI italiane che non vogliono gestire in proprio nemmeno lo strato di backup e cercano un'infrastruttura gestita con il dato che non lascia l'Italia, la prima scelta che indico è [RHX](https://www.rhx.it/servizi/virtual-server): private cloud con gestione sistemistica inclusa, backup automatizzati e ripristino tra i servizi managed, datacenter a Milano (adiacente al MiX) e Padova. Il posizionamento è private cloud gestito, non VPS low-cost: il confronto si fa sul TCO gestito, non sul prezzo nudo per core. ## Lo script di backup che installo in produzione Lo script che metto su ogni VPS gestito esegue in sequenza quattro operazioni: dump del database, backup del filesystem con Borg, log strutturato e verifica periodica dell'integrità. Lo lancio come **systemd timer**, non come cron: ottengo logging centralizzato in journald, gestione pulita dei fallimenti con `OnFailure=` e niente sorprese sul `PATH` o sull'ambiente. ```bash #!/usr/bin/env bash set -euo pipefail # Configurazione (in produzione: passphrase e password DB da file con chmod 600) export BORG_REPO="ssh://backup@STORAGE_HOST/./borg-repo" export BORG_PASSPHRASE="$(cat /root/.borg-passphrase)" readonly LOG="/var/log/borg-backup.log" readonly ARCHIVE="{hostname}-{now:%Y-%m-%d_%H%M}" log() { echo "$(date '+%Y-%m-%d %H:%M:%S') $1" | tee -a "$LOG"; } # 1. Dump MySQL consistente, senza lock sulle tabelle InnoDB log "START: MySQL dump" mysqldump --defaults-extra-file=/root/.my.cnf \ --single-transaction --quick --routines --triggers --events \ --all-databases | zstd -6 > /tmp/mysql-dump.sql.zst log "DONE: MySQL dump ($(du -sh /tmp/mysql-dump.sql.zst | cut -f1))" # 2. Backup BorgBackup del filesystem + dump log "START: Borg create" borg create --compression zstd,6 --stats --one-file-system \ "::${ARCHIVE}" \ /etc /var/www /home /tmp/mysql-dump.sql.zst \ --exclude '/var/www/*/vendor' \ --exclude '/var/www/*/node_modules' \ --exclude '/var/www/*/storage/logs/*.log' \ --exclude '*.cache' 2>> "$LOG" log "DONE: Borg create" # 3. Pulizia del dump temporaneo rm -f /tmp/mysql-dump.sql.zst # 4. Verifica integrita settimanale (sabato), a basso costo sul repo if [ "$(date +%u)" -eq 6 ]; then log "START: Borg check" borg check "${BORG_REPO}" 2>> "$LOG" log "DONE: Borg check" fi ``` Tre dettagli che fanno la differenza e che vedo saltati di continuo. Le **esclusioni** non sono pignoleria: `vendor/` e `node_modules/` si rigenerano con `composer install` e `npm ci`, includerli spreca spazio, banda e tempo di ripristino; i log applicativi in `storage/logs/` non servono a ripristinare nulla. La **compressione `zstd,6`** offre un rapporto compressione/velocità eccellente, tipicamente intorno al 50% di riduzione con overhead CPU contenuto. E il `--single-transaction` del mysqldump è **non negoziabile** su InnoDB: garantisce un dump consistente senza bloccare le scritture, evitando lo scenario classico in cui una tabella ordini referenzia righe di una tabella prodotti dumpata in un istante diverso. Aggiungo `--quick` per non bufferizzare l'intero result set in RAM su database grandi. ## La retention policy: il modello GFS senza sprechi La retention segue il modello **GFS (Grandfather-Father-Son)**, che bilancia granularità di ripristino e costo dello storage tenendo molti backup recenti e via via meno backup man mano che si va indietro nel tempo. La configurazione che uso come default copre tre orizzonti diversi: - **7 backup giornalieri**, per recuperare da un errore scoperto in fretta (una migration sbagliata, una cancellazione accidentale di ieri). - **4 backup settimanali**, per i problemi che emergono dopo qualche giorno. - **6 backup mensili**, per audit, compliance e per la *corruzione lenta*, quella che si insinua e si nota solo settimane dopo. Su Borg la rotazione si esprime così, e gira **lato storage**, mai dal VPS: ```bash # Pruning: eseguito SOLO dallo storage di backup, con credenziali diverse dal VPS borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 \ --stats "${BORG_REPO}" 2>> "$LOG" # Compattazione: libera davvero lo spazio dopo il pruning borg compact "${BORG_REPO}" 2>> "$LOG" ``` Il `borg compact` dopo il prune è il passaggio che quasi tutti dimenticano: **il pruning marca gli archivi come eliminati, ma lo spazio si libera solo con la compattazione**. Senza, il repository continua a crescere all'infinito nonostante il prune. Grazie alla deduplicazione, l'occupazione effettiva di una retention completa resta vicina al volume dei dati unici più i delta: su un'applicazione tipica, dove tra un giorno e l'altro cambia una frazione minima dei file, decine di archivi storici costano una manciata di gigabyte oltre alla baseline. È il motivo per cui tenere mesi di storia su una Storage Box ha un costo marginale che vale ogni centesimo rispetto al rischio che copre. ## Il backup del database: mysqldump non è l'unica strada Per database MySQL o MariaDB fino a una decina di gigabyte, `mysqldump --single-transaction` resta lo strumento più pratico: produce un file SQL portabile, leggibile e verificabile a mano. Se vuoi i dettagli sul perché `--single-transaction` è la chiave per dumpare senza lock un database in produzione, l'ho trattato a fondo nell'articolo su [mysqldump senza lock su server di produzione](https://www.mauriziofonte.it/blog/post/mysqldump-senza-lock-su-server-produzione.html). Oltre i 20-30 GB, però, il dump logico diventa un collo di bottiglia: un mysqldump da 40 GB può richiedere decine di minuti, durante i quali la transazione lunga mantiene una vista consistente che pesa sulle performance e gonfia gli undo log. Per quei casi uso **Percona XtraBackup**, che esegue un backup fisico *hot* copiando i file InnoDB a livello di pagina mentre il database continua a scrivere, applicando i redo log alla fine per garantire la consistenza. Il ripristino è molto più veloce di un import SQL, perché non deve ricostruire gli indici: si copiano i file e si avvia il server. Lo svantaggio è la minore portabilità tra versioni diverse di MySQL, ma per il disaster recovery sullo stesso stack è la soluzione più efficiente. Un errore che vedo di continuo, indipendente dal tool: **il dump viene schedulato e nessuno controlla mai se è andato a buon fine**. Il passo in più che implemento sempre è un check sulla dimensione del dump: se l'archivio è significativamente più piccolo della media storica (diciamo una variazione oltre il 20%), qualcosa non torna e il backup va marcato come sospetto, non archiviato in silenzio. ## Il test di ripristino automatizzato: la parte che tutti saltano Lo ripeto perché è il numero `0` della regola e il punto dove le strategie altrui crollano: **un backup che non è mai stato ripristinato non è un backup, è una speranza**. In più di un'occasione ho fatto l'audit di infrastrutture dove i backup giravano da anni, regolarmente, e si è scoperto solo durante un'emergenza che erano corrotti, incompleti o cifrati con una chiave persa. La causa è sempre la stessa: nessuno aveva mai verificato che il ripristino funzionasse davvero. Il test che configuro su ogni VPS estrae l'ultimo archivio in dry-run e verifica che non ci siano errori di integrità, ed è abbastanza leggero da girare ogni notte: ```bash #!/usr/bin/env bash set -euo pipefail export BORG_REPO="ssh://backup@STORAGE_HOST/./borg-repo" export BORG_PASSPHRASE="$(cat /root/.borg-passphrase)" # Ultimo archivio, verifica integrita senza scrivere su disco LAST="$(borg list --last 1 --format '{archive}' "${BORG_REPO}")" if borg extract --dry-run "${BORG_REPO}::${LAST}" 2>/tmp/restore-test.log; then echo "RESTORE TEST OK: ${LAST}" | mail -s "Backup OK" admin@esempio.it else echo "RESTORE TEST FAILED: ${LAST}" | mail -s "BACKUP ALERT" admin@esempio.it fi ``` Il `--dry-run` di `borg extract` legge e decifra l'intero archivio verificandone l'integrità senza scrivere nulla su disco, quindi è veloce e senza impatto sullo spazio. **Ma il dry-run non basta da solo.** Una volta al mese eseguo un *restore reale completo*: estraggo l'archivio in una directory pulita, importo il dump in un'istanza MySQL temporanea e controllo che l'applicazione si avvii e che le tabelle critiche contengano dati coerenti. È l'unico modo per validare l'intera catena, dal chunk cifrato all'applicazione in piedi, e per misurare un **RTO realistico**: quanto tempo serve davvero a tornare operativi. Un RTO scritto in un documento ma mai cronometrato è un numero di fantasia. Se quello che stai affrontando non è la prevenzione ma il dopo (un filesystem già corrotto da ripristinare), ho documentato la procedura passo-passo nell'articolo sul [ripristino di un filesystem corrotto su VPS Debian e Ubuntu](https://www.mauriziofonte.it/blog/post/ripristino-filesystem-corrotto-vps-debian-ubuntu.html). E se vuoi inquadrare il backup nel disegno più ampio della continuità operativa, è il primo pilastro del [piano di disaster recovery per applicazioni PHP](https://www.mauriziofonte.it/blog/post/piano-disaster-recovery-php-continuita-operativa-pmi.html): backup, RPO/RTO, runbook e ruoli sono pezzi dello stesso sistema, non isole. Il backup non è un task tecnico da configurare una volta e dimenticare: è un'assicurazione sulla sopravvivenza del business digitale, e come ogni assicurazione vale solo se l'hai testata prima del sinistro. La PMI manifatturiera del Nord-Est ha pagato a caro prezzo la lezione che uno script schedulato non è una strategia, e che un backup sullo stesso disco del server è un placebo. Una destinazione offsite, immutabile, con encryption lato client e un restore verificato ogni settimana costa una frazione minima di una singola giornata di fermo. Se vuoi impostare una strategia di backup seria sulla tua infrastruttura, o semplicemente verificare che quella che hai oggi sopravviva davvero a un ransomware e a un test di ripristino reale, [contattami per una consulenza diretta](https://www.mauriziofonte.it/pages/contattami): tra la diagnosi e la prima contromisura, di solito, passano ore e non settimane. Dall'articolo al lavoro vero Se questo server lo devi tenere in piedi tu Major upgrade senza fermo, hardening, monitoraggio, backup di cui viene provato il ripristino. [Vedi come lavoro sui server](https://www.mauriziofonte.it/servizi/consulenza-it-devops.html) Ultima modifica: Giovedì 25 Giugno 2026, alle 13:18 [« Articolo precedenteServer Debian e Ubuntu in emergenza: checklist operativa rapida per VPS9 Luglio 2025](https://www.mauriziofonte.it/blog/post/checklist-emergenza-debian-ubuntu-vps-unmanaged.html)[Articolo successivo »Ottimizzare cron job su VPS unmanaged: tecniche avanzate per prevenire colli di bottiglia e downtime10 Luglio 2025](https://www.mauriziofonte.it/blog/post/ottimizzare-cron-job-vps-unmanaged.html) ### Articoli correlati a Backup VPS su Hetzner, OVH, Contabo, Digital Ocean e Aruba: strategie avanzate per aziende - [Backup del filesystem e dei database di server web](https://www.mauriziofonte.it/blog/post/backup_del_filesystem_e_dei_database_di_server_web.html) Il backup di un server web non è uno script da lanciare e dimenticare: è una strategia che mette insieme due cose diverse, i file e i database, · 18 Febbraio 2026 ![Backup del filesystem e dei database di server web](https://www.mauriziofonte.it/image/000070070-backup_del_filesystem_e_dei_database_di_server_web.jpg) - [Backup di Mysql con mysqldump senza lock sulle tabelle](https://www.mauriziofonte.it/blog/post/mysqldump-senza-lock-su-server-produzione.html) Lanciare mysqldump su un database in produzione senza fermare i servizi è possibile, ma il modo in cui si fa cambia tutto. La ricetta che gira · 19 Marzo 2026 ![Backup di Mysql con mysqldump senza lock sulle tabelle](https://www.mauriziofonte.it/image/000300070-mysqldump-senza-lock-su-server-produzione.jpg) - [Piano di Disaster Recovery per applicazioni PHP: guida pratica per la continuità operativa della tua PMI](https://www.mauriziofonte.it/blog/post/piano-disaster-recovery-php-continuita-operativa-pmi.html) Un piano di disaster recovery non è un backup: è la definizione di RTO e RPO realistici, l'analisi del rischio, i runbook di ripristino, le procedure · 8 Settembre 2025 ![Piano di Disaster Recovery per applicazioni PHP: guida pratica per la continuità operativa della tua PMI](https://www.mauriziofonte.it/image/002260070-piano-disaster-recovery-php-continuita-operativa-pmi.jpg) - [Disaster Recovery Plan per PMI: da backup non testati a RPO/RTO verificabili con la regola 3-2-1-1-0](https://www.mauriziofonte.it/blog/post/disaster-recovery-plan-importanza-azienda.html) La National Cybersecurity Alliance stima che il 60 delle piccole imprese che subisce una perdita dati significativa chiude entro 6 mesi. Un Disaster · 29 Mag 2025 ![Disaster Recovery Plan per PMI: da backup non testati a RPO/RTO verificabili con la regola 3-2-1-1-0](https://www.mauriziofonte.it/image/001490070-disaster-recovery-plan-importanza-azienda.jpg) - [Backup automatici su cPanel inviati via FTP: come si fa, e perché non è abbastanza](https://www.mauriziofonte.it/blog/post/backup-automatico-cpanel-ftp.html) cPanel rende facile creare un backup completo a mano, ma in modalità utente, senza accesso WHM, non offre un modo immediato per automatizzarlo. · 3 Febbraio 2026 ![Backup automatici su cPanel inviati via FTP: come si fa, e perché non è abbastanza](https://www.mauriziofonte.it/image/000450070-backup-automatico-cpanel-ftp.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Backup VPS su Hetzner, OVH, Contabo, Digital Ocean e Aruba: strategie avanzate per aziende", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/backup-vps-unmanaged-strategie-avanzate.html Pubblicato: 2025-07-09 · Aggiornato: 2026-06-25. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.