Авамар: Що відбувається, коли avtar читає файл на етапі сканування файлу
Summary: У цій статті описано, що відбувається, коли avtar читає файл під час етапу сканування файлу резервної копії 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
Що відбувається, коли Avamar сканує файли під час резервного копіювання?
Під час резервного копіювання Avamar avtar сканує всю файлову систему, вказану у вихідному наборі даних. Він перевіряє кожен файл, щоб дізнатися, чи був він змінений з моменту попереднього резервного копіювання.
Для отримання додаткової інформації про те, як avtar виявляє, що файл було змінено, перегляньте статтю Клієнт Avamar - Що має змінитися, перш ніж avtar вважатиме файл зміненим?
Avtar обходить всі каталоги, навіть якщо змінений час самих довідників не змінився. Це пов'язано з тим, що підкаталоги нижчого рівня могли змінитися.
Для кожного файла, який не є каталогом, avtar збирає його метадані. Ці метадані є 'stat' інформацією про файл
.У файловій системі Windows NTFS або ReFS з дескрипторами безпеки avtar також збирає дескриптор безпеки.
Це пов'язано з тим, що ця інформація може змінюватися без зміни «часу зміни файлу».
Увесь шлях до об'єкта поєднується зі статистичними метаданими для виконання пошуку в кеші файлів.
Під час читання кешу файлу повертається хеш вмісту або розташування для резервних копій домену даних.
Це дозволяє створювати резервні копії файлу, не відкриваючи його. У цьому немає необхідності, оскільки він ніколи не змінювався з моменту останнього резервного копіювання.
У файловому кеші промахується читання, файл відкривається, а вміст читається, фрагментується, стискається та хешується. Потім використовується хеш-кеш (або DDBoost для Data Domain), щоб уникнути відправки контенту на сервер Avamar.
Хеш створюється на основі інформації, яка повертається в результаті операції, подібної до статистики.
Приклад в Linux:
Оцінюючи, чи було змінено файл, avtar враховує час внесення змін і змін, але НЕ час доступу.
Це швидка операція, яка пояснює, чому резервні копії Avamar з невеликою кількістю змінених файлів і низькою швидкістю змін є такими швидкими.
Якщо обчислюваний хеш відрізняється від того, що знаходиться в файловому кеші клієнта, файл вважається зміненим. Змінений файл повинен бути повністю оброблений, а нові фрагменти повинні бути відправлені на сервер Avamar.
Під час резервного копіювання Avamar avtar сканує всю файлову систему, вказану у вихідному наборі даних. Він перевіряє кожен файл, щоб дізнатися, чи був він змінений з моменту попереднього резервного копіювання.
Для отримання додаткової інформації про те, як avtar виявляє, що файл було змінено, перегляньте статтю Клієнт Avamar - Що має змінитися, перш ніж avtar вважатиме файл зміненим?
Avtar обходить всі каталоги, навіть якщо змінений час самих довідників не змінився. Це пов'язано з тим, що підкаталоги нижчого рівня могли змінитися.
Для кожного файла, який не є каталогом, avtar збирає його метадані. Ці метадані є 'stat' інформацією про файл
.У файловій системі Windows NTFS або ReFS з дескрипторами безпеки avtar також збирає дескриптор безпеки.
Це пов'язано з тим, що ця інформація може змінюватися без зміни «часу зміни файлу».
Увесь шлях до об'єкта поєднується зі статистичними метаданими для виконання пошуку в кеші файлів.
Під час читання кешу файлу повертається хеш вмісту або розташування для резервних копій домену даних.
Це дозволяє створювати резервні копії файлу, не відкриваючи його. У цьому немає необхідності, оскільки він ніколи не змінювався з моменту останнього резервного копіювання.
У файловому кеші промахується читання, файл відкривається, а вміст читається, фрагментується, стискається та хешується. Потім використовується хеш-кеш (або DDBoost для Data Domain), щоб уникнути відправки контенту на сервер Avamar.
Хеш створюється на основі інформації, яка повертається в результаті операції, подібної до статистики.
Приклад в 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.
Additional Information
Статті по темі:
- Авамар: Поведінка та теорія продуктивності резервного копіювання.
- Авамар: Як використовувати журнали клієнта, щоб визначити, які файли є новими або зміненими з моменту попереднього резервного копіювання.
- Авамар: Усунення несправностей із повільною роботою резервного копіювання.
- Клієнт Avamar - Що має змінитися, перш ніж avtar вважатиме файл зміненим?
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.