Varför kopierar en Rsync-spegel oavsiktliga borttagningar till säkerhetskopian?

En rsync-spegel kopierar oavsiktliga borttagningar eftersom en spegel är designad för att få destinationen att matcha den aktuella källan. När jobbet använder --delete eller ett relaterat borttagningsalternativ behandlas en fil som saknas från hem-NAS som en extra fil på backupdestinationen och tas bort under synkroniseringen. Det beteendet är korrekt för en spegel, men det är osäkert som den enda återställningshistoriken.

Rsync följer en spegelregel, inte bevarar varje tidigare version

Utan ett borttagningsalternativ kopierar rsync normalt nya och ändrade filer men lämnar filer som endast finns på destinationen kvar. Med --delete försonas destinationen med källan. En kortfattad förklaring av flaggan säger att att ta bort en fil från källan också tar bort den från destinationen så att destinationen förblir en sann spegel.

För en ZimaSpace hem-NAS betyder detta en borttagen familjefoto, en omdöpt mediamapp, borttagen containerkonfiguration eller tillfälligt saknad montering som kan speglas på USB- eller fjärrspegeln vid nästa schemalagda körning.

Borttagningen börjar med en saknad källväg

Rsync vet inte om en fil försvann för att du medvetet tog bort den, en app rensade upp, en användare gjorde ett misstag, ransomware ändrade trädet eller en källdataset misslyckades med att monteras. Den jämför det synliga källträdet med destinationsträdet. Om ett objekt endast finns på mottagarsidan och borttagning är aktiverad blir det en kandidat för borttagning.

Tidsinställningen för borttagning ändrar när filer tas bort, inte om de tas bort

De relaterade alternativen styr överföringsfasen. --delete-before tar bort filer som endast finns på destinationen innan kopiering, --delete-during tar bort medan kataloger bearbetas, och --delete-after väntar tills överföringarna är klara. De påverkar beteendet för ledigt utrymme och exponering för fel, men de förvandlar inte spegeln till en versionshanterad säkerhetskopia.

Använd timingen medvetet. Att ta bort innan överföringen kan frigöra kapacitet men tar bort det tidigare speglingsläget tidigare. Att ta bort efter överföringen bevarar det gamla destinationsinnehållet längre, men det slutliga resultatet matchar fortfarande källan om jobbet slutförs.

En saknad montering kan se ut som en massborttagning

Ett av de farligaste fallen för hemmabaserade servrar uppstår när den schemalagda källvägen fortfarande finns som en tom katalog efter att den verkliga lagringspoolen misslyckats med att monteras. Rsync kan då jämföra en tom källa med en fylld destination. En föreslagen säkerhetsåtgärd är att köra en torrkörning och räkna de planerade borttagningarna innan den verkliga synkroniseringen tillåts.

På en hemmabaserad NAS, låt jobbet misslyckas om den förväntade källmonteringen, filsystemets UUID, markeringskatalogen eller minimalt antal filer saknas. Låt inte existensen av en tom sökväg räknas som en frisk källa.

Pausa jobbet innan du försöker återställa en borttagen fil

1. Inaktivera den schemalagda rsync-uppgiften omedelbart.
2. Kör inte kommandot igen för att "se om det löser sig självt."
3. Kontrollera snapshots, papperskorgar, versionshanterade säkerhetskopieringsarkiv och den andra offlinekopian.
4. Om spegeln fortfarande innehåller filen, kopiera den till en karantänväg utanför rsync-destinationen innan nästa körning.
5. Bekräfta om borttagningen i källan var avsiktlig innan du återställer den till den aktiva delningen.

ZimaSpace-artikeln om att bevara familjefoton i flera oberoende kopior är relevant här: en synkroniserad spegel bör vara ett lager, inte den enda plats där en äldre fil kan finnas kvar.

Förhandsgranska den exakta uppsättningen borttagningar

Kör samma kommando med --dry-run, detaljerad uppräkning och rapportering av borttagningar. Granska käll- och destinationsvägar, avslutande snedstreck, undantag, monteringsstatus och antalet planerade borttagningar. En nyligen publicerad säkerhetsartikel om rsync betonar att en spegel kan återskapa oavsiktlig borttagning eller ransomware-skada och därför behöver ett separat historiklager.

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

Behandla ett oväntat stort antal borttagningar som en misslyckad förkontroll. Stoppa och kontrollera att den avsedda NAS-datamängden är monterad och att kommandot inte riktas mot en överordnad katalog eller fel borttagbar disk.

Flytta borttagna destinationsfiler till ett återställningsområde

Om du behöver en spegel men också vill ha ett kort återställningsfönster, kombinera borttagning med en backupkatalog eller snapshotlager. Rsync kan flytta ersatta eller borttagna destinationsfiler till en daterad återställningskatalog istället för att förstöra dem omedelbart. Gemenskapens rekommendation för att behålla borttagna rsync-data är att behålla borttagna filer på en separat plats med egen städpolicy.

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

Testa kommandot med icke-kritiska data först. Återställningskatalogen måste vara utanför den speglade undermappen, annars kan en framtida körning behandla den som en del av källan eller ta bort den enligt samma policy.

Använd versionerade snapshots när tidigare tillstånd är viktiga

En aktuell spegel svarar på ”hur ser källan ut nu?” En backup svarar på ”hur såg källan ut före misstaget?” Om du behöver båda, behåll spegeln för snabb åtkomst och lägg till filsystemssnapshots, hårda länksnapshotkataloger, ett versionerat backupverktyg eller en andra offline-disk.

En redogörelse för oavsiktlig rsync-borttagning beskriver den underliggande svagheten tydligt: ett handbyggt rsync-arbetsflöde behöver uttryckliga rotation- och borttagningsskydd. Lita inte på en enda förändringsbar destination för både exakt synkronisering och långsiktig historik.

Vanliga frågor

Om jag tar bort --delete, blir spegeln då en backup?

Inte ensamt. Filer som bara finns på destinationen kommer att finnas kvar, men överskrivna filer kan fortfarande förlora sitt tidigare innehåll, och det finns ingen ren återställningspunkt för ett specifikt datum. Lägg till snapshots eller ett versionerat backupförråd.

Vilket borttagningsalternativ är säkrast?

--delete-after fördröjer borttagningar tills överföringarna är klara, vilket bevarar det gamla destinationsläget längre under körningen. Det tar ändå bort filer som bara finns på destinationen vid slutförandet, så förhandskontroller och versionshistorik är fortfarande nödvändiga.

Hur stoppar jag en oväntad massborttagning?

Inaktivera schemat, kör en testkörning med borttagningsutdata, verifiera källmontering och sökväg, och ställ in en tröskel för borttagningsantal eller kontroll av markörfil. Kör inte om det aktiva kommandot förrän den föreslagna borttagningslistan är förstådd.

Slutsats

Rsync speglar oavsiktliga borttagningar eftersom borttagningsalternativ gör att backupdestinationen matchar den synliga NAS-källan. Skydda en ZimaSpace hemserverarbetsflöde genom att verifiera monteringar, förhandsgranska borttagningar, karantänsätta borttagna filer och behålla versionerade eller offline återställningspunkter. En spegel kan vara användbar, men en exakt spegel utan historik är inte tillräckligt skydd mot mänskliga misstag.