Backup automatico server con rsync e cron

rsync e cron sono la coppia classica per automatizzare i backup su server Linux. Sono affidabili, gratuiti, presenti in qualsiasi distribuzione e supportano trasferimenti incrementali con conservazione delle versioni tramite hard link. In questa guida vedremo come costruire un sistema di backup robusto, off-site e ripristinabile.

Perché rsync e ancora attuale

Nonostante esistano tool moderni come restic, BorgBackup e Duplicity, rsync resta insostituibile per la sua semplicità, trasparenza e velocità su LAN o link veloci. Trasferisce solo i delta dei file, preserva permessi e attributi estesi e si integra perfettamente con SSH per cifrare il traffico. Aggiungendo l'opzione --link-dest ottieni snapshot incrementali a basso costo di spazio.

Struttura della destinazione

Su un server di backup separato (off-site o secondo datacenter) crea una directory per host con sottocartelle per data: ad esempio /srv/backup/web01/2026-06-29/. Ogni run nuova punta a --link-dest all'ultima riuscita, così i file invariati vengono linkati duramente e occupano spazio una sola volta. La rotazione si fa cancellando le directory più vecchie con find e mtime.

Procedura passo-passo

1. Sul server di backup crea un'utente backup con shell limitata e quota disco.
2. Genera una chiave SSH dedicata sul server di origine e copiala sull'host di backup.
3. Limita la chiave a un comando preciso con command="rsync --server ..." in authorized_keys.
4. Scrivi uno script che esegue: rsync con --link-dest, log su file, alert via email in caso di errore.
5. Pianifica con cron, esempio: 15 2 * * * /usr/local/sbin/backup.sh
6. Imposta una rotazione mantenendo 7 giornalieri, 4 settimanali e 6 mensili.
7. Testa periodicamente il restore di un file casuale: un backup mai testato non e un backup.
8. Aggiungi un secondo livello off-site su cloud (B2, S3 compatibile) con rclone.

Esempio di script minimale

Lo script tipico definisce SRC, DEST, LAST e invoca rsync -aHAX --delete --link-dest="$LAST" "$SRC/" "$DEST/". Aggiunge logging in /var/log/backup.log e notifica con sendmail se il codice di uscita e diverso da zero.

Errori comuni e come risolverli

• Backup sullo stesso disco: inutile in caso di guasto hardware, usa sempre un'altro host.
• Dimenticare --delete: senza, i file cancellati restano per sempre; con --delete senza versioning rischi di perderli; soluzione: snapshot con link-dest.
• Cron senza output redirect: definisci MAILTO e gestisci esplicitamente stdout/stderr.
• Backup non testati: una volta al mese ripristina su un'host di test.

Domande frequenti

D: Quanto spazio servirebbe con --link-dest?
R: Circa una copia piena più il delta giornaliero: per filesystem da 100 GB con basso turnover puoi conservare 30 snapshot in meno di 150 GB.

D: rsync sostituisce restic o Borg?
R: No: questi ultimi offrono deduplica e cifratura nativa, ma rsync e più trasparente e ispezionabile.

D: Posso usare cron.daily invece di crontab?
R: Si, e una soluzione pulita: metti lo script in /etc/cron.daily/ e ricorda i permessi 755.

Approfondimento tecnico: hard link e snapshot incrementali

La modalita --link-dest di rsync sfrutta gli hard link del filesystem: i file invariati nel nuovo snapshot puntano fisicamente agli stessi inode del precedente. Lo spazio occupato cresce solo per i file cambiati, mentre ogni directory di backup appare come una copia completa navigabile. E un meccanismo elegante che ricalca a livello base concetti di filesystem moderni come btrfs e ZFS snapshots.

Per filesystem nativi a snapshot (ZFS, btrfs) si puo affiancare rsync con zfs snapshot + zfs send | zfs receive: il trasferimento avviene a livello di blocco, molto più efficiente e con sicurezza atomica. Per database, le snapshot di filesystem combinati con fsfreeze garantiscono consistenza senza fermare il servizio.

Scenari d'uso reali

Una web agency con 30 siti su Plesk schedula rsync notturni verso un server remoto Hetzner Storage Box: 50 euro/mese, retention 30 giorni, restore di un sito in 15 minuti.

Un file server aziendale con 2 TB di dati su NAS replica via rsync verso un secondo NAS in altra sede via VPN WireGuard: protezione da incendio o furto.

Un server di sviluppo con codice già su git fa backup solo del database e dei file utente, con rsync giornaliero verso un VPS economico in altra regione.

Checklist operativa per backup rsync

• Almeno 2 destinazioni: locale veloce + off-site sicura.
• Cifratura lato client prima dell'upload off-site.
• Verifica integrita periodica con checksum.
• Logging strutturato e alert in caso di fallimento.
• Retention GFS (7 giornalieri, 4 settimanali, 12 mensili).
• Test di restore mensile su host di staging.
• Documentazione delle procedure in runbook.

Risorse e riferimenti

Documentazione rsync man page e rsync.samba.org. Alternative complementari: restic.net, borgbackup.readthedocs.io, duplicity.gitlab.io. Per validazione integrita, par2cmdline aggiunge ridondanza parity. La filosofia 3-2-1-1-0 e ben spiegata nei blog di Veeam e Acronis.

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su backup automatico server con rsync e cron richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.