Waarom kopieert een Rsync-spiegel per ongeluk verwijderde bestanden naar de back-up?

Een rsync-spiegel kopieert per ongeluk verwijderde bestanden omdat een spiegel is ontworpen om de bestemming te laten overeenkomen met de huidige bron. Wanneer de taak gebruikt maakt van --delete of een gerelateerde verwijderoptie, wordt een bestand dat ontbreekt op de thuis-NAS behandeld als een extra bestand op de back-upbestemming en verwijderd tijdens synchronisatie. Dat gedrag is correct voor een spiegel, maar onveilig als enige herstelgeschiedenis.

Rsync volgt een spiegelregel, niet het bewaren van elke vorige versie

Zonder een verwijderoptie kopieert rsync normaal gesproken nieuwe en gewijzigde bestanden, maar laat alleen-bestemmingsbestanden staan. Met --delete wordt de bestemming afgestemd op de bron. Een beknopte uitleg van de vlag stelt dat het verwijderen van een bestand uit de bron het ook van de bestemming verwijdert zodat de bestemming een ware spiegel blijft.

Voor een ZimaSpace thuis-NAS betekent dit dat een verwijderde familiefoto, hernoemde mediapmap, verwijderde containerconfiguratie of tijdelijk ontbrekende koppeling kan worden weerspiegeld op de USB- of externe spiegel bij de volgende geplande uitvoering.

Het verwijderen begint met een ontbrekend bronpad

Rsync weet niet of een bestand verdwenen is omdat je het bewust hebt verwijderd, een app het heeft opgeruimd, een gebruiker een fout maakte, ransomware de boom heeft veranderd, of een bron-dataset niet kon worden aangekoppeld. Het vergelijkt de zichtbare bronboom met de bestemmingsboom. Als een object alleen aan de ontvangende kant bestaat en verwijderen is ingeschakeld, wordt het een verwijderingskandidaat.

De timing van verwijderen verandert wanneer bestanden worden verwijderd, niet of ze worden verwijderd.

De gerelateerde opties regelen de fase van de overdracht. --delete-before verwijdert alleen-bestemmingsbestanden vóór het kopiëren, --delete-during verwijdert terwijl mappen worden verwerkt, en --delete-after wacht tot overdrachten zijn voltooid. Ze beïnvloeden het vrije-ruimtegedrag en de blootstelling aan fouten, maar ze veranderen de spiegel niet in een versie-back-up.

Gebruik de timing bewust. Verwijderen vóór de overdracht kan capaciteit vrijmaken, maar verwijdert de vorige spiegelstatus eerder. Verwijderen na de overdracht behoudt de oude inhoud van de bestemming langer, maar het eindresultaat komt nog steeds overeen met de bron als de taak voltooid is.

Een Ontbrekende Koppeling Kan Uitzien als een Massale Verwijdering

Een van de gevaarlijkste situaties op een thuisserver ontstaat wanneer het geplande bronpad nog bestaat als een lege map nadat het echte opslagpool niet is aangekoppeld. Rsync kan dan een lege bron vergelijken met een gevulde bestemming. Een voorgestelde beveiliging is om een droge controle uit te voeren en het aantal geplande verwijderingen te tellen voordat de echte synchronisatie wordt toegestaan.

Laat een taak op een thuis-NAS falen als de verwachte bronkoppeling, bestandssysteem-UUID, markermap of minimaal aantal bestanden ontbreekt. Laat het bestaan van een lege map niet tellen als een gezonde bron.

Pauzeer de Taak Voordat je Probeert een Verwijderd Bestand te Herstellen

1. Schakel de geplande rsync-taak onmiddellijk uit.
2. Voer het commando niet opnieuw uit om te “zien of het zichzelf herstelt.”
3. Controleer snapshots, prullenbakken, versie-back-uprepositories en de tweede offline kopie.
4. Als de spiegel het bestand nog bevat, kopieer het dan naar een quarantainepad buiten de rsync-bestemming vóór de volgende run.
5. Bevestig of de bronverwijdering opzettelijk was voordat je het herstelt in de live share.

Het ZimaSpace-artikel over het bewaren van familiefoto’s in meerdere onafhankelijke kopieën is hier relevant: een gesynchroniseerde spiegel moet één laag zijn, niet de enige plek waar een ouder bestand kan overleven.

Bekijk de Exacte Set Verwijderingen Vooraf

Voer hetzelfde commando uit met --dry-run, gedetailleerde itemisatie en rapportage van verwijderingen. Controleer de bron- en doelpaden, afsluitende schuine strepen, uitsluitingen, koppelstatus en het aantal geplande verwijderingen. Een recent artikel over rsync-veiligheid benadrukt dat een spiegel per ongeluk verwijderen of ransomware-schade kan reproduceren en daarom een aparte geschiedenislaag nodig heeft.

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

Behandel een onverwacht groot aantal verwijderingen als een mislukte preflight-controle. Stop en controleer of de bedoelde NAS-dataset is aangekoppeld en dat het commando niet gericht is op een bovenliggende map of de verkeerde verwisselbare schijf.

Verplaats Verwijderde Bestanden naar een Herstelgebied

Als je een spiegel nodig hebt maar ook een korte herstelperiode wilt, combineer dan verwijdering met een back-upmap of snapshotlaag. Rsync kan vervangen of verwijderde bestemmingsbestanden verplaatsen naar een gedateerde herstelmap in plaats van ze onmiddellijk te vernietigen. Community-richtlijnen voor het behouden van verwijderde rsync-gegevens raden aan verwijderde bestanden op een aparte locatie te bewaren met een eigen opruimbeleid.

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

Test het commando eerst met niet-kritische gegevens. De herstelmap moet buiten de gespiegeld submap liggen, anders kan een toekomstige uitvoering deze als onderdeel van de bron beschouwen of verwijderen volgens hetzelfde beleid.

Gebruik versiebeheerde snapshots wanneer eerdere toestanden belangrijk zijn

Een actuele spiegel beantwoordt de vraag “hoe ziet de bron er nu uit?” Een back-up beantwoordt “hoe zag de bron eruit vóór de fout?” Als je beide nodig hebt, houd dan de spiegel voor snelle toegang en voeg bestandssysteem-snapshots, hardlink snapshot-mappen, een versiebeheer back-uptool of een tweede offline schijf toe.

Een verslag van per ongeluk rsync-verwijdering beschrijft de onderliggende zwakte duidelijk: een handmatig gemaakte rsync workflow heeft expliciete rotatie- en verwijderingsbeveiligingen nodig. Vertrouw niet op één wijzigbare bestemming die zowel exacte synchronisatie als langdurige geschiedenis biedt.

FAQ

Als ik verwijder --delete, wordt de spiegel dan een back-up?

Niet op zichzelf. Alleen-bestemmingsbestanden blijven bestaan, maar overschreven bestanden kunnen nog steeds hun vorige inhoud verliezen, en er is geen schoon herstelpunt voor een specifieke datum. Voeg snapshots of een versiebeheer back-uprepository toe.

Welke verwijderingstimingoptie is het veiligst?

--delete-after vertraagt verwijderingen tot de overdrachten zijn voltooid, wat de oude bestemmingsstatus langer behoudt tijdens de uitvoering. Het verwijdert nog steeds alleen-bestemmingsbestanden bij voltooiing, dus preflight-controles en versiegeschiedenis blijven noodzakelijk.

Hoe stop ik een onverwachte massale verwijdering?

Schakel het schema uit, voer een proefrun uit met verwijderingsoutput, verifieer de bronmount en het pad, en stel een drempel voor het aantal verwijderingen of een controle op een markeringsbestand in. Voer het live-commando niet opnieuw uit voordat de voorgestelde lijst met verwijderingen is begrepen.

Belangrijkste conclusie

Rsync spiegelt per ongeluk verwijderingen omdat verwijderingsopties de back-upbestemming laten overeenkomen met de zichtbare NAS-bron. Bescherm een ZimaSpace home-server workflow door mounts te verifiëren, verwijderingen te bekijken, verwijderde bestanden in quarantaine te plaatsen en versiebeheer of offline herstelpunten te behouden. Een spiegel kan nuttig zijn, maar een exacte spiegel zonder geschiedenis biedt geen voldoende bescherming tegen menselijke fouten.