Varför är en inkrementell säkerhetskopia nästan lika stor som en fullständig säkerhetskopia?
En inkrementell backup kan bli nästan lika stor som en full backup när källan verkligen skriver om många block, backupmotorn förlorar sin tidigare ändringsbaslinje, det skyddade området ändras eller siffran du läser är arkivets tillväxt snarare än den aktuella inkrementella mängden. Diagnostisera dessa möjligheter separat innan du tar bort återställningspunkter, återställer jobbet eller startar en ny full backup.
Identifiera först vilken siffra som verkar för stor
”Den inkrementella är fullstor” kan beskriva fyra olika mätningar. De är inte utbytbara och pekar på olika orsaker.
| Mätning | Vad det betyder | Vad ett stort värde antyder |
|---|---|---|
| Skannade källbyte | Data lästa för att upptäcka ändringar | Motorn kan behöva inspektera hela filer även om den bara laddar upp ändrade delar |
| Överförda byte | Ny data skickad till destinationen | Många block ändrades, baslinjen förlorades eller deduplicering matchade inte |
| Inkrementell filstorlek | Ny återställningspunktdata som skrevs av denna körning | Jobbet fångade en verkligt stor skillnad eller fungerade som en ny baslinje |
| Total tillväxt i arkivet | Nettolagring tillagd efter sammanslagningar, retention, metadata och syntetiska operationer | Backupkedjans design eller städschema kan vara den verkliga orsaken |
Registrera alla fyra siffror för en körning. Ett jobb som skannar 8 TB men överför 12 GB beter sig mycket annorlunda än ett som överför och skriver 7 TB.
Bekräfta om arbetsbelastningen verkligen förändrades så mycket
Volymnivå-backupprogramvara skyddar ändrade lagringsblock, inte den användarvisade storleken på redigerade dokument. En liten ändring kan påverka ett större block, och aktiva tjänster modifierar kontinuerligt loggar, index, databaser, cacheminnen och operativsystemfiler. En nyligen administratörsdiskussion förklarar varför en ändrad byte kan göra det innehållande backupblocket till en del av nästa inkrement.
Kontrollera om den stora körningen följde efter något av dessa händelser:
- Databasunderhåll, komprimering, omindexering eller tillväxt av transaktionsloggar
- Uppdateringar av virtuella maskiner, swap-aktivitet, antivirusgenomsökningar eller gästdiskdefragmentering
- Medietranskodning, omindexering av fotobibliotek, miniatyrgenerering eller metadataomskrivningar
- Stora arkiv, krypterade behållare, brevlådor eller diskavbildningsfiler som skrivs om på plats
- Filsystembalans, poolutvidgning, blockflyttning eller snapshot-konsolidering
Jämför backupfönstret med applikationsloggar och lagringsskrivningsdiagram. Om källskrivningarna ökade samtidigt kan backupen rapportera en verklig skillnad snarare än ett backupfel.
Kontrollera om ändringsspårningen har förlorat sin baslinje
Blockspårningssystem jämför det aktuella tillståndet med ett känt tidigare ändrings-ID. En snapshot-återställning, spårningsåterställning, ogiltig ändringskarta, värdmigrering, misslyckad tidigare session eller återställning av backup-jobb kan bryta den relationen. Nästa körning kan då läsa eller skydda hela källan för att etablera en säker baslinje. En praktisk CBT-återställningsgenomgång noterar att återställning av ändringsspårning kan kräva en ny aktiv fullständig backup innan normala inkrementella återupptas.
Sök efter loggtermer som CBT återställning, ändrings-ID ogiltigt, journal omsluten, baslinje saknas, ny kedja, eller fullständig skanning krävs. Återställ inte spårning upprepade gånger utan att bevara loggarna; upprepade återställningar kan dölja den ursprungliga orsaken och leda till upprepade fullstora körningar.
Verifiera att backupens omfattning och källidentitet inte har ändrats
Ett jobb kan fortfarande märkas som inkrementellt medan det skyddar en annan källa än tidigare. En ny montering under en inkluderad sökväg, en filsystemsomformatering, en ändrad enhetsidentifierare, ett annat värdnamn, en ny delningsväg eller en utökad inkluderingsregel kan få motorn att bygga nya interna strukturer. Community-felsökning visar att ytterligare volymer och monteringspunkter kan dras in i ett jobb som verkar oförändrat.
Exportera föregående och aktuella jobbdefinitioner och jämför:
- Skyddade rötter, monteringar, delningar, dataset och virtuella diskar
- Värd-, volym- och filsystemidentifierare
- Inkluderings- och exkluderingsmönster
- Snapshot-leverantör och konsistensläge
- Krypterings-, kompressions- och dedupliceringsinställningar
Om källan har utökats avsiktligt kan en fullstor inkrementell förväntas. Om varje senare körning förblir stor, fortsätt diagnosen.
Bestäm om backupens granularitet passar filerna
Filnivå-, blocknivå- och innehållsdefinierade chunking-motorer reagerar olika på redigeringar, namnändringar och omskrivningar. Ett block-deduplicerande system kan bara registrera metadata när en mapp flyttas; en enklare filnivåmotor kan behandla den flyttade sökvägen som en borttagen fil plus en ny fil. I ett blockbaserat exempel ändrar en namnändring av en katalog sökvägsmetadata utan att ladda upp alla oförändrade datablock på nytt.
Stora föränderliga filer kräver särskild uppmärksamhet. En databas, VM-avbild, krypterad valv eller monolitisk arkivfil kan läsas helt för att upptäcka små interna förändringar, och mängden som slutligen lagras beror på chunkgränser och deduplicering. En diskussion om stora databaser beskriver hur en multi-gigabyte databasfil kan läsas helt även när endast ändrade chunkar överförs.
Om applikationen tillhandahåller en konsekvent export, transaktionsloggbackup eller applikationsmedveten backupmetod, jämför det arbetsflödet med att säkerhetskopiera den levande monolitiska filen.
Separera ett stort inkrement från syntetisk full och behållningsaktivitet.
En syntetisk full backup sätts ihop i lagringen från en tidigare full backup plus senare inkrementella. Den kan skapa ett fullstort återställningsobjekt utan att läsa hela källan igen. En översikt över backuptyper förklarar att syntetiska fulla backuper byggs från den befintliga fulla och inkrementella kedjan.
Lagringsutvecklingen kan också förbli hög när gamla återställningspunkter är låsta, rensning inte har körts, borttagna snapshots fortfarande refererar till chunkar eller en sammanslagning tillfälligt behöver arbetsutrymme. Kontrollera jobbets tidslinje istället för att bedöma en enda kataloglista:
| Observerat mönster. | Trolig tolkning. | Nästa kontroll. |
|---|---|---|
| Nätverksöverföring är liten, lagringsskrivning är stor. | Syntetisk full, sammanslagning eller ompaketering. | Logg för lagringsuppgift. |
| Inkrementfilen är liten, total användning fortsätter att öka. | Behållning, oföränderlighet, snapshots eller fördröjd rensning. | Äldsta behållna punkt och återvinningsschema. |
| Överförda och skrivna byte närmar sig båda full storlek. | Verklig förändring, förlorad baslinje eller ändrad omfattning. | Källaktivitet och spårningsloggar. |
| Endast den första körningen efter en förändring är stor. | Ny baslinje eller övergång i källlayout. | Nästa två inkrementella körningar. |
Kör ett test med en variabel innan backupkedjan byggs om.
- Spara den aktuella jobbkonfigurationen, detaljerade loggar, lista över återställningspunkter och lagringskapacitet.
- Välj ett tyst testfönster och pausa kända applikationer med hög skrivaktivitet om det är säkert att göra det.
- Skapa en liten testfil, ändra den en gång och kör samma inkrementella jobb utan att ändra några inställningar.
- Registrera skannade, överförda, skrivna, deduplicerade och behållna byte.
- Kör en andra inkrementell utan källändringar.
Om båda kontrollerade körningarna förblir fullstora, fokusera på spårning, källidentitet eller konfiguration av jobbkedjan. Om de blir små, återställ normala arbetsbelastningar en i taget tills förändringstakten återvänder. Detta skiljer backup-motorns beteende från applikationsförändringar.
Matcha åtgärden till orsaken
| Bekräftad orsak | Korrigerande åtgärd | Förväntat resultat |
|---|---|---|
| Hög verklig skrivhastighet | Minska omfattningen av temporära filer, använd app-medvetna exporter eller schemalägg efter underhåll | Inkrementstorlek följer meningsfulla dataändringar |
| Spårningsbaslinje förlorad | Reparera spårning en gång, skapa nödvändig baslinje och verifiera sedan senare inkrement | En stor körning följd av mindre deltas |
| Omfattning utökad | Bekräfta att den nya datan är avsedd eller dela upp den i ett separat jobb | Förutsägbar tillväxt kopplad till den tillagda källan |
| Stora föränderliga filer | Använd applikationskonsistenta dumpningar eller en chunk-medveten backupmetod | Mindre onödig ombearbetning och säkrare återställningar |
| Retention eller syntetiska operationer | Justera kapacitetsplanering, beskärningstidpunkt eller policy för återställningspunkter | Arkivets tillväxt matchar den avsedda historiken |
När du dimensionerar destinationen, kom ihåg att versionshistorik och retention kan göra ett arkiv större än den aktiva källan. Samma skillnad behandlas i ZimaSpace-guiden för planering av NAS-kapacitet för versioner och backup-historik.
Stoppa och trappa upp när varje körning skapar en ny baslinje
Trappa upp innan du raderar kedjan när loggar visar upprepade ogiltigförklaringar av baslinjen, källidentifierare ändras oväntat, återställningspunkter försvinner, arkivmetadata rapporterar korruption eller ett test utan ändring ändå skriver nästan hela källan. Behåll aktuella återställningspunkter tills minst en representativ återställning har testats. Att återskapa jobbet kan dölja bevis och ta bort den enda återställningsbara historiken.
Vanliga frågor
Kan flyttning eller namnbyte av en stor mapp orsaka en fullstor inkrementell backup?
Det beror på backup-motorn. Verktyg som deduplicerar innehåll eller block kan återanvända befintlig data och lagra mest metadata om sökvägar, medan filnivåverktyg kan behandla flyttade filer som nya objekt. Testa exakt produkt med en representativ mapp innan du omorganiserar en stor datamängd.
Betyder en syntetisk full att NAS:en laddade upp hela källan igen?
Inte nödvändigtvis. En syntetisk full backup sätts ofta ihop av data som redan finns i arkivet. Jämför källavläsnings- och nätverksöverföringsräknare med arkivskrivningsräknare för att se var arbetet skedde.
Varför kan en liten databasändring skapa en stor inkrementell backup?
Applikationen kan skriva om många lagringsblock, komprimera databasen, rotera loggar eller ändra chunk-gränser även när den synliga ändringen i posten är liten. Använd en applikationskonsistent backup eller export och jämför dess delta med den aktiva databasen.
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.
