Waarom werkt een ZFS-hervattingstoken voor verzenden niet meer nadat de bestemming opnieuw is opgestart?

Een herstart van de bestemming zou een ZFS-hervattingstoken normaal gesproken niet ongeldig moeten maken, tenzij de opgeslagen ontvangststatus, dataset of vereiste bronhistorie is gewijzigd.

Het token is een ondoorzichtige beschrijving van een specifieke onderbroken ontvangst en geen herbruikbare bladwijzer voor een latere replicatiepoging. Het hoort bij het bestandssysteem of volume op de bestemming dat de gedeeltelijke status met een hervatbare ontvangst heeft bewaard. Na een herstart kan een taak de verkeerde dataset lezen, de pool op een andere manier importeren, de gedeeltelijke status wissen, de bestemming wijzigen, een vereiste momentopname op de bron verliezen of een incompatibele stream genereren. Controleer het token aan beide kanten voordat u een volledige overdracht opnieuw start.

Bevestig dat de gedeeltelijke ontvangst de herstart heeft overleefd

Lees op de bestemming de eigenschap receive_resume_token uit van exact het bestandssysteem of volume dat voor de onderbroken ontvangst werd gebruikt. Noteer de poolnaam, het datasetpad, de tokenwaarde en het ruimtegebruik van de gedeeltelijke status.

Het FreeBSD-handboek legt uit dat hervatbare ontvangsten de gedeeltelijke status bewaren en een ondoorzichtig token op de ontvangende dataset behouden totdat de overdracht is voltooid of de status expliciet wordt opgegeven.

Als de eigenschap na de herstart leeg is, is de ontvangst niet opgeslagen met de optie voor hervatbaarheid, is de gedeeltelijke status voltooid of afgebroken, wordt de verkeerde dataset bevraagd of heeft een geautomatiseerde opschoning de status verwijderd. Gebruik een token dat van een eerdere overdracht is gekopieerd niet opnieuw.

Controleer of het token bij exact dezelfde bestemmingsdataset hoort

Controleer of de bestemmingspool onder de verwachte naam is geïmporteerd en of de replicatie nog steeds op hetzelfde datasetpad is gericht. Let op alternatieve hoofdlocaties, hernoemde pools, wijzigingen in bovenliggende paden en taakopties die padonderdelen toevoegen of verwijderen.

De referentie voor ZFS-eigenschappen van Ubuntu definieert receive_resume_token als een dataseteigenschap. Het token moet daarom worden uitgelezen van het bestandssysteem of volume waarop die specifieke opgeslagen status staat.

Er mag niet zonder meer van worden uitgegaan dat een token uit backup/pool/data een ontvangst kan hervatten die nu op backup/data is gericht. Corrigeer het taakpad voordat u momentopnamen wijzigt of de gedeeltelijke ontvangst vernietigt.

Controleer of de bestemming is gewijzigd of teruggedraaid

Inspecteer opdrachten, geplande taken, replicatiesoftware, bewaarbeleid voor momentopnamen en beheerderactiviteit sinds de onderbreking. Zoek naar terugdraaiacties, promotie van klonen, het hernoemen van datasets, het afbreken van ontvangsten of een nieuwe ontvangst naar hetzelfde doel.

Klara Systems merkt op dat replicatiehulpmiddelen de bestemmingsstatus beheren rond ZFS send en receive. Daardoor kan een orkestratietaak het oorspronkelijke herstelpad ongeldig maken door de opgeslagen status op te schonen of te vervangen.

Schrijf tijdens het onderzoek geen gewone bestanden naar een replicatiebestemming. Zelfs als het token nog bestaat, kunnen wijzigingen op de bestemming de stream blokkeren of een terugdraaiactie afdwingen die nieuwere gegevens op de bestemming vernietigt.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Controleer of de bron de momentopname- of bladwijzerketen nog heeft

Identificeer de brondataset en de momentopnamen of bladwijzers die in de onderbroken overdracht zijn vastgelegd. Vergelijk deze met het huidige bewaarbeleid en met eventuele hernoemingen of verwijderingen van momentopnamen sinds de overdracht is gestopt.

De FreeBSD-handleiding voor zfs-send specificeert dat zfs send -t een stream genereert op basis van het hervattingstoken voor de ontvangst. De nieuwe stream wordt daarmee gekoppeld aan de onderbroken ontvangst en niet aan een willekeurige huidige momentopname.

Als het bewaarbeleid de vereiste bronhistorie heeft verwijderd, kan het token geen gegevens reconstrueren die niet meer bestaan. Bewaar de resterende gedeeltelijke status op de bestemming totdat u hebt bepaald of een andere bronkopie of een nieuwe volledige verzending nodig is.

Controleer poolfuncties en streamopties op beide systemen

Noteer de ZFS-versies, ingeschakelde poolfuncties, versleutelingsstatus en de oorspronkelijke streamopties, zoals raw-, compressed-, embedded- of large-block-verzendingen. Vergelijk deze na elke software- of poolupgrade.

De documentatie van Oracle over hervatbare replicatie beschrijft het hervatten van een onderbroken overdracht als een gecoördineerde send-and-receive-bewerking. Compatibiliteit en de oorspronkelijke overdrachtscontext blijven daarom ook na een herstart belangrijk.

Een herstart op zichzelf verandert geen functievlaggen, maar een upgrade tijdens de onderbreking kan dat wel doen. Voer de hervattingsopdracht handmatig uit met uitgebreide uitvoer voordat u ervan uitgaat dat het token zelf beschadigd is.

Controleer replicatieservices en SSH na het opstarten van de bestemming

Bevestig dat de bestemmingspool is geïmporteerd, vereiste versleutelde datasets zijn ontgrendeld, SSH actief is, de replicatiegebruiker ZFS-opdrachten kan uitvoeren en de taak pas start nadat de opslag beschikbaar is.

De richtlijnen van TrueNAS voor replicatie op afstand vereisen dat de SSH- en datasetvereisten op de bestemming na een herstart beschikbaar zijn. Anders kan de automatisering mislukken voordat het opgeslagen token zelfs maar wordt geprobeerd.

Test de authenticatie en een alleen-lezen-eigenschapsquery voordat u de hervatte stream start. Een netwerk- of machtigingsfout kan in een logboek van een taak op hoog niveau op een tokenfout lijken.

Hervat de gedeeltelijke ontvangst één keer of breek deze bewust af

Genereer met het huidige token één hervatte send-stream en voer die naar een hervatbare ontvangst op dezelfde bestemming. Sla de volledige foutuitvoer op en voorkom dat parallelle replicatietaken worden gestart.

De NAS-datamigratiehandleiding van ZimaSpace geeft de bijbehorende veiligheidsregel: bewaar de bron en het terugdraaipad totdat de bestemming is geverifieerd.

Als het token onbruikbaar is en de gedeeltelijke status geen waarde meer heeft, breek deze dan alleen af met de ondersteunde opdracht voor het afbreken van ontvangsten nadat u hebt bevestigd dat een nieuwe volledige of incrementele overdracht kan worden gegenereerd. Het afbreken maakt de opgeslagen gedeeltelijke status vrij en kan niet ongedaan worden gemaakt.

Veelgestelde vragen

Maakt een herstart van de bestemming een ZFS-hervattingstoken altijd ongeldig?

Nee. Een opgeslagen gedeeltelijke ontvangst is ontworpen om onderbrekingen, waaronder een onzuivere afsluiting, te overleven. Een fout na de herstart betekent meestal dat de taak een andere dataset leest, de gedeeltelijke status is gewist, vereiste bronhistorie is gewijzigd of opstartafhankelijkheden ontbreken.

Kan er alleen vanaf de bron een nieuw hervattingstoken worden gegenereerd?

Nee. Het ondoorzichtige token komt uit de opgeslagen gedeeltelijke ontvangststatus van de bestemmingsdataset. De bron gebruikt dat token om een vervolsstream te genereren, maar kan een verwijderde status op de bestemming niet zelfstandig opnieuw maken.

Wanneer moet de gedeeltelijke ontvangst worden afgebroken?

Breek deze alleen af wanneer is aangetoond dat het hervattingspad onbruikbaar is, de bron een vervangende overdracht kan genereren en de gedeeltelijke status op de bestemming niet langer nodig is voor herstel. Bewaar logboeken en beschikbare momentopnamen voordat u deze verwijdert.