Perché un backup incrementale è quasi grande quanto un backup completo?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Why Is an Incremental Backup Almost as Large as a Full Backup? - Zima Store Online

Un backup incrementale può diventare quasi grande quanto un backup completo quando la sorgente riscrive realmente molti blocchi, il motore di backup perde la sua baseline di cambiamento precedente, l’ambito protetto cambia o il numero che stai leggendo è la crescita del repository piuttosto che il payload incrementale corrente. Diagnostica queste possibilità separatamente prima di eliminare punti di ripristino, resettare il lavoro o avviare un nuovo backup completo.

Identifica prima quale numero sembra troppo grande

“L’incrementale è a dimensione piena” può descrivere quattro misurazioni diverse. Non sono intercambiabili e ognuna indica una causa differente.

Misurazione	Cosa significa	Cosa suggerisce un valore elevato
Byte della sorgente scansionati	Dati letti per rilevare le modifiche	Il motore potrebbe dover ispezionare file interi anche se carica solo i chunk modificati
Byte trasferiti	Nuovi dati inviati alla destinazione	Molti blocchi modificati, la baseline è stata persa o la deduplicazione non ha corrisposto
Dimensione del file incrementale	Nuovi dati del punto di ripristino scritti da questa esecuzione	Il lavoro ha catturato un delta realmente grande o si è comportato come una nuova baseline
Crescita totale del repository	Storage netto aggiunto dopo fusioni, retention, metadati e operazioni sintetiche	Il design della catena di backup o il programma di pulizia potrebbero essere la vera causa

Registra tutti e quattro i numeri per una singola esecuzione. Un lavoro che scansiona 8 TB ma trasferisce 12 GB si comporta in modo molto diverso da uno che trasferisce e scrive 7 TB.

Conferma se il carico di lavoro è realmente cambiato così tanto

Il software di backup a livello di volume protegge i blocchi di storage modificati, non la dimensione visibile all'utente dei documenti modificati. Una piccola modifica può alterare un blocco più grande, e i servizi attivi modificano continuamente log, indici, database, cache e file del sistema operativo. Una recente discussione tra amministratori spiega perché un byte modificato può rendere il blocco di backup contenente parte del prossimo incremento.

Verifica se la grande esecuzione ha seguito uno di questi eventi:

Manutenzione del database, compattazione, reindicizzazione o crescita del log delle transazioni
Aggiornamenti della macchina virtuale, attività di swap, scansioni antivirus o deframmentazione degli ospiti
Transcodifica dei media, reindicizzazione della libreria fotografica, rigenerazione delle miniature o riscrittura dei metadati
File di grandi archivi, contenitori crittografati, caselle di posta o immagini disco riscritti in loco
Bilanciamento del filesystem, espansione del pool, rilocazione dei blocchi o consolidamento degli snapshot

Confronta la finestra di backup con i log dell'applicazione e i grafici di scrittura dello storage. Se le scritture della sorgente sono aumentate nello stesso momento, il backup potrebbe segnalare un delta reale piuttosto che un errore di backup.

Verifica se il Change Tracking ha perso la sua baseline

I sistemi di tracciamento a blocchi confrontano lo stato attuale con un ID di modifica precedente noto. Un ripristino snapshot, una reimpostazione del tracciamento, una mappa di modifica non valida, una migrazione host, una sessione precedente fallita o la ricreazione del lavoro di backup possono interrompere questa relazione. La successiva esecuzione può quindi leggere o proteggere l'intera sorgente per stabilire una baseline sicura. Una guida pratica al recupero CBT nota che reimpostare il tracciamento delle modifiche può richiedere un nuovo full attivo prima che gli incrementali normali riprendano.

Cerca termini nei log come CBT reimpostato, ID di modifica non valido, journal avvolto, baseline mancante, nuova catena, oppure scansione completa richiesta. Non reimpostare il tracciamento ripetutamente senza conservare i log; ripetute reimpostazioni possono nascondere il trigger originale e produrre esecuzioni ripetute a grandezza intera.

Verifica che l'ambito del backup e l'identità della sorgente non siano cambiati

Un lavoro può ancora essere etichettato come incrementale pur proteggendo una sorgente diversa rispetto a prima. Un nuovo mount sotto un percorso incluso, una ridimensionamento del filesystem, un identificatore dispositivo cambiato, un nome host diverso, un nuovo percorso di condivisione o una regola di inclusione ampliata possono far sì che il motore costruisca nuove strutture interne. La risoluzione dei problemi della community mostra che volumi aggiuntivi e punti di mount possono essere inclusi in un lavoro che sembra invariato.

Esporta le definizioni del lavoro precedente e corrente e confrontale:

Radici protette, mount, condivisioni, dataset e dischi virtuali
Identificatori di host, volume e filesystem
Modelli di inclusione ed esclusione
Provider snapshot e modalità di coerenza
Impostazioni di crittografia, compressione e deduplicazione

Se la sorgente si è espansa intenzionalmente, può essere previsto un incremento a grandezza intera. Se ogni esecuzione successiva rimane grande, continua la diagnosi.

Determina se la granularità del backup si adatta ai file

I motori di suddivisione a livello di file, blocco e contenuto reagiscono in modo diverso a modifiche, rinominazioni e riscritture. Un sistema di deduplicazione a blocchi può registrare solo i metadati quando una cartella viene spostata; un motore più semplice a livello di file può trattare il percorso spostato come un file eliminato più un nuovo file. In un esempio basato su blocchi, rinominare una directory cambia i metadati del percorso senza ricaricare tutti i blocchi di dati invariati.

I file grandi e mutabili richiedono attenzione speciale. Un database, un'immagine VM, un vault crittografato o un archivio monolitico possono essere letti completamente per scoprire piccole modifiche interne, e la quantità memorizzata dipende infine dai confini dei chunk e dalla deduplicazione. Una discussione sui database di grandi dimensioni descrive come un file di database multi-gigabyte può essere letto completamente anche quando vengono trasferiti solo i chunk modificati.

Se l'applicazione fornisce un'esportazione coerente, un backup del log delle transazioni o un metodo di backup consapevole dell'applicazione, confrontare quel flusso di lavoro con il backup del file monolitico live.

Separare un grande incremento dall'attività di full sintetico e ritenzione.

Un full sintetico viene assemblato all'interno del repository da un full precedente più incrementali successivi. Può creare un oggetto di recupero a dimensione piena senza rileggere l'intera sorgente. Una panoramica dei tipi di backup spiega che i backup full sintetici sono costruiti dalla catena esistente di full e incrementali.

La crescita del repository può rimanere elevata anche quando i vecchi punti di ripristino rimangono bloccati, la potatura non è stata eseguita, gli snapshot eliminati fanno ancora riferimento a chunk o un merge necessita temporaneamente di spazio di lavoro. Controllare la timeline del lavoro invece di giudicare da una singola lista di directory:

Schema osservato.	Interpretazione probabile.	Prossimo controllo.
Il trasferimento di rete è piccolo, la scrittura nel repository è grande.	Full sintetico, merge o repack.	Log delle attività del repository.
Il file incrementale è piccolo, l'uso totale continua a salire.	Ritenzione, immutabilità, snapshot o potatura ritardata.	Punto di ripristino più vecchio mantenuto e programma di recupero.
Byte trasferiti e scritti si avvicinano entrambi alla dimensione piena.	Churn reale, baseline persa o ambito modificato.	Attività della sorgente e log di tracciamento.
Solo la prima esecuzione dopo una modifica è grande.	Nuova baseline o transizione del layout della sorgente.	Prossime due esecuzioni incrementali.

Eseguire un test a variabile singola prima di ricostruire la catena di backup.

Salvare la configurazione corrente del lavoro, i log dettagliati, l'elenco dei punti di ripristino e la capacità del repository.
Scegliere una finestra di test tranquilla e mettere in pausa le applicazioni note per scritture elevate se è sicuro farlo.
Creare un piccolo file di test, modificarlo una volta ed eseguire lo stesso lavoro incrementale senza cambiare alcuna impostazione.
Registrare byte scansionati, trasferiti, scritti, deduplicati e mantenuti.
Eseguire un secondo incrementale senza modifiche alla sorgente.

Se entrambe le esecuzioni controllate rimangono a dimensione piena, concentrarsi sul tracciamento, sull'identità della sorgente o sulla configurazione della catena di lavoro. Se diventano piccole, ripristinare i carichi di lavoro normali uno alla volta fino a quando il tasso di cambiamento non ritorna. Questo separa il comportamento del motore di backup dal churn dell'applicazione.

Abbina la Correzione alla Causa

Causa Confermata	Azione Correttiva	Risultato Atteso
Alto tasso reale di scrittura	Riduci l'ambito dei file temporanei, usa esportazioni consapevoli dell'app o programma dopo la manutenzione	La dimensione dell'incremento segue cambiamenti significativi dei dati
Tracciamento della baseline perso	Ripara il tracciamento una volta, crea la baseline richiesta, poi verifica gli incrementi successivi	Una grande esecuzione seguita da delta più piccoli
Ambito ampliato	Conferma che i nuovi dati sono intenzionali o dividili in un lavoro separato	Crescita prevedibile legata alla sorgente aggiunta
File grandi e modificabili	Usa dump coerenti con l'applicazione o un metodo di backup consapevole dei chunk	Meno rielaborazioni inutili e ripristini più sicuri
Operazioni di retention o sintetiche	Adatta la pianificazione della capacità, i tempi di potatura o la politica dei punti di ripristino	La crescita del repository corrisponde alla storia prevista

Quando dimensioni la destinazione, ricorda che la cronologia delle versioni e la retention possono rendere un repository più grande della sorgente attiva. La stessa distinzione è trattata nella guida ZimaSpace a pianificare la capacità del NAS per versioni e cronologia backup.

Interrompi ed Escala Quando Ogni Esecuzione Crea una Nuova Baseline

Escala prima di eliminare la catena quando i log mostrano ripetute invalidazioni della baseline, gli identificatori sorgente cambiano inaspettatamente, i punti di ripristino scompaiono, i metadati del repository segnalano corruzione o un test senza modifiche scrive ancora quasi tutta la sorgente. Mantieni i punti di ripristino attuali finché almeno un ripristino rappresentativo non è stato testato. Ricreare il lavoro può nascondere le prove e rimuovere l'unica storia recuperabile.

Domande Frequenti

Spostare o rinominare una cartella grande può causare un incremento di dimensioni complete?

Dipende dal motore di backup. Gli strumenti di deduplicazione per contenuto o blocchi possono riutilizzare i dati esistenti e memorizzare principalmente i metadati del percorso, mentre gli strumenti a livello di file possono trattare i file spostati come nuovi oggetti. Testa il prodotto esatto con una cartella rappresentativa prima di riorganizzare un grande set di dati.

Un full sintetico significa che il NAS ha caricato di nuovo l'intera sorgente?

Non necessariamente. Un full sintetico è comunemente assemblato dai dati già presenti nel repository. Confronta i contatori di lettura sorgente e trasferimento rete con i contatori di scrittura nel repository per vedere dove è avvenuto il lavoro.

Perché una piccola modifica al database può creare un incremento grande?

L'applicazione può riscrivere molti blocchi di archiviazione, compattare il database, ruotare i log o modificare i confini dei chunk anche quando la modifica visibile del record è piccola. Usa un backup o un'esportazione coerente con l'applicazione e confronta la sua delta con il file del database attivo.