Vad du ska göra när en VM-säkerhetskopiering fastnar på samma procenttal endast i snapshot-läge
En VM-säkerhetskopiering som låser sig vid samma procenttal endast i snapshot-läge tyder först på sökvägen för live-snapshot eller gästfrysning, snarare än på ett fast skadat diskblock.
Den avgörande jämförelsen är snapshot-läge kontra stoppläge med samma VM, mål och ungefärliga datamängd. Om stoppläget upprepade gånger passerar det gamla procenttalet blir den generella diagnosen om ett fast problemområde mindre sannolik, och undersökningen bör i stället fokusera på QEMU Guest Agent-frysning/upptining, applikationskonsistens, lagring med snapshot-stöd och beteendet vid skrivningar i realtid. Behåll en fungerande säkerhetskopia i stoppläge under testerna, så att felsökningen aldrig tar bort den sista återställningsbara kopian.
Verifiera att stoppläget passerar den punkt där snapshot-läget misslyckas
Kör en säkerhetskopiering i stoppläge under ett underhållsfönster till samma mål som används av det felande snapshot-jobbet. Anteckna procenttal, disk, genomströmning och varaktighet vid den punkt där snapshot-läget normalt stannar.
En jämförelse av Proxmox säkerhetskopieringslägen förklarar att snapshot-läget håller VM:ar aktiva, medan stoppläget eliminerar många variabler i gästens körning.
Om stoppläget låser sig vid samma punkt går du tillbaka till den generella artikeln om samma procenttal och tester av käll- eller mållagringen. Om stoppläget slutförs ska de följande experimenten begränsas till den snapshotspecifika sökvägen.
Kontrollera om frysning via QEMU Guest Agent är utlösaren
Granska säkerhetskopieringsloggen efter guest-fsfreeze-freeze, guest-fsfreeze-thaw, tidsgränsöverskridanden eller kommunikationsfel med gästagenten. Jämför tidsstämpeln med gästens journal eller Windows-händelseloggar.
En genomgång av säkerhetskopiering av Windows i Proxmox noterar att gästagenten utför fsfreeze när agenten är aktiverad.
Inaktivera inte funktioner för gästens konsistens permanent som första åtgärd. Använd ett kontrollerat test för att avgöra om själva frysanropet utgör gränsen, och åtgärda därefter samspelet mellan gästagenten och filsystemet.
Leta efter filsystem som inte fryser korrekt
Inventera monterade filsystem inuti gästen, inklusive loop-enheter, nätverksfilsystem, programmonteringar av bind-typ, databaslagring och ovanliga layouter i kontrollpaneler. Notera vilket filsystem som är upptaget när snapshoten startar.
CloudLinux dokumenterar ett fall där fsfreeze kan låsa komplexa gäster, i stället för att själva säkerhetskopieringsmålet är orsaken.
Om borttagning eller korrigering av en problematisk gästmontering gör att snapshot-läget passerar procenttalet ska du återställa skyddet för konsistensen och dokumentera beroendet. Undvik upprepade framtvingade omstarter som kan förvandla ett säkerhetskopieringsproblem till skador på gästens filsystem.
Skilj en tidsgräns vid frysning från ett stopp i dataöverföringen
Kontrollera om säkerhetskopieringen stannar innan någon betydande dataöverföring börjar, direkt efter en frysförfrågan eller senare under blockkopieringen. Ett fast procenttal nära noll kan motsvara ett helt annat felsteg än ett stopp halvvägs genom en virtuell disk.
Ett fall i en kunskapsdatabas för webbhotell visar att frysning kan blockera säkerhetskopieringen på obestämd tid efter att snapshotsekvensen har startat.
Om överföringen aldrig börjar ska du fokusera på konsistensskapande i gästen. Om överföringen fortgår normalt under lång tid innan den stannar ska du i stället jämföra belastningen från live-skrivningar, snapshotlagrets beteende och lagringens fördröjning.
Återskapa gästfrysningen utanför den fullständiga säkerhetskopieringen
Där plattformen och underhållspolicyn tillåter det kan du testa gästagentens frys- och upptiningsbeteende separat eller övervaka gästen noggrant under en manuell snapshot-händelse. Ha en konsol öppen och verifiera att gästen återupptar skrivningar efter upptining.
Ett QEMU-ärende dokumenterar att QEMU fsfreeze kan låsa VM:ar vid vissa filsystemskonfigurationer i gästen.
Om enbart frysningen återskapar låsningen ska du åtgärda den sökvägen i gästen innan du justerar PBS-genomströmningen. Om frysning och upptining fungerar korrekt ska du gå vidare till samspelet mellan snapshotlagring och live-skrivningar.
Behåll stoppläget som återställningsväg tills snapshot-läget fungerar
Offra inte tillförlitliga säkerhetskopior när du felsöker en bekvämlighetsfunktion. Schemalägg säkerhetskopieringar i stoppläge under ett acceptabelt underhållsfönster tills snapshot-läget har slutförts flera gånger och ett återställningstest bekräftar resultatet.
Ett exempel från Server Fault visar en verklig miljö där stoppläget fungerar som reservlösning när live-snapshotbeteendet behöver hanteras separat.
Åtgärden är klar när snapshot-läget upprepade gånger passerar det gamla procenttalet och gästen förblir responsiv före, under och efter säkerhetskopieringen. Den relaterade ZimaSpace-artikeln om generella säkerhetskopieringar som fryser vid samma procenttal är fortfarande rätt överordnade gren om stoppläget också fryser.
Vanliga frågor
Är stoppläget en permanent ersättning för snapshot-läget?
Det kan vara en tillförlitlig reservlösning när driftstopp är acceptabelt, men snapshot-läget är vanligtvis att föredra när gästen kan försättas i ett konsistent tillstånd på ett säkert sätt och live-säkerhetskopieringar slutförs konsekvent.
Bör jag inaktivera QEMU Guest Agent för att få säkerhetskopieringar att fungera?
Endast som ett kontrollerat diagnostiskt test när det är lämpligt. Agenten tillhandahåller även användbara funktioner för avstängning och konsistens, så det underliggande frysproblemet bör identifieras i stället för att döljas.
Varför stannar säkerhetskopieringen vid samma procenttal om problemet är fsfreeze?
Procenttal för förloppet kan motsvara återkommande faser i säkerhetskopieringen, inte bara diskpositioner. En frysning eller övergång till snapshot som nås vid samma steg kan därför ge samma synliga procenttal.
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.
