Домен даних : Програма резервного копіювання, інтегрована з Retention Lock, може зазнавати помилок резервного копіювання через проблему конфігурації

Деякі завдання резервного копіювання завершуються помилкою в клієнті резервного копіювання з такими повідомленнями:
 

8212 6df7 12/05 15:47:15 871396 [MEDIAFS    ] 3637866-3138214 Cannot set the access time of [/data/col1/Commvault/SUBDIR/CV_MAGNETIC/V_305788/CHUNK_18517307], error=0xECCC000D:{CQiFile::SetTimes(825)/ErrNo.13.(Permission denied)}
8212 6df7 12/05 15:47:15 871396 [MEDIAFS    ] 3637866-3138214 Cannot mark the file [/data/col1/Commvault/SUBDIR/CV_MAGNETIC/V_305788/CHUNK_18517307] as read only.

Режим «тільки для читання» для резервних копій та образів — це те, як це конкретне програмне забезпечення для резервного копіювання викликає функцію DD backend, яка дозволяє адміністратору встановити період часу, протягом якого файл у бекенді не може бути змінений або видалений, для захисту від випадкового або зловмисного видалення даних. Ця функція називається Data Domain Retention Lock (скорочено RL).

На стороні DD журнали показують наступне для одного і того ж блоку зберігання, підкаталогу та файлу резервної копії:

12/05 07:47:47.820284 [7f1bc842a000] Attempt to set atime of 16adcf:0:16addb:0:7d70db86:6256fe81:0 to larger than maximum retention period of mtree.
12/05 07:47:47.820289 [7f1bc842a000] ERROR: FM fm_dm1_setattr:1408 - fm_dm1_setattr_intern failed
12/05 07:47:47.820533 [7f1bcdf19d90] ddboost-<backupsoftware.example.com-56892>: ddboost_api ERROR: ddp_utime() failed, su_name=Commvault, path_name=/SUBDIR/CV_MAGNETIC/V_305788/CHUNK_18517307, Err: 5034-nfs setattr failed (nfs: Permission denied)

Конфігурація DD RL для кожного окремого MTree, в якому включена ця функція, включає в себе встановлення мінімальної (Retention-lock min-retention-period) і максимальної (Retention-lock max-retention-period) тривалості блокувань, які дозволено встановлювати для будь-якого з файлів в MTree. У DD RL програма резервного копіювання повинна індивідуально встановлювати блокування файлів, якщо не ввімкнено функцію автоматичного блокування зберігання DD (ARL). Варіанти MTree в прикладі були наступними:
 

Mtree: /data/col1/Commvault

Option                                      Value
-----------------------------------------   -----------
Retention-lock                              enabled
Retention-lock mode                         governance
Retention-lock uuid                         UUID1:UUID2
Retention-lock min-retention-period         720minutes
Retention-lock max-retention-period         35days
Retention-lock automatic-retention-period   not set
Retention-lock automatic-lock-delay         120minutes
Retention-lock indefinite-retention-hold    disabled
-----------------------------------------   -----------

Це означає, що для будь-якого файлу в MTree RL може бути встановлено лише 720 хвилин від поточного часу (або довше) і 35 днів від поточного часу (або коротше). Іншими словами, з наведеною вище конфігурацією файл може бути захищений від модифікації або видалення лише на період понад 12 годин, але менше 35 днів. Будь-яка спроба програми резервного копіювання встановити блокування (що робиться шляхом оновлення часу файлу, при використанні BOOST; за допомогою виклику "ddp_utime") на коротший або довший термін, призведе до помилки, представленої вище:

12/05 07:47:47.820284 [7f1bc842a000] Attempt to set atime of 16adcf:0:16addb:0:7d70db86:6256fe81:0 to larger than maximum retention period of mtree.

Якщо програма резервного копіювання знає, як користуватися функцією DD RL, вона чекає, поки резервна копія завершить запис до образу на сервері, а потім, врешті-решт, встановить блокування для образу резервної копії (або образів, оскільки деяке програмне забезпечення може використовувати більше одного файлу для зберігання одного завдання резервної копії). Бібліотеки BOOST будуть використовуватися для виклику «ddp_utime», щоб встановити блокування на тривалість, що дорівнює передбачуваному збереженню резервної копії на рівні програми резервного копіювання. Це має два наслідки:

• Якщо час не синхронізовано між програмою резервного копіювання та DD, програма резервного копіювання може обчислити «X днів потому» та отримати дату та час, які не зовсім збігаються з датою та часом для DD, що призведе до того, що резервний образ буде заблоковано на коротший або довший період часу, залежно від ознаки різниці в часі
• Якщо передбачуване збереження резервної копії не узгоджується з обмеженнями RL на DD MTree, програма резервного копіювання може спробувати встановити блокування занадто далеко в майбутньому (на період, що перевищує «Максимальний період збереження замка»), і, отже, встановлення блокування буде відхилено. Якщо, наприклад, резервне копіювання програми зберігається протягом 60 днів, а в ДД встановлено значення «Максимальний період зберігання замка утримання» на 30 днів, налаштування блокування, очевидно, не вдасться

У ситуаціях, коли збереження програмного забезпечення для резервного копіювання дорівнює «Максимальний період збереження блокування збереження» на DD, будь-які незначні різниці в часі можуть призвести до відмови в налаштуванні блокування через різницю в часі між двома хостами.

Важливо, щоб усі хости в інфраструктурі резервного копіювання мали правильний час, а отже, щоб вони синхронізувалися через NTP або (якщо є) Windows AD.

Щоб уникнути кутових випадків, подібних до описаного, хорошою практикою є те, що "Максимальний період зберігання блокування утримання" в MTree з підтримкою RL встановлено на трохи довший, ніж політика резервного копіювання з найдовшим збереженням, що зберігається в цьому MTree. Наприклад, якщо в програмі резервного копіювання встановлено термін зберігання даних на 35 днів, встановлення параметра «Максимальний період зберігання замка збереження» на DD MTree, який використовується для зберігання цих політик, на 36 або навіть 40 днів, є правильним рішенням, щоб уникнути випадкових збоїв у встановленні RL.

Зауважте, що параметр "Максимальний період збереження замка збереження" (Retention-lock-max-retention-period) вищий за період зберігання резервних копій зображень не є проблемою. Якщо у нас було 100 днів «Максимальний період збереження замка» для 35-денної політики резервного копіювання збереження, через 35 днів зображення будуть видалені програмою, а clean позбудеться використаного простору під час наступного запуску. Єдиним недоліком є випадкове встановлення зображень з довшим блокуванням, з RL Compliance ви не зможете видаляти файли довше, ніж очікувалося. Тому рекомендація полягає в тому, щоб встановити "Retention-lock max-retention-period" трохи довше, але не занадто.