Backup di hosting e VPS su NAS Synology con DSM 7

Articolo aggiornato a ottobre 2026: procedura rivista per DSM 7.2.

Il backup che offre il provider di hosting è comodo, ma ha un difetto di fondo: sta nello stesso posto dei dati. Se l’account viene sospeso, compromesso o il provider ha un problema serio, si perdono sito e backup insieme. Per questo da anni tengo una copia di siti e VPS anche sul NAS Synology, in casa o in ufficio, e da lì la porto anche fuori sede.

Rispetto alla prima versione di questa guida ho abbandonato l’FTP: le credenziali viaggiano in chiaro, ed è il primo protocollo che conviene disattivare su un hosting. Oggi uso SSH con autenticazione a chiave, che quasi tutti gli hosting (cPanel compreso) e ovviamente qualsiasi VPS mettono a disposizione.

Cosa serve

un NAS Synology con DSM 7.x e una cartella condivisa dedicata, ad esempio backup;
accesso SSH all’hosting o al VPS (su cPanel si abilita da “Accesso SSH” / “SSH Access”);
SSH attivo sul NAS: Pannello di controllo → Terminale e SNMP.

1. Chiave SSH dal NAS verso il server

Collegatevi in SSH al NAS con un utente amministratore e generate una chiave dedicata, salvandola in una cartella persistente (non nella home di root, che alcuni aggiornamenti di DSM possono azzerare):

sudo mkdir -p /volume1/backup/.ssh
sudo ssh-keygen -t ed25519 -f /volume1/backup/.ssh/id_backup -N "" -C "nas-backup"
sudo cat /volume1/backup/.ssh/id_backup.pub

Copiate la chiave pubblica nel file ~/.ssh/authorized_keys dell’utente sul server (su cPanel: Accesso SSH → Gestisci chiavi SSH → Importa, poi Autorizza). Fate una prova di connessione per accettare la fingerprint del server:

sudo ssh -i /volume1/backup/.ssh/id_backup -p 22 [email protected] "echo ok"

2. Credenziali del database fuori dallo script

Nella vecchia versione la password del database stava scritta nello script: meglio evitarlo. Sul server create il file ~/.my.cnf, leggibile solo dal vostro utente (chmod 600 ~/.my.cnf):

[mysqldump]
user=utente_db
password=PasswordDelDatabase

3. Lo script di backup

Salvate questo script sul NAS, ad esempio in /volume1/backup/scripts/backup-sito.sh, adattando le variabili iniziali:

#!/bin/bash
HOST="[email protected]"
PORT=22
KEY="/volume1/backup/.ssh/id_backup"
REMOTE_DIR="public_html/"
DB="nome_database"
DEST="/volume1/backup/example.com"
KEEP_DAYS=14
DATA=$(date +%Y-%m-%d)

mkdir -p "$DEST/files" "$DEST/db"

# File del sito: rsync copia solo le differenze
rsync -az --delete -e "ssh -i $KEY -p $PORT" "$HOST:$REMOTE_DIR" "$DEST/files/"

# Database: dump compresso, una copia al giorno
ssh -i "$KEY" -p "$PORT" "$HOST" "mysqldump --single-transaction --routines $DB" | gzip > "$DEST/db/$DB-$DATA.sql.gz"

# Rotazione: elimina i dump più vecchi di KEEP_DAYS giorni
find "$DEST/db" -name "*.sql.gz" -mtime +$KEEP_DAYS -delete

La cartella files è uno specchio del sito (con --delete i file rimossi sul server vengono rimossi anche qui), mentre i dump del database restano uno per giorno. Lo storico dei file lo affidiamo agli snapshot, come vediamo tra poco. Su un VPS potete includere nello stesso modo altre cartelle, ad esempio /etc o le configurazioni del web server, aggiungendo altre righe rsync.

4. Pianificazione

In DSM aprite Pannello di controllo → Pianificazione attività → Crea → Attività pianificata → Script definito dall’utente. Utente root, esecuzione giornaliera nelle ore notturne, e come comando:

bash /volume1/backup/scripts/backup-sito.sh

Nelle impostazioni dell’attività attivate l’invio dell’output via e-mail “solo in caso di errore”: così saprete subito se qualcosa si rompe, senza ricevere una mail ogni notte.

5. Storico e copia fuori sede

Snapshot Replication: se la cartella è su un volume Btrfs, attivate gli snapshot giornalieri sulla cartella backup. Avrete uno storico anche dei file del sito, senza occupare spazio inutile.
Hyper Backup: copiate la cartella backup su un secondo NAS, su un disco USB o su un cloud (Synology C2, S3, Backblaze B2). La regola del 3-2-1 vale anche qui.

Per i VPS c’è anche un’alternativa senza script: Active Backup for Business può fare il backup di un server Linux via rsync (sezione File Server) con pianificazione e versioni gestite dall’interfaccia. Per il database però resta necessario un dump, quindi lo script del punto 3 torna comunque utile.

Se il problema persiste

Se l’attività fallisce ma lanciata a mano funziona, nove volte su dieci è la fingerprint del server non ancora accettata dall’utente root: rifate la prova di connessione del punto 1 con sudo. Se invece il dump è vuoto, controllate che ~/.my.cnf abbia i permessi giusti e che il nome del database sia corretto.

Domande o configurazioni particolari? Lasciate un commento.