Авамар: Що відбувається, коли avtar читає файл на етапі сканування файлу
Zhrnutie: У цій статті описано, що відбувається, коли avtar читає файл під час етапу сканування файлу резервної копії 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
Що відбувається, коли 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.
Ďalšie informácie
Статті по темі:
- Авамар: Поведінка та теорія продуктивності резервного копіювання.
- Авамар: Як використовувати журнали клієнта, щоб визначити, які файли є новими або зміненими з моменту попереднього резервного копіювання.
- Авамар: Усунення несправностей із повільною роботою резервного копіювання.
- Клієнт Avamar - Що має змінитися, перш ніж avtar вважатиме файл зміненим?
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.