Så verifierar du att ZFS-replikering kan återupptas efter en avbruten överföring

Ja, när mottagarsidan bevarar en giltig återupptagningstoken och de källögonblicksbilder som krävs för token fortfarande finns.

Beslutet är viktigt när en rå eller inkrementell zfs send avbryts på grund av ett nätverks- eller destinationsavbrott. De två konkurrerande tillstånden är giltig token för återupptagning av mottagning och saknad token eller förstörd källögonblicksbild. Börja med en sparad konfiguration och kasserbara data, observera en gren i taget och stoppa om testet ökar risken för dataförlust, behörighetsproblem eller otillgänglighet.

Definiera villkoren bakom beslutet om återupptagbar ZFS-replikering

Dokumentera miljön innan du ändrar något: programvaru- och firmwareversioner, enhetsidentiteter, monterings- eller nätverkssökväg, ledigt utrymme, behörigheter och det observerbara symptomet. Baslinjen måste bevara tillräckligt med detaljer för att återskapa situationen där en rå eller inkrementell zfs send avbryts på grund av ett nätverks- eller destinationsavbrott.

Den första kandidaten är en giltig token för återupptagning av mottagning. Den andra är en saknad token eller en förstörd källögonblicksbild. Den aktuella återupptagbara zfs send definierar den mekanism eller kommandogräns som används i testet; den ersätter inte observationer från just denna hemserver.

Skriv ned godkännandevillkoret och stoppvillkoret innan du kör skiljetestet. Ett godkänt resultat måste ändra de bevis som förutsägs av den ena grenen samtidigt som orelaterade tjänster förblir oförändrade; ett underkänt resultat måste återställa systemet till det sparade tillståndet i stället för att utlösa en kedja av spekulativa korrigeringar.

Testa påståendet utan att sänka det ursprungliga kravet

Använd detta skiljetest: avbryt en kasserbar replikering, läs token, generera en återupptagen dataström och jämför den slutliga ögonblicksbilden på destinationen. Håll arbetsbelastning, klient, sökväg, filuppsättning och tidsinställning konstanta så att resultatet kan kopplas till den ändrade variabeln.

Använd ZFS send och receive för att välja det fält som faktiskt kan skilja grenarna åt och samla sedan in dess tidsstämpel, avslutningsstatus, feltext, enhets- eller ögonblicksbildsidentitet, fördröjning, överförda byte, behörigheter och återställningstillstånd. Ett felfritt kommandoavslut räcker inte när identitet, beständighet eller applikationstillstånd är det som testas.

Upprepa testet en gång efter en omstart, återanslutning, ommontering eller cache utan innehåll när en sådan händelse ingår i det ursprungliga villkoret. Om den första körningen är destruktiv eller miljön inte kan återställas, stoppa och återskapa testet på en kasserbar kopia i stället.

token=$(zfs get -H -o value receive_resume_token pool/dst)
zfs send -t "$token" | ssh nas zfs receive pool/dst

Tolka godkända, underkända och avvikande resultat

GODKÄNT: återupptagningsströmmen slutförs och källans och destinationens ögonblicksbilder delar den förväntade GUID-linjen. Dokumentera den exakta versionen, identiteten och arbetsbelastningen som godkändes så att slutsatsen förblir villkorad i stället för att bli ett universellt påstående.

UNDERKÄNT: ingen token finns, destinationen återställdes eller nödvändiga källögonblicksbilder togs bort. Ett underkänt resultat bevisar inte automatiskt den motsatta grenen när nätverk, minne, behörigheter eller källans konsekvens kan påverka båda; isolera dessa gemensamma beroenden innan du eskalerar.

UNDANTAG ELLER OTYDLIGT RESULTAT: avbryt den partiella mottagningen först efter att du har avgjort att kostnaden för en omstart är acceptabel. Bevara loggarna och kör inte reparations-, rensnings-, förstörings-, ompartitionerings- eller rekursiva ägarskapskommandon förrän det finns en återställningsbar kopia.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Bekräfta beslutet under den ursprungliga arbetsbelastningen

Tillämpa den åtgärd som motsvarar den observerade grenen och upprepa sedan det ursprungliga villkoret i stället för en förenklad ersättning. Beslutet gäller endast när återupptagningsströmmen slutförs och källans och destinationens ögonblicksbilder delar den förväntade GUID-linjen under två cykler eller den relevanta omstarten, viloläget, avbrottet eller belastningsövergången.

Använd de oföränderliga säkerhetskopieringsfönstren för att kontrollera det närmaste beroende arbetsflödet, men behåll den ursprungliga utlösaren oförändrad. Orelaterade datauppsättningar, delningar, containrar, användare och återställningspunkter måste behålla sin tidigare åtkomst och tidsåtgång.

Stoppgränsen är tydlig: om ingen token finns, destinationen återställdes eller nödvändiga källögonblicksbilder togs bort, återgå till den senast verifierade konfigurationen, behåll bevisen och eskalera till ett djupare plattforms- eller hårdvarutest endast när grenen kan upprepas.

När målresultatet har uppnåtts jämför du det med layouten för det lokala arkivet så att korrigeringen inte flyttar risken till en närliggande tjänst. Ett lyckat måltest med ett nytt fel för säkerhetskopiering, identitet, tidsgräns eller tillgänglighet är fortfarande en misslyckad ändring.

Vanliga frågor

För återupptagbar ZFS-replikering gäller de återstående sökningarna vanligtvis om varje avbruten mottagning skapar en token, om gamla källögonblicksbilder kan tas bort efter ett avbrott och hur den slutliga replikan verifieras. Svaren nedan håller dessa specialfall åtskilda från huvudbeslutet.

Godkännandegränsen flyttas inte: återupptagningsströmmen slutförs och källans och destinationens ögonblicksbilder delar den förväntade GUID-linjen. Om ett efterföljande villkor ändrar filsystemet, identiteten, nätverkssökvägen eller applikationsversionen upprepar du endast det skiljetest som påverkas av ändringen.

Sluta bredda experimentet när ingen token finns, destinationen återställdes eller nödvändiga källögonblicksbilder togs bort. Då ska du avbryta den partiella mottagningen först efter att du har avgjort att kostnaden för en omstart är acceptabel; bevara bevisen innan du eskalerar till plattforms-, lagrings- eller hårdvaruansvarig.

Skapar varje avbruten mottagning en token?

Nej. Mottagningen måste använda återupptagningsbart beteende och misslyckas i ett tillstånd som bevarar en token.

Kan gamla källögonblicksbilder tas bort efter ett avbrott?

Inte förrän den återupptagna strömmen inte längre är beroende av dem och destinationen har verifierats.

Hur verifierar man den slutliga replikan?

Jämför ögonblicksbildernas GUID-linje, egenskaper, förväntade filer och ett återställningsprov - inte bara kommandots avslutningsstatus.

För återupptagbar ZFS-replikering är det praktiska svaret fortfarande villkorat: återupptagningsströmmen slutförs och källans och destinationens ögonblicksbilder delar den förväntade GUID-linjen. När ingen token finns, destinationen återställdes eller nödvändiga källögonblicksbilder togs bort, ska du avbryta den partiella mottagningen först efter att du har avgjort att kostnaden för en omstart är acceptabel; en partiell framgång som inte klarar den ursprungliga arbetsbelastningen är inte kompatibilitet.