Avamar: Cosa succede quando avtar legge un file durante la fase di scansione dei file
Summary: Questo articolo descrive cosa accade quando avtar legge un file durante la fase di scansione dei file di un backup Avamar.
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Instructions
Cosa succede quando Avamar esegue la scansione dei file durante un backup?
Durante un backup Avamar, avtar esegue la scansione dell'intero file system specificato all'interno del dataset di origine. Controlla ogni file per sapere se è stato modificato dal backup precedente.
Per ulteriori informazioni su come avtar rileva se un file è stato modificato, vedere Avamar Client - Cosa deve cambiare prima che avtar consideri un file come modificato?
Avtar esamina tutte le directory, anche se l'ora modificata delle directory stesse non è cambiata. Ciò è dovuto al fatto che le sottodirectory di livello inferiore potrebbero essere state modificate.
Per ogni file non di directory, avtar raccoglie i relativi metadati. Questi metadati sono le informazioni "statistiche" sul file.
In un file system NTFS o ReFS di Windows con descrittori di sicurezza, avtar raccoglie anche il descrittore di sicurezza.
Ciò è dovuto al fatto che tali informazioni possono cambiare senza che cambi l'ora di modifica del file.
L'intero percorso di un oggetto viene combinato con metadati di tipo statistica per eseguire una ricerca nella cache dei file.
In un file cache read hit, viene restituito l'hash del contenuto o la posizione per i backup di Data Domain.
Ciò consente di eseguire il backup del file senza aprirlo. Non ce n'è bisogno, poiché non è mai cambiato dall'ultima volta che è stato sottoposto a backup.
In caso di read miss della cache dei file, il file viene aperto e il contenuto viene letto, suddiviso in blocchi, compresso e sottoposto a hash. Viene quindi utilizzata la cache hash (o DDBoost per Data Domain) per evitare l'invio di contenuto all'Avamar Server.
Un hash viene prodotto in base alle informazioni restituite da un'operazione simile a una statistica.
Esempio in Linux:
Quando valuta se il file è stato modificato, avtar considera i tempi di modifica e modifica, ma NON l'ora di accesso.
Si tratta di un'operazione rapida che spiega perché i backup Avamar con pochi file modificati e un basso tasso di modifica sono così veloci.
Se l'hash calcolato differisce da quello presente nella cache dei file del client, il file viene considerato modificato. Un file modificato deve essere completamente elaborato e i nuovi blocchi devono essere inviati all'Avamar Server.
Durante un backup Avamar, avtar esegue la scansione dell'intero file system specificato all'interno del dataset di origine. Controlla ogni file per sapere se è stato modificato dal backup precedente.
Per ulteriori informazioni su come avtar rileva se un file è stato modificato, vedere Avamar Client - Cosa deve cambiare prima che avtar consideri un file come modificato?
Avtar esamina tutte le directory, anche se l'ora modificata delle directory stesse non è cambiata. Ciò è dovuto al fatto che le sottodirectory di livello inferiore potrebbero essere state modificate.
Per ogni file non di directory, avtar raccoglie i relativi metadati. Questi metadati sono le informazioni "statistiche" sul file.
In un file system NTFS o ReFS di Windows con descrittori di sicurezza, avtar raccoglie anche il descrittore di sicurezza.
Ciò è dovuto al fatto che tali informazioni possono cambiare senza che cambi l'ora di modifica del file.
L'intero percorso di un oggetto viene combinato con metadati di tipo statistica per eseguire una ricerca nella cache dei file.
In un file cache read hit, viene restituito l'hash del contenuto o la posizione per i backup di Data Domain.
Ciò consente di eseguire il backup del file senza aprirlo. Non ce n'è bisogno, poiché non è mai cambiato dall'ultima volta che è stato sottoposto a backup.
In caso di read miss della cache dei file, il file viene aperto e il contenuto viene letto, suddiviso in blocchi, compresso e sottoposto a hash. Viene quindi utilizzata la cache hash (o DDBoost per Data Domain) per evitare l'invio di contenuto all'Avamar Server.
Un hash viene prodotto in base alle informazioni restituite da un'operazione simile a una statistica.
Esempio in Linux:
stat testtest.gz
File: `testtest.gz'
Size: 29 Blocks: 8 IO Block: 4096 regular file
Device: 803h/2051d Inode: 2149406915 Links: 1
Access: (0600/-rw-------) Uid: ( 500/ admin) Gid: ( 500/ admin)
Access: 2014-12-30 07:51:14.335261000 +0000
Modify: 2014-12-30 07:51:14.335261000 +0000
Change: 2014-12-30 07:51:18.443265606 +0000
Quando valuta se il file è stato modificato, avtar considera i tempi di modifica e modifica, ma NON l'ora di accesso.
Si tratta di un'operazione rapida che spiega perché i backup Avamar con pochi file modificati e un basso tasso di modifica sono così veloci.
Se l'hash calcolato differisce da quello presente nella cache dei file del client, il file viene considerato modificato. Un file modificato deve essere completamente elaborato e i nuovi blocchi devono essere inviati all'Avamar Server.
Additional Information
Articoli correlati:
- Avamar: Comportamento e teoria delle prestazioni di backup.
- Avamar: Come utilizzare i log del client per identificare quali file sono nuovi o modificati rispetto al backup precedente.
- Avamar: Risoluzione dei problemi di prestazioni di backup lente.
- Avamar Client - Cosa deve cambiare affinché avtar consideri un file come modificato?
Affected Products
AvamarProducts
Avamar, Avamar ClientArticle Properties
Article Number: 000013952
Article Type: How To
Last Modified: 07 Mar 2024
Version: 7
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.