Wanneer moet je een verbroken ZFS-replicatieketen opnieuw seeden?

Maak opnieuw een volledige seed wanneer je geen geldige gemeenschappelijke basis kunt aantonen of wanneer het herstellen van de keten een niet-geverifieerde rollback van de bestemming zou vereisen. Bewaar eerst de laatst leesbare replica.

In een thuis-NAS is de verleidelijke kortere weg om de volgende incrementele verzending geforceerd uit te voeren totdat deze werkt. Dat kan een ontbrekende bovenliggende snapshot, een afwijkende bestemming of een ontvangstdestination verbergen die niet langer de dataset is die je denkt. Begin met het inventariseren van beide kanten zonder iets te wijzigen, toon aan of er nog een gedeelde basis bestaat en gebruik een gefaseerde volledige seed wanneer het bewijs geen veilige voortzetting van de incrementele overdracht ondersteunt.

Toon aan dat beide kanten nog steeds dezelfde basis delen

Begin met een alleen-lezeninventarisatie van de brondataset, bestemmingsdataset, snapshots, bladwijzers en eventuele status van hervatten bij ontvangst. Vergelijk meer dan alleen een handige snapshotnaam: bevestig dat de kandidaatbasis bij de bedoelde datasets hoort en dezelfde replicatiegeschiedenis vertegenwoordigt. Bewaar de overzichten voordat je opruimt, zodat je kunt uitleggen waarom voor de volgende actie is gekozen.

Incrementele ZFS-replicatie is afhankelijk van een basis die al op de ontvanger aanwezig is. Een praktische snapshotreplicatiereeks bewaart de gedeelde geschiedenis daarom bewust, in plaats van ervan uit te gaan dat identieke labels continuïteit bewijzen.

Als er aan beide kanten een geverifieerde basis bestaat, ga dan verder met een niet-destructieve incrementele test. Als de naam bestaat maar de identiteit of het datasetpad verschilt, behandel de keten dan als onbewezen. Als er geen gemeenschappelijke basis meer is, verwijder dan geen extra snapshots en forceer de bestemming niet terug; de beslissing is dan al verschoven richting een gefaseerde reseed.

Test het incrementele plan zonder de replica te wijzigen

Stel de voorgestelde verzending samen met de geverifieerde basis en het nieuwste doel, maar stuur deze nog niet naar de actieve bestemming. Gebruik een proefrun, een uitgebreide schatting of de voorbeeldmodus van de replicatietool. Bevestig het bronpad, bestemmingspad, de basissnapshot, doelsnapshot, recursievlaggen en verwachte streamgrootte voordat een ontvangst gegevens kan wijzigen.

Een planner die geen gemeenschappelijke basissnapshot meldt, weigert een onveilige gok en vraagt niet simpelweg om opnieuw proberen. Herhaaldelijk opnieuw proberen maakt verwijderde gedeelde geschiedenis niet opnieuw aan.

Een stream ter grootte van de delta vanaf exact de basis en het doel ondersteunt het herstellen van de keten. Een stream die bijna zo groot is als de volledige dataset, een onverwachte dataset of een vereiste geforceerde rollback betekent dat de voorbeeldcontrole is mislukt. Stop daar en bewaar de huidige replica; vlaggen blijven wijzigen totdat het commando werkt is geen verificatie.

Kies herstel alleen wanneer geschiedenis en bestemmingstoestand overeenkomen

Herstel het incrementele pad alleen wanneer de gemeenschappelijke basis is geverifieerd, de bestemming geen onafhankelijke werkkopie is geworden en het voorbeeld de verwachte delta voorstelt. Houd de bestemming tijdens het herstelvenster alleen-lezen. Stuur eerst naar een nieuwe child-dataset of stagingdoel wanneer de tool dit toestaat en vergelijk daarna voordat je deze promoveert.

Maak opnieuw een volledige seed wanneer er geen geldige basis bestaat, de bestemming is afgeweken, de vereiste rollback snapshots zou verwijderen die je nog nodig hebt of de tijd die nodig is om de keten te bewijzen groter wordt dan de beheersbare kosten van een nieuwe volledige overdracht. Besprekingen over afstamming van incrementele snapshots bevestigen dat tussenliggende namen minder belangrijk zijn dan het behouden van een bruikbaar gemeenschappelijk punt.

Wis de oude bestemming niet om ruimte te maken tenzij er een andere geverifieerde kopie bestaat. Bij een veiligere reseed schrijf je naar een afzonderlijke dataset of pool, verifieer je de nieuwe kopie en trek je pas daarna de defecte keten terug. Als er niet genoeg capaciteit is om beide te bewaren, pauzeer dan en regel tijdelijke ruimte in plaats van van de laatst leesbare replica een experiment te maken.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Valideer de nieuwe keten gedurende twee replicatiecycli

Eén succesvolle volledige ontvangst bewijst alleen dat er een stream is aangekomen. Maak op de bron een klein testbestand of wijzig een eigenschap, maak de volgende geplande snapshot en voer een tweede incrementele cyclus uit met de nieuwe gemeenschappelijke basis. Vergelijk na beide runs de datasetproperties, snapshotlijsten, een steekproef van bestanden en het replicatielogboek.

Als hervatgedrag onderdeel was van de oorspronkelijke fout, houd dan het eerdere foutpad voor het hervattoken gescheiden van ontbrekende afstamming, zodat hetzelfde symptoom je niet opnieuw naar de verkeerde herstelactie leidt.

Het herstel is geslaagd wanneer de nieuwe seed leesbaar is, de tweede incrementele overdracht de omvang van de delta heeft en succesvol is, en de verwachte snapshots en bestanden na een herstart of geplande run verschijnen. Behoud de voormalige replica totdat deze controles zijn geslaagd. Schakel hulp in als identiteiten opnieuw veranderen, de bestemming niet alleen-lezen kan blijven of de tool herhaaldelijk een onverwachte basis selecteert.