Waarom is een incrementele back-up bijna net zo groot als een volledige back-up?
Een incrementele back-up kan bijna zo groot worden als een volledige back-up wanneer de bron daadwerkelijk veel blokken herschrijft, de back-upengine zijn vorige wijzigingsbasislijn verliest, de beschermde scope verandert, of het getal dat u leest repository-groei is in plaats van de huidige incrementele payload. Diagnoseer die mogelijkheden afzonderlijk voordat u herstelpunten verwijdert, de taak reset of een nieuwe volledige back-up start.
Identificeer eerst welk getal te groot lijkt
“De incrementele is volwaardig” kan vier verschillende metingen beschrijven. Ze zijn niet uitwisselbaar en wijzen elk op een andere oorzaak.
| Metingen | Wat het betekent | Wat een grote waarde suggereert |
|---|---|---|
| Bronbytes gescand | Gegevens gelezen om wijzigingen te detecteren | De engine moet mogelijk hele bestanden inspecteren, zelfs als hij alleen gewijzigde delen uploadt |
| Overgedragen bytes | Nieuwe gegevens naar de bestemming verzonden | Veel blokken gewijzigd, de basislijn ging verloren, of deduplicatie kwam niet overeen |
| Incrementele bestandsgrootte | Nieuwe herstelpuntgegevens geschreven door deze run | De taak heeft een echt grote delta vastgelegd of gedroeg zich als een nieuwe basislijn |
| Totale groei van de repository | Netto opslag toegevoegd na merges, retentie, metadata en synthetische bewerkingen | Het ontwerp van de back-upketen of het opruimschema kan de werkelijke oorzaak zijn |
Noteer alle vier de cijfers voor één run. Een taak die 8 TB scant maar 12 GB overdraagt, gedraagt zich heel anders dan een die 7 TB overdraagt en schrijft.
Bevestig of de workload echt zo veel is veranderd
Volume-niveau back-upsoftware beschermt gewijzigde opslagblokken, niet de voor de gebruiker zichtbare grootte van bewerkte documenten. Een kleine wijziging kan een groter blok veranderen, en drukke services wijzigen continu logs, indexen, databases, caches en besturingssysteem bestanden. Een recente discussie onder beheerders legt uit waarom één gewijzigd byte het bijbehorende back-upblok onderdeel kan maken van de volgende increment.
Controleer of de grote run een van deze gebeurtenissen volgde:
- Databaseonderhoud, compactie, herindexering of groei van transactielogboeken
- Updates van virtuele machines, swap-activiteit, antivirus-scans of gastdefragmentatie
- Media-transcodering, foto-bibliotheekherindexering, miniatuurweergave regeneratie of metadata herschrijvingen
- Grote archief-, versleutelde container-, mailbox- of schijfimagebestanden die ter plaatse worden herschreven
- Bestandssysteembalans, pooluitbreiding, blokverplaatsing of snapshotconsolidatie
Vergelijk het back-upvenster met applicatielogs en opslag-schrijfgrafieken. Als de bron tegelijkertijd meer schrijft, kan de back-up een echte delta rapporteren in plaats van een back-upfout.
Controleer of Change Tracking zijn basislijn is verloren
Blok-tracking systemen vergelijken de huidige staat met een bekende vorige wijzigings-ID. Een snapshot revert, tracking reset, ongeldige wijzigingskaart, hostmigratie, mislukte vorige sessie of het opnieuw aanmaken van een back-uptaak kan die relatie verbreken. De volgende run kan dan de hele bron lezen of beschermen om een veilige baseline vast te stellen. Een praktische CBT-herstelhandleiding vermeldt dat het resetten van wijzigingstracking een nieuwe actieve volledige back-up kan vereisen voordat normale incrementele back-ups hervatten.
Zoek naar logtermen zoals CBT gereset, wijzigings-ID ongeldig, journal gewrapt, baseline ontbreekt, nieuwe keten, of volledige scan vereist. Reset de tracking niet herhaaldelijk zonder de logs te bewaren; herhaalde resets kunnen de oorspronkelijke trigger verbergen en herhaalde volledige runs veroorzaken.
Controleer of de back-up scope en bronidentiteit niet zijn veranderd
Een taak kan nog steeds als incrementeel worden gelabeld terwijl een andere bron wordt beschermd dan voorheen. Een nieuwe mount onder een opgenomen pad, een bestandssysteemresize, een gewijzigd apparaat-ID, een andere hostnaam, een nieuw sharepad of een uitgebreid inclusieregel kan de engine nieuwe interne structuren laten bouwen. Community-troubleshooting toont aan dat extra volumes en mountpunten kunnen worden toegevoegd aan een taak die ongewijzigd lijkt.
Exporteer de vorige en huidige taakdefinities en vergelijk:
- Beschermde roots, mounts, shares, datasets en virtuele schijven
- Host-, volume- en bestandssysteemidentificaties
- Inclusie- en exclusiepatronen
- Snapshot-provider en consistentiemodus
- Encryptie-, compressie- en deduplicatie-instellingen
Als de bron opzettelijk is uitgebreid, kan één volledige incrementele back-up worden verwacht. Als elke volgende run groot blijft, ga dan door met de diagnose.
Bepaal of de back-up granulariteit bij de bestanden past
Bestandsniveau-, blokniveau- en inhoud-gedefinieerde chunking-engines reageren verschillend op bewerkingen, hernoemingen en herschrijvingen. Een blok-deduplicatiesysteem kan alleen metadata registreren wanneer een map wordt verplaatst; een eenvoudigere engine op bestandsniveau kan het verplaatste pad behandelen als een verwijderd bestand plus een nieuw bestand. In een voorbeeld op blokbasis verandert het hernoemen van een directory de padmetadata zonder alle ongewijzigde databestanden opnieuw te uploaden.
Grote wijzigbare bestanden vereisen speciale aandacht. Een database, VM-image, versleutelde kluis of monolithisch archief kan volledig worden gelezen om kleine interne wijzigingen te ontdekken, en de uiteindelijk opgeslagen hoeveelheid hangt af van chunk-grenzen en deduplicatie. Een discussie over grote databases beschrijft hoe een multi-gigabyte databasebestand volledig kan worden gelezen, zelfs als alleen gewijzigde chunks worden overgedragen.
Als de applicatie een consistente export, transactie-log backup of applicatiebewuste backupmethode biedt, vergelijk dan die workflow met het back-uppen van het live monolithische bestand.
Scheiding van een grote incrementele backup van synthetische volledige en bewaaractiviteiten.
Een synthetische volledige backup wordt binnen de repository samengesteld uit een eerdere volledige plus latere incrementele backups. Het kan een volledig herstelobject creëren zonder de hele bron opnieuw te lezen. Een overzicht van backuptypen legt uit dat synthetische volledige backups worden opgebouwd uit de bestaande volledige en incrementele keten.
De groei van de repository kan ook hoog blijven wanneer oude herstelpunten vergrendeld blijven, opschoning niet heeft plaatsgevonden, verwijderde snapshots nog steeds chunks refereren, of een samenvoeging tijdelijk werkruimte nodig heeft. Controleer de taak-tijdlijn in plaats van één directorylijst te beoordelen:
| Waargenomen patroon. | Waarschijnlijke interpretatie. | Volgende controle. |
|---|---|---|
| Netwerkoverdracht is klein, repository schrijven is groot. | Synthetische volledige backup, samenvoegen of herverpakken. | Repository taaklog. |
| Incrementeel bestand is klein, totaal gebruik blijft stijgen. | Bewaring, onveranderlijkheid, snapshots of vertraagde opschoning. | Oudste bewaarde punt en herwinningsschema. |
| Overgedragen en geschreven bytes naderen beide de volledige grootte. | Echte veranderingen, verloren basislijn of gewijzigde scope. | Bronactiviteit en trackinglogs. |
| Alleen de eerste run na een wijziging is groot. | Nieuwe basislijn of overgang in bronindeling. | Volgende twee incrementele runs. |
Voer een test met één variabele uit voordat u de backupketen opnieuw opbouwt.
- Sla de huidige taakconfiguratie, gedetailleerde logs, lijst met herstelpunten en opslagcapaciteit op.
- Kies een rustig testvenster en pauzeer bekende applicaties met veel schrijfacties als dat veilig is.
- Maak één klein testbestand, wijzig het één keer en voer dezelfde incrementele taak uit zonder instellingen te veranderen.
- Registreer gescande, overgedragen, geschreven, gededupliceerde en bewaarde bytes.
- Voer een tweede incrementele backup uit zonder bronwijzigingen.
Als beide gecontroleerde runs volledig van formaat blijven, richt u zich dan op tracking, bronidentiteit of configuratie van de taakketen. Als ze klein worden, herstel dan normale workloads één voor één totdat het wijzigingspercentage terugkeert. Dit scheidt het gedrag van de backup-engine van applicatieveranderingen.
Pas de oplossing aan op de oorzaak
| Bevestigde oorzaak | Corrigerende actie | Verwacht resultaat |
|---|---|---|
| Hoge werkelijke schrijfsnelheid | Beperk de scope van tijdelijke bestanden, gebruik app-bewuste exports of plan na onderhoud | Incrementele grootte volgt betekenisvolle gegevenswijzigingen |
| Tracking-baseline verloren | Hersteltracking één keer uitvoeren, de vereiste baseline creëren en daarna latere incrementele back-ups verifiëren | Eén grote uitvoering gevolgd door kleinere deltas |
| Uitgebreide scope | Bevestig dat de nieuwe gegevens bedoeld zijn of splits ze op in een aparte taak | Voorspelbare groei gekoppeld aan de toegevoegde bron |
| Grote wijzigbare bestanden | Gebruik applicatie-consistente dumps of een chunk-bewuste back-upmethode | Minder onnodige herverwerking en veiligere herstelacties |
| Retentie- of synthetische bewerkingen | Pas capaciteitsplanning, snoeitiming of herstelpuntbeleid aan | Groei van de repository komt overeen met de bedoelde geschiedenis |
Houd bij het bepalen van de grootte van de bestemming rekening met het feit dat versiegeschiedenis en retentie een repository groter kunnen maken dan de actieve bron. Hetzelfde onderscheid wordt behandeld in de ZimaSpace-gids voor planning van NAS-capaciteit voor versies en back-upgeschiedenis.
Stop en Escaleer Wanneer Elke Uitvoering een Nieuwe Baseline Creëert
Escaleer voordat je de keten verwijdert wanneer de logs herhaalde baseline-invalidatie tonen, bronidentificaties onverwacht veranderen, herstelpunten verdwijnen, repository-metadata corruptie meldt, of een test zonder wijzigingen bijna de hele bron blijft schrijven. Bewaar de huidige herstelpunten totdat ten minste één representatief herstel is getest. Het opnieuw aanmaken van de taak kan het bewijs verbergen en de enige herstelbare geschiedenis verwijderen.
Veelgestelde vragen
Kan het verplaatsen of hernoemen van een grote map een incrementele back-up van volledige grootte veroorzaken?
Dat hangt af van de back-upengine. Tools die inhoud- of blokdeduplicatie toepassen, kunnen de bestaande gegevens hergebruiken en vooral padmetadata opslaan, terwijl tools op bestandsniveau de verplaatste bestanden als nieuwe objecten kunnen behandelen. Test het exacte product met een representatieve map voordat je een grote dataset herstructureert.
Betekent een synthetische volledige back-up dat de NAS de hele bron opnieuw heeft geüpload?
Niet per se. Een synthetische volledige back-up wordt vaak samengesteld uit gegevens die al in de repository staan. Vergelijk de bron-lees- en netwerkoverdrachtscounters met de repository-schrijfcounters om te zien waar het werk heeft plaatsgevonden.
Waarom kan een kleine databasebewerking een grote incrementele back-up veroorzaken?
De applicatie kan veel opslagblokken herschrijven, de database comprimeren, logs roteren of chunk-grenzen wijzigen, zelfs als de zichtbare wijziging in het record klein is. Gebruik een applicatie-consistente back-up of export en vergelijk het verschil met het live databasebestand.
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...
