Avamar. Что происходит, когда avtar считывает файл на этапе проверки файла
Сводка: В этой статье описывается, что происходит, когда avtar считывает файл на этапе сканирования файла резервной копии Avamar.
Данная статья применяется к
Данная статья не применяется к
Эта статья не привязана к какому-либо конкретному продукту.
В этой статье указаны не все версии продуктов.
Инструкции
Что происходит, когда Avamar сканирует файлы во время резервного копирования?
Во время резервного копирования Avamar avtar сканирует всю файловую систему, указанную в исходном наборе данных. Он проверяет каждый файл, чтобы узнать, не был ли он изменен с момента предыдущего резервного копирования.
Дополнительные сведения о том, как avtar определяет, что файл был изменен, см. в разделе Клиент Avamar — что должно измениться, прежде чем avtar сочтет файл измененным?
Avtar обходит все каталоги, даже если время изменения самих каталогов не изменилось. Это связано с тем, что подкаталоги более низкого уровня могли измениться.
Для каждого файла, не относящегося к каталогу, avtar собирает его метаданные. Эти метаданные представляют собой статистическую информацию о файле.
В файловой системе Windows NTFS или ReFS с дескрипторами безопасности avtar также собирает дескриптор безопасности.
Это связано с тем, что эта информация может изменяться без изменения параметра «время изменения файла».
Весь путь к объекту объединяется с метаданными, подобными статистике, для выполнения поиска
в кэше файлов.При обращении к чтению файлового кэша возвращается хэш содержимого или местоположение для резервных копий Data Domain.
Это позволяет создавать резервную копию файла, не открывая его. В этом нет необходимости, так как он не менялся с момента последнего резервного копирования.
При промахе чтения файлового кэша файл открывается, а содержимое считывается, разбивается на фрагменты, сжимается и хэшируется. Затем используется хэш-кэш (или DDBoost для Data Domain), чтобы избежать отправки содержимого на сервер Avamar.
Хэш создается на основе информации, которая возвращается в результате операции, подобной stat-like.
Пример в Linux:
При оценке того, изменился ли файл, avtar учитывает время изменения и изменения, но НЕ время доступа.
Это быстрая операция, которая объясняет, почему резервное копирование Avamar с небольшим количеством измененных файлов и низкой частотой изменения выполняется так быстро.
Если вычисленный хэш отличается от того, что находится в кэше файлов клиента, файл считается измененным. Измененный файл должен быть полностью обработан, а новые фрагменты должны быть отправлены на Avamar Server.
Во время резервного копирования Avamar avtar сканирует всю файловую систему, указанную в исходном наборе данных. Он проверяет каждый файл, чтобы узнать, не был ли он изменен с момента предыдущего резервного копирования.
Дополнительные сведения о том, как avtar определяет, что файл был изменен, см. в разделе Клиент Avamar — что должно измениться, прежде чем avtar сочтет файл измененным?
Avtar обходит все каталоги, даже если время изменения самих каталогов не изменилось. Это связано с тем, что подкаталоги более низкого уровня могли измениться.
Для каждого файла, не относящегося к каталогу, avtar собирает его метаданные. Эти метаданные представляют собой статистическую информацию о файле.
В файловой системе Windows NTFS или ReFS с дескрипторами безопасности avtar также собирает дескриптор безопасности.
Это связано с тем, что эта информация может изменяться без изменения параметра «время изменения файла».
Весь путь к объекту объединяется с метаданными, подобными статистике, для выполнения поиска
в кэше файлов.При обращении к чтению файлового кэша возвращается хэш содержимого или местоположение для резервных копий Data Domain.
Это позволяет создавать резервную копию файла, не открывая его. В этом нет необходимости, так как он не менялся с момента последнего резервного копирования.
При промахе чтения файлового кэша файл открывается, а содержимое считывается, разбивается на фрагменты, сжимается и хэшируется. Затем используется хэш-кэш (или DDBoost для Data Domain), чтобы избежать отправки содержимого на сервер Avamar.
Хэш создается на основе информации, которая возвращается в результате операции, подобной stat-like.
Пример в 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
При оценке того, изменился ли файл, avtar учитывает время изменения и изменения, но НЕ время доступа.
Это быстрая операция, которая объясняет, почему резервное копирование Avamar с небольшим количеством измененных файлов и низкой частотой изменения выполняется так быстро.
Если вычисленный хэш отличается от того, что находится в кэше файлов клиента, файл считается измененным. Измененный файл должен быть полностью обработан, а новые фрагменты должны быть отправлены на Avamar Server.
Дополнительная информация
Похожие статьи
- Avamar. Поведение и теория производительности резервного копирования.
- Avamar. Как использовать журналы клиента для определения новых файлов или файлов, измененных с момента предыдущего резервного копирования.
- Avamar. Поиск и устранение проблем, связанных с низкой производительностью резервного копирования.
- Avamar Client. Что должно измениться, прежде чем avtar сочтет файл измененным?
Затронутые продукты
AvamarПродукты
Avamar, Avamar ClientСвойства статьи
Номер статьи: 000013952
Тип статьи: How To
Последнее изменение: 07 Mar 2024
Версия: 7
Получите ответы на свои вопросы от других пользователей Dell
Услуги технической поддержки
Проверьте, распространяются ли на ваше устройство услуги технической поддержки.