Waarom loopt een VM-back-up elke nacht bij hetzelfde percentage vast?
Een VM-back-up die elke nacht bij hetzelfde percentage vastloopt, bereikt meestal dezelfde bronregio of back-upfase. Daardoor wordt het percentage een herhaalbare diagnostische aanwijzing.
Noteer op het moment van vastlopen de exacte VM-schijf, fase, logmelding, doorvoersnelheid en status van de bestemming. Vergelijk vervolgens een andere datastore, controleer de bronopslag rond die regio, scheid hooks voor het stilzetten van de gast van de bulkoverdracht en controleer nachtelijke belasting. Beschouw een stabiel percentage niet als bewijs dat het netwerk faalt.
Gebruik het percentage als een herhaalbare locatieaanduiding
Noteer gedurende meerdere nachten het exacte percentage, de verstreken tijd, de huidige VM-schijf, de back-upfase, de overdrachtssnelheid en de laatste logregel. Het percentage geeft aan waar de taak zich bevindt, maar vormt op zichzelf geen diagnose.
Uit werk rond het afstellen van PBS-prestatieknelpunten blijkt dat knelpunten kunnen verschuiven tussen bronlezingen, hashing, compressie, netwerkoverdracht en datastorebewerkingen. Breng de vastloper daarom eerst in verband met een fase voordat je willekeurige instellingen wijzigt.
Als dezelfde VM en fase bij elke uitvoering vrijwel op hetzelfde punt stoppen, geef dan prioriteit aan deterministische brongegevens of een herhaalbare workflowstap boven algemene netwerkcongestie.
Vergelijk het back-updoel met een andere bestemming
Maak dezelfde VM-back-up naar een andere datastore of een tijdelijke lokale bestemming als de capaciteit en het herstelbeleid dat toestaan. Houd de snapshotmodus en VM-belasting vergelijkbaar.
Een veelgebruikt opslagpad voor Proxmox-back-ups bevat NFS- of NAS-opslag. Latentie of vergrendeling op de bestemming kan ervoor zorgen dat één bestemming vastloopt terwijl de VM zelf goed blijft functioneren.
Als de alternatieve bestemming voorbij het eerdere vastlooppunt komt, onderzoek dan de oorspronkelijke datastore, het bestandssysteem, het netwerkpad en de beschikbare ruimte. Als beide bestemmingen op identieke wijze vastlopen, richt je onderzoek dan weer op de bron of de back-upfase.
Controleer de bronschijf rond het herhaalbare gebied
Controleer logboeken van de hostopslag, SMART-gegevens, ZFS- of bestandssysteemfouten en leeslatentie terwijl de back-up het probleemgebied nadert. Een back-up kan de eerste taak zijn die elk koud blok leest.
Werkelijke meldingen over langdurige PBS-back-upknelpunten laten zien waarom een lange back-up door één knelpunt kan worden gedomineerd, in plaats van door de nominale omvang van de VM.
Een herhaalbare leesfout, time-out of latentiespiek op hetzelfde punt betekent dat je het incident als een gegevensbehoudsprobleem moet behandelen. Vermijd herhaalde volledige leesbewerkingen als de bronschijf achteruitgaat.
Scheid het stilzetten van de gast van de gegevensoverdracht
Noteer of de back-up vastloopt tijdens het stilzetten via de gastagent, het maken van de snapshot, de voorbereiding van metagegevens of nadat de bulkgegevensoverdracht al is gestart. Test een back-up tijdens een onderhoudsvenster met minimale belasting van de gast.
Bij een algemene Proxmox-back-upworkflow worden back-uporkestratie en opslagoverdracht van elkaar gescheiden. Dat is nuttig wanneer een hook voor een applicatieconsistente bevriezing blijft hangen, terwijl schijf- en netwerkdoorvoer normaal zijn.
Als het uitschakelen van een niet-essentiële hook voor het stilzetten van de gast ervoor zorgt dat de taak doorgaat, herstel dan die hook of de gastagent voordat je de optie voor consistentie opnieuw inschakelt. Laat belangrijke databases niet zonder stilzetting werken zonder een alternatief herstelplan.
Plan de taak buiten concurrerende nachtelijke werkzaamheden
Vergelijk het tijdstip van vastlopen met scrubs, replicatie, mediascans, snapshots, deduplicatie- of cloud-synchronisatietaken. Verplaats tijdelijk slechts één concurrerende taak om de belasting te testen.
Een dieper inzicht in de PBS-architectuur en het afstellen ervan is nuttig wanneer meerdere bronnen hetzelfde nachtelijke tijdvenster delen en het back-uppercentage slechts aangeeft waar die belasting zichtbaar wordt.
Het probleem is opgelost wanneer de back-up herhaaldelijk voorbij het oude vastlooppunt komt en wordt voltooid met een bruikbaar herstelpunt. De gerelateerde ZimaSpace-gids over gereedheid van VM-back-ups voegt de herstelgrens toe. Neem één testherstel op in het validatieplan in plaats van te vertrouwen op een voortgangsindicator van 100 procent.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Kan Plex een GPU delen met een andere Docker-container?
Plex en een andere container kunnen vaak dezelfde GPU gebruiken, maar je moet de driverondersteuning, apparaattoewijzing, belasting van de video-engine, het geheugengebruik en het...
Hoe je kunt bepalen of een Plex-fout door de client of de server wordt veroorzaakt
Reproduceer hetzelfde item op een andere client, vergelijk het sessiepad en verzamel pas serverbewijs nadat de scope heeft uitgewezen waar de fout daadwerkelijk zit.
Plex-cache en tijdelijke opslag voor transcodering configureren
Bescherm de permanente Plex-status door tijdelijke transcodebestanden op geschikte lokale opslag te plaatsen en controleer vervolgens het opruimen, de beschikbare ruimte en het gedrag...
