Perché una copia speculare con Rsync trasferisce le cancellazioni accidentali al backup?

Uno specchio rsync copia le cancellazioni accidentali perché uno specchio è progettato per far corrispondere la destinazione alla sorgente corrente. Quando il lavoro usa --delete o un'opzione di cancellazione correlata, un file mancante dal NAS domestico è trattato come un file extra nella destinazione di backup e viene rimosso durante la sincronizzazione. Questo comportamento è corretto per uno specchio, ma non è sicuro come unica storia di recupero.

Rsync segue una regola di specchio, non preserva ogni versione passata

Senza un'opzione di cancellazione, rsync normalmente copia i file nuovi e modificati ma lascia i file presenti solo nella destinazione al loro posto. Con --delete, la destinazione viene riconciliata con la sorgente. Una spiegazione concisa del flag afferma che eliminare un file dalla sorgente lo rimuove anche dalla destinazione così che la destinazione rimane un vero specchio.

Per un NAS domestico ZimaSpace, questo significa che una foto di famiglia eliminata, una cartella media rinominata, una configurazione container rimossa o un mount temporaneamente mancante possono riflettersi sul mirror USB o remoto alla prossima esecuzione programmata.

La cancellazione inizia con un percorso sorgente mancante

Rsync non sa se un file è scomparso perché lo hai eliminato intenzionalmente, un'app lo ha pulito, un utente ha commesso un errore, un ransomware ha modificato l'albero o un dataset sorgente non è stato montato. Confronta l'albero sorgente visibile con quello di destinazione. Se un oggetto esiste solo sul lato ricevente e la cancellazione è abilitata, diventa un candidato alla cancellazione.

Il momento della cancellazione cambia quando i file vengono rimossi, non se vengono rimossi.

Le opzioni correlate controllano la fase del trasferimento. --delete-before rimuove i file presenti solo nella destinazione prima della copia, --delete-during elimina mentre le directory vengono elaborate, e --delete-after attende che i trasferimenti finiscano. Influenzano il comportamento dello spazio libero e l'esposizione ai fallimenti, ma non trasformano lo specchio in un backup versionato.

Usa il timing deliberatamente. Eliminare prima del trasferimento può liberare capacità ma rimuove lo stato precedente dello specchio prima. Eliminare dopo il trasferimento preserva più a lungo il contenuto vecchio della destinazione, ma il risultato finale corrisponde comunque alla sorgente se il lavoro viene completato.

Un montaggio mancante può sembrare una cancellazione di massa

Uno dei casi più pericolosi per un server domestico si verifica quando il percorso sorgente programmato esiste ancora come directory vuota dopo che il pool di archiviazione reale non si monta. Rsync può quindi confrontare una sorgente vuota con una destinazione popolata. Una salvaguardia proposta è eseguire un controllo a secco e contare le eliminazioni pianificate prima di consentire la sincronizzazione reale.

Su un NAS domestico, fai fallire il lavoro se manca il montaggio della sorgente previsto, l'UUID del filesystem, la directory segnaposto o il conteggio minimo di file. Non considerare l'esistenza di un percorso vuoto come una sorgente sana.

Metti in pausa il lavoro prima di tentare di recuperare un file eliminato

1. Disabilita immediatamente l'attività rsync programmata.
2. Non eseguire nuovamente il comando per “vedere se si risolve da solo.”
3. Controlla snapshot, cestini, repository di backup versionati e la seconda copia offline.
4. Se lo specchio contiene ancora il file, copialo in un percorso di quarantena al di fuori della destinazione rsync prima della prossima esecuzione.
5. Conferma se l'eliminazione dalla sorgente è stata intenzionale prima di ripristinarla nella condivisione attiva.

L'articolo di ZimaSpace su mantenere le foto di famiglia in più copie indipendenti è rilevante qui: uno specchio sincronizzato dovrebbe essere un livello, non l'unico posto dove un file più vecchio può sopravvivere.

Anteprima del set esatto di eliminazioni

Esegui lo stesso comando con --dry-run, itemizzazione dettagliata e report delle eliminazioni. Controlla i percorsi di origine e destinazione, le barre finali, le esclusioni, lo stato del montaggio e il numero di eliminazioni pianificate. Un recente articolo sulla sicurezza di rsync sottolinea che uno specchio può riprodurre eliminazioni accidentali o danni da ransomware e quindi necessita di un livello di cronologia separato.

rsync -a --delete --dry-run --itemize-changes   /srv/storage/family/ /mnt/usb-mirror/family/

Considera un numero inaspettatamente elevato di eliminazioni come un controllo preliminare fallito. Interrompi e verifica che il dataset NAS previsto sia montato e che il comando non sia rivolto a una directory superiore o al disco rimovibile sbagliato.

Sposta i file di destinazione eliminati in un'area di recupero

Se hai bisogno di uno specchio ma vuoi anche una finestra di recupero breve, combina la cancellazione con una directory di backup o uno strato di snapshot. Rsync può spostare i file sostituiti o cancellati della destinazione in una directory di recupero datata invece di distruggerli immediatamente. Le indicazioni della comunità per conservare i dati cancellati da rsync raccomandano di mantenere i file cancellati in una posizione separata con una propria politica di pulizia.

rsync -a --delete   --backup   --backup-dir="/mnt/usb-mirror/deleted/$(date +%F)"   /srv/storage/family/ /mnt/usb-mirror/current/

Testa il comando prima con dati non critici. La directory di recupero deve essere al di fuori del sottoalbero specchiato, altrimenti una futura esecuzione potrebbe trattarla come parte della sorgente o cancellarla con la stessa politica.

Usa Snapshot Versionati Quando Contano gli Stati Passati

Uno specchio attuale risponde a “come appare ora la sorgente?” Un backup risponde a “come appariva la sorgente prima dell’errore?” Se hai bisogno di entrambi, mantieni lo specchio per un accesso rapido e aggiungi snapshot del filesystem, directory snapshot con hard-link, uno strumento di backup versionato o un secondo disco offline.

Un resoconto di una cancellazione accidentale con rsync descrive chiaramente la debolezza sottostante: un flusso di lavoro rsync costruito a mano necessita di rotazione esplicita e salvaguardie per la cancellazione. Non fare affidamento su una singola destinazione mutabile per fornire sia sincronizzazione esatta che cronologia a lungo termine.

FAQ

Se rimuovo --delete, lo specchio diventa un backup?

Non da sola. I file presenti solo nella destinazione rimarranno, ma i file sovrascritti potrebbero comunque perdere i contenuti precedenti e non esiste un punto di ripristino pulito per una data specifica. Aggiungi snapshot o un repository di backup versionato.

Qual è l’opzione di tempistica di cancellazione più sicura?

--delete-after ritarda le cancellazioni fino al completamento dei trasferimenti, preservando più a lungo lo stato precedente della destinazione durante l’esecuzione. Cancella comunque i file presenti solo nella destinazione al termine, quindi controlli preliminari e cronologia delle versioni restano necessari.

Come posso fermare una cancellazione di massa imprevista?

Disabilita la pianificazione, esegui una simulazione con output delle cancellazioni, verifica il mount e il percorso della sorgente, e imposta una soglia di conteggio cancellazioni o un controllo del file marker. Non rieseguire il comando live finché non si comprende la lista proposta di cancellazioni.

Conclusione finale

Rsync riflette le cancellazioni accidentali perché le opzioni di cancellazione fanno sì che la destinazione del backup corrisponda alla sorgente NAS visibile. Proteggi il flusso di lavoro del server domestico ZimaSpace verificando i mount, visualizzando in anteprima le cancellazioni, mettendo in quarantena i file rimossi e mantenendo punti di recupero versionati o offline. Uno specchio può essere utile, ma uno specchio esatto senza cronologia non è una protezione sufficiente contro gli errori umani.