Varför slutar en ZFS-återupptagningstoken för sändning att fungera efter att destinationen har startats om?
En omstart av destinationen bör normalt inte göra en ZFS-återupptagningstoken ogiltig, såvida inte det sparade mottagningstillståndet, datauppsättningen eller den nödvändiga källhistoriken har ändrats.
Token är en ogenomskinlig beskrivning av en specifik avbruten mottagning, inte ett återanvändbart bokmärke för framtida replikeringsförsök. Den hör till det filsystem eller den volym på destinationen som bevarade det partiella tillståndet med en återupptagbar mottagning. Efter en omstart kan en uppgift läsa fel datauppsättning, importera poolen på ett annat sätt, rensa det partiella tillståndet, ändra destinationen, förlora en nödvändig källögonblicksbild eller generera en inkompatibel dataström. Verifiera token i båda ändar innan du startar en full överföring igen.
Bekräfta att den partiella mottagningen överlevde omstarten
På destinationen läser du egenskapen receive_resume_token från exakt det filsystem eller den volym som användes för den avbrutna mottagningen. Anteckna poolnamnet, sökvägen till datauppsättningen, tokenvärdet och utrymmesanvändningen för det partiella tillståndet.
FreeBSD-handboken förklarar att återupptagbara mottagningar bevarar partiellt tillstånd och behåller en ogenomskinlig token på den mottagande datauppsättningen tills överföringen är klar eller tillståndet uttryckligen överges.
Om egenskapen är tom efter omstarten sparades mottagningen inte med alternativet för återupptagning, det partiella tillståndet slutfördes eller avbröts, fel datauppsättning efterfrågas eller så har en automatisk rensning tagit bort det. Återanvänd inte en token som kopierats från en tidigare överföring.
Verifiera att token tillhör exakt rätt destinationsdatauppsättning
Kontrollera om destinationspoolen importerades med förväntat namn och om replikeringen fortfarande riktas mot samma sökväg till datauppsättningen. Var uppmärksam på alternativa rötter, namnändrade pooler, ändringar i överordnade sökvägar och uppgiftsalternativ som lägger till eller tar bort sökvägskomponenter.
Ubuntus referens för ZFS-egenskaper definierar receive_resume_token som en egenskap hos datauppsättningen, vilket innebär att token måste läsas från det filsystem eller den volym som innehåller just det sparade tillståndet.
En token som hämtats från backup/pool/data kan inte utan vidare antas kunna återuppta en mottagning som nu riktas mot backup/data. Korrigera uppgiftens sökväg innan du ändrar ögonblicksbilder eller förstör den partiella mottagningen.
Kontrollera om destinationen ändrades eller återställdes
Granska kommandon, schemalagda uppgifter, replikeringsprogram, kvarhållningsregler för ögonblicksbilder och administratörsaktivitet sedan avbrottet. Leta efter återställning, befordran av klon, namnändring av datauppsättning, avbruten mottagning eller en ny mottagning till samma mål.
Klara Systems påpekar att replikeringsverktyg hanterar destinationstillstånd kring ZFS-sändning och -mottagning. En orkestreringsuppgift kan därför göra den ursprungliga återställningsvägen ogiltig genom att rensa eller ersätta det sparade tillståndet.
Skriv inte vanliga filer till en replikeringsdestination medan du utreder problemet. Även om token fortfarande finns kan ändringar på destinationen blockera dataströmmen eller tvinga fram en återställning som förstör nyare data på destinationen.
Verifiera att källan fortfarande har kedjan med ögonblicksbilder eller bokmärken
Identifiera källdatauppsättningen och de ögonblicksbilder eller bokmärken som kodas i den avbrutna överföringen. Jämför dem med aktuell kvarhållning och eventuella namnändringar eller borttagningar av ögonblicksbilder sedan överföringen stoppades.
FreeBSD:s zfs-send-handbok anger att zfs send -t genererar en dataström från mottagningens återupptagningstoken och knyter den nya dataströmmen till den avbrutna mottagningen, inte till en godtycklig aktuell ögonblicksbild.
Om kvarhållningen har tagit bort den nödvändiga källhistoriken kan token inte återskapa data som inte längre finns. Bevara det återstående partiella tillståndet på destinationen tills du har avgjort om en annan källkopia eller en ny fullständig sändning krävs.
Kontrollera poolfunktioner och strömalternativ i båda systemen
Dokumentera ZFS-versioner, aktiverade poolfunktioner, krypteringsstatus och de ursprungliga strömalternativen, till exempel råa, komprimerade, inbäddade eller sändningar med stora block. Jämför dem efter eventuella programvaru- eller pooluppgraderingar.
Oracles dokumentation om återupptagbar replikering beskriver återupptagning av en avbruten överföring som en samordnad sändnings- och mottagningsåtgärd. Kompatibilitet och den ursprungliga överföringskontexten är därför fortfarande viktiga efter en omstart.
En omstart i sig ändrar inte funktionsflaggor, men en uppgradering som genomfördes under avbrottet kan göra det. Återskapa återupptagningskommandot manuellt med utförliga utdata innan du antar att själva token är skadad.
Verifiera replikerings tjänster och SSH efter att destinationen startat
Bekräfta att destinationspoolen är importerad, att nödvändiga krypterade datauppsättningar är upplåsta, att SSH körs, att replikeringsanvändaren kan köra ZFS-kommandon och att uppgiften startar först när lagringen är klar.
TrueNAS vägledning för fjärrreplikering kräver att SSH och datauppsättningsförutsättningarna på destinationen är tillgängliga efter omstarten. Annars kan automatiseringen misslyckas innan den ens försöker använda den sparade token.
Testa autentisering och en skrivskyddad egenskapsfråga innan du startar den återupptagna dataströmmen. Ett nätverks- eller behörighetsfel kan se ut som ett tokenfel i en övergripande uppgiftslogg.
Återuppta en gång eller avbryt den partiella mottagningen medvetet
Generera en återupptagen dataström med den aktuella token och mata in den i en återupptagbar mottagning på samma destination. Spara hela felutmatningen och undvik att starta parallella replikeringsuppgifter.
ZimaSpace guide för NAS-datamigrering anger en närliggande säkerhetsregel: bevara källan och återställningsvägen tills destinationen har verifierats.
Om token inte kan användas och det partiella tillståndet inte längre är värdefullt, avbryter du det med det stödda kommandot för att avbryta mottagningen först efter att du har bekräftat att en ny fullständig eller inkrementell överföring kan genereras. Ett avbrott frigör det sparade partiella tillståndet och kan inte ångras.
Vanliga frågor
Gör en omstart av destinationen alltid en ZFS-återupptagningstoken ogiltig?
Nej. En sparad partiell mottagning är utformad för att överleva avbrott, inklusive en oplanerad avstängning. Ett fel efter omstarten innebär vanligtvis att uppgiften läser en annan datauppsättning, att det partiella tillståndet rensades, att nödvändig källhistorik ändrades eller att startberoenden saknas.
Kan en ny återupptagningstoken genereras enbart från källan?
Nej. Den ogenomskinliga token kommer från den sparade partiella mottagningen i destinationsdatauppsättningen. Källan använder token för att generera en fortsättningsström, men kan inte återskapa ett borttaget destinationstillstånd på egen hand.
När bör den partiella mottagningen avbrytas?
Avbryt den först när återupptagningsvägen har visat sig vara oanvändbar, källan kan generera en ersättande överföring och det partiella tillståndet på destinationen inte längre behövs för återställning. Bevara loggar och tillgängliga ögonblicksbilder innan du tar bort det.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
