Perché Rsync può rompere i backup incrementali senza errori evidenti

Rsync 3.4.3 può causare un problema serio: i backup incrementali smettono di funzionare correttamente: molti utenti hanno risolto tornando alla versione 3.4.1, che ripristina il comportamento atteso. Il problema non è banale perché rsync non è un tool marginale, ma uno dei mattoni storici dei backup Unix e Linux, usato da amministratori, NAS, script cron e procedure di disaster recovery.

Il dato tecnico più rilevante è che rsync 3.4.3 corregge 6 vulnerabilità di sicurezza, ma alcune correzioni sembrano aver alterato comportamenti usati da anni nei backup incrementali. Quando rsync è utilizzato in modalità daemon, i backup basati su hard link (collegamenti che permettono a più copie di condividere gli stessi dati senza occupare spazio aggiuntivo) non riutilizzano i file presenti nel backup precedente e trasferiscono nuovamente tutti i dati. Di conseguenza, dopo pochi cicli di backup, lo spazio disponibile sui dischi può esaurirsi rapidamente.

Perché il problema con rsync colpisce proprio i backup incrementali

Molti script usano rsync per creare snapshot completi solo in apparenza. In pratica, ogni backup contiene una struttura completa di cartelle e file, ma i file che non hanno subito modifiche condividono lo stesso inode, ovvero la struttura del file system che memorizza le informazioni sul file, grazie all’uso degli hard link. Il risparmio di spazio deriva proprio da questo meccanismo: se un file rimane invariato, non viene copiato di nuovo, ma si riutilizza semplicemente il riferimento già esistente.

Il meccanismo tipico usa --link-dest="../backup-precedente": Rsync confronta la sorgente con la directory indicata e, quando trova file identici per dimensione, timestamp e metadati rilevanti, crea un link fisico invece di riscrivere i dati. Se questa logica salta, il backup resta formalmente valido, ma perde la sua caratteristica essenziale: occupa spazio come una copia completa.

Il tema scottante delle modifiche assistite da LLM (AI)

La discussione pubblica è esplosa anche per un motivo culturale: alcuni commit ovvero alcune modifiche integrate di recente nel codice di rsync risultano attribuite a Claude.

Ciò significa che alcuni sviluppatori hanno utilizzato ad esempio Claude Code per intervenire direttamente sul sorgente di rsync. Un LLM (Large Language Model) può aiutare a scrivere codice, generare test, rivedere patch o proporre refactoring: il problema nasce quando l’output entra in aree sensibili senza revisione profonda, test di regressione e casi d’uso realistici.

Rsync non manipola dati astratti: decide cosa copiare, cosa saltare, cosa cancellare e cosa collegare tramite inode: una piccola modifica nel controllo dei percorsi, nella gestione di chroot o nei permessi può cambiare il comportamento di un vasto numero di sistemi di backup.

Il codice generato o assistito non è diverso dal codice scritto a mano quando arriva in produzione: deve essere sottoposto agli stessi controlli, processi di verifica e standard qualitativi. Anzi, in molti casi richiede persino maggiore attenzione, perché può sembrare corretto e coerente a prima vista pur non rispettando le regole fondamentali, i vincoli logici e i comportamenti consolidati su cui si basa storicamente il software.

Cosa controllare subito sui sistemi già aggiornati all’ultima versione di rsync

Chi usa rsync 3.4.3, o pacchetti 3.2.7 con backport di sicurezza recenti, dovrebbe verificare i backup incrementali. Il controllo minimo consiste nel confrontare lo spazio realmente occupato e il numero di link dei file che non hanno subito modifiche.

Su Linux si può usare stat su un file che non cambia tra due snapshot: il campo link count deve aumentare se lo stesso inode compare in più backup.

Anche du -sh e du -sh --apparent-size aiutano a distinguere spazio fisico e dimensione apparente. Se ogni nuova esecuzione consuma quasi lo stesso spazio della sorgente, l’opzione --link-dest non sta lavorando.

Un test prudente prevede l’uso di risorse di piccole dimensioni con un backup incrementale tramite rsync in una destinazione temporanea. Dopo la seconda esecuzione, i file invariati devono condividere gli inode con quelli del primo snapshot.

La vicenda ricorda una regola spesso dimenticata: un backup riuscito non coincide con un ripristino riuscito. Nel caso di rsync 3.4.3 il rischio è ancora più subdolo, perché il backup può concludersi senza errori e produrre file leggibili, ma consumare spazio in modo anomalo.

Dopo alcuni giorni, il sistema non riesce più a mantenere correttamente il numero di backup previsto dalla politica di retention (conservazione delle copie nel tempo): gli snapshot più vecchi sono eliminati prima del previsto oppure lo spazio di archiviazione si esaurisce completamente, portando il filesystem a raggiungere il 100% di utilizzo.