Avamar: O que acontece quando o avtar lê um arquivo durante a fase de varredura do arquivo
Zhrnutie: Este artigo descreve o que acontece quando o avtar lê um arquivo durante a fase de varredura de arquivo de um backup do Avamar.
Tento článok sa vzťahuje na
Tento článok sa nevzťahuje na
Tento článok nie je viazaný na žiadny konkrétny produkt.
V tomto článku nie sú uvedené všetky verzie produktov.
Pokyny
O que acontece quando o Avamar verifica arquivos durante um backup?
Durante um backup do Avamar, o avtar verifica todo o file system especificado no conjunto de dados de origem. Ele verifica cada arquivo para saber se ele foi modificado desde o backup anterior.
Para obter mais informações sobre como o avtar detecta se um arquivo foi modificado, consulte Avamar Client — O que precisa mudar antes de o avtar considerar que um arquivo foi modificado?
O Avtar percorre todos os diretórios, mesmo que o horário de modificação dos próprios diretórios não tenha sido alterado. Isso ocorre porque os subdiretórios de nível inferior podem ter sido alterados.
Para cada arquivo que não é de diretório, o avtar coleta seus metadados. Esses metadados são as informações "estatísticas" sobre o arquivo.
Em um sistema de arquivos NTFS ou ReFS do Windows com descritores de segurança, o avtar também coleta o descritor de segurança.
Isso ocorre porque essas informações podem mudar sem que a "hora de modificação do arquivo" mude.
Todo o caminho de um objeto é combinado com metadados semelhantes a estatísticas para executar uma pesquisa de cache de arquivos.
Em um hit de leitura do cache de arquivos, o hash de conteúdo, ou o local dos backups do Data Domain, é retornado.
Isso permite fazer backup do arquivo sem abri-lo. Não há necessidade, já que ele nunca mudou desde a última vez que foi feito backup.
Em uma perda de leitura do cache de arquivo, o arquivo é aberto e o conteúdo é lido, fragmentado, compactado e hash. Em seguida, o cache de hash (ou DDBoost para Data Domain) é usado para evitar o envio de conteúdo para o Avamar Server.
Um hash é produzido com base nas informações retornadas de uma operação semelhante a estatística.
Exemplo no Linux:
Ao avaliar se o arquivo foi alterado, o avtar considera os horários de modificação e alteração, mas NÃO o horário de acesso.
Essa é uma operação rápida e explica por que os backups do Avamar com poucos arquivos alterados e uma baixa taxa de alteração são tão rápidos.
Se o hash calculado for diferente do que está no cache de arquivos do client, o arquivo será considerado alterado. Um arquivo alterado deve ser totalmente processado, e os novos fragmentos devem ser enviados para o Avamar Server.
Durante um backup do Avamar, o avtar verifica todo o file system especificado no conjunto de dados de origem. Ele verifica cada arquivo para saber se ele foi modificado desde o backup anterior.
Para obter mais informações sobre como o avtar detecta se um arquivo foi modificado, consulte Avamar Client — O que precisa mudar antes de o avtar considerar que um arquivo foi modificado?
O Avtar percorre todos os diretórios, mesmo que o horário de modificação dos próprios diretórios não tenha sido alterado. Isso ocorre porque os subdiretórios de nível inferior podem ter sido alterados.
Para cada arquivo que não é de diretório, o avtar coleta seus metadados. Esses metadados são as informações "estatísticas" sobre o arquivo.
Em um sistema de arquivos NTFS ou ReFS do Windows com descritores de segurança, o avtar também coleta o descritor de segurança.
Isso ocorre porque essas informações podem mudar sem que a "hora de modificação do arquivo" mude.
Todo o caminho de um objeto é combinado com metadados semelhantes a estatísticas para executar uma pesquisa de cache de arquivos.
Em um hit de leitura do cache de arquivos, o hash de conteúdo, ou o local dos backups do Data Domain, é retornado.
Isso permite fazer backup do arquivo sem abri-lo. Não há necessidade, já que ele nunca mudou desde a última vez que foi feito backup.
Em uma perda de leitura do cache de arquivo, o arquivo é aberto e o conteúdo é lido, fragmentado, compactado e hash. Em seguida, o cache de hash (ou DDBoost para Data Domain) é usado para evitar o envio de conteúdo para o Avamar Server.
Um hash é produzido com base nas informações retornadas de uma operação semelhante a estatística.
Exemplo no 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
Ao avaliar se o arquivo foi alterado, o avtar considera os horários de modificação e alteração, mas NÃO o horário de acesso.
Essa é uma operação rápida e explica por que os backups do Avamar com poucos arquivos alterados e uma baixa taxa de alteração são tão rápidos.
Se o hash calculado for diferente do que está no cache de arquivos do client, o arquivo será considerado alterado. Um arquivo alterado deve ser totalmente processado, e os novos fragmentos devem ser enviados para o Avamar Server.
Ďalšie informácie
Artigos relacionados:
- Avamar: Comportamento e teoria do desempenho de backup.
- Avamar: Como usar os logs do client para identificar quais arquivos são novos ou alterados desde o backup anterior.
- Avamar: Solução de problemas de desempenho lento do backup.
- Avamar Client — O que precisa mudar antes que o avtar considere que um arquivo foi modificado?
Dotknuté produkty
AvamarProdukty
Avamar, Avamar ClientVlastnosti článku
Číslo článku: 000013952
Typ článku: How To
Dátum poslednej úpravy: 07 mar 2024
Verzia: 7
Nájdite odpovede na svoje otázky od ostatných používateľov spoločnosti Dell
Služby podpory
Skontrolujte, či sa na vaše zariadenie vzťahujú služby podpory.