メイン コンテンツに進む
  • すばやく簡単にご注文が可能
  • 注文内容の表示、配送状況をトラック
  • 会員限定の特典や割引のご利用
  • 製品リストの作成とアクセスが可能
  • 「Company Administration(会社情報の管理)」では、お使いのDell EMCのサイトや製品、製品レベルでのコンタクト先に関する情報を管理できます。

Домен даних: Retention Lock Поширені запитання

概要: Ця стаття містить огляд функцій блокування збереження домену даних (RL) і пояснює відмінності між конфігурацією та використанням режиму керування та відповідності.

この記事は自動翻訳されたものである可能性があります。品質に関するフィードバックがある場合は、このページの下部にあるフォームを使用してお知らせください。

文書の内容


現象

Ця стаття містить стислий огляд функцій блокування збереження домену даних (RL) і відповіді на пов'язані з цим поширені запитання (FAQ).

原因

Ця стаття містить стислий огляд функцій блокування збереження домену даних (RL) і відповіді на пов'язані з цим поширені запитання (FAQ).

解決方法

Що таке утримуючий замок?
Блокування збереження – це функція, яка використовується на відновлювачах доменів даних (DDR) для запобігання зміні або видаленню певних наборів файлів протягом заздалегідь визначеного періоду. Тобто файли, заблоковані при зберіганні, доступні лише для читання до закінчення терміну їх зберігання.

Які існують версії фіксатора утримання?
Фіксатор фіксатора доступний для двох різних функцій:
  • Управління: Менш сувора з двох функцій блокування утримання (тобто блокування проти файлів може бути скасована, якщо це необхідно).
  • Відповідності: Більш сувора з двох функцій, які підкоряються декільком загальним нормативним стандартам. Тобто, блокування проти файлів не можуть бути скасовані. DDR має бути налаштований з користувачем «офіцера безпеки», який повинен автентифікувати певні команди. Існують різні обмеження на інші функції, щоб запобігти видаленню заблокованих даних або достроковому скасуванню блокувань.
Примітка:
  • Режим відповідності доступний лише в DDOS 5.3 (і пізніших версіях).
  • Для кожної функції утримуючого замка потрібен окремий ліцензійний ключ.
  • Функція блокування утримання вмикається на основі кожного MTree.
  • Єдина система може використовувати як режим управління, так і режим відповідності проти окремих MTrees. Однак він повинен мати окремі ліцензії на управління та відповідність.
  • Не вмикайте будь-який вид блокування збереження DD на MTrees, який використовується для зберігання даних Avamar, якщо це не вказано в документації Avamar, як частина запуску цієї функції на Avamar. Увімкнення DD RL на будь-якому такому MTree без дотримання правильного процесу Avamar може зробити MTree непридатним для резервного копіювання та спричинити потребу в тривалому відновленні. Це особливо вірно, якщо включено автоматичне блокування утримання (ARL) для Avamar MTree.
  • Функція блокування збереження може не підтримуватися для MTrees, які використовуються для зберігання даних за допомогою старіших версій Avamar або даних Protection Software на пристроях Integration Data Protection Appliance або PowerProtect Data Protection Series. Це може перешкодити Avamar або захисному програмному забезпеченню всередині Integration Data Protection Appliance працювати належним чином і переходити в стан READONLY.
Які протоколи доступу до даних підтримуються з retention lock?
  • Протоколи NFS, CIFS і DD Boost повністю підтримуються проти MTrees за допомогою управління збереженням блокування або режиму відповідності.
  • Протокол Virtual Tape Library (VTL) підтримується лише для MTrees у режимі керування блокуванням утримання. Автоматичне блокування збереження не підтримується на VTL домену даних. Зверніться до Посібника з адміністрування домену даних, щоб дізнатися, як розблокувати стрічки із збереженням таким чином, щоб на них можна було записувати.
Режим відповідності режиму утримання замка відповідає нормативним стандартам:
До переліку нормативних стандартів, яким відповідає режим відповідності retention lock, входять наступні:     
  • СЕК 17а-4(f)
  • Правило CFTC 1.31b
  • FDA 21 CFR Частина 11
  • Закон Сарбейнса-Окслі
  • IRS 98025 і 97-22
  • Стандарт ISO 15489-1
  • MoREQ2010
Щоб отримати повну інформацію про сертифікацію, зверніться до постачальника підтримки, з яким укладено договір.

Як увімкнено керування блокуванням утримання?
  • До DDR додано ліцензію на керування замком утримання.
  • Режим керування замком утримання включено для будь-якого необхідного MTree:     
# mtree retention-lock enable mode governance mtree [mtree]

Як забезпечується відповідність вимогам фіксатора утримання?
  • Існують конкретні інструкції для деяких нових моделей Data Domain з iDRAC.
  • До DDR додано ліцензію на відповідність замку утримання.
  • Слід створити користувача з роллю 'security' (за умови, що такого користувача не існує):     
(ADMIN USER) # user add [username] role security
  •  Користувач з роллю «безпека» повинен увійти в DDR і включити авторизацію користувача-охоронця:     
(SECURITY USER): # authorization policy set security-officer enabled
  • Система повинна бути налаштована на режим відповідності фіксації утримання. Як тільки наступна команда виконується до завершення, система автоматично перезавантажується:     
(ADMIN USER) # system retention-lock compliance configure
  • Після перезавантаження системи в системі має бути ввімкнено режим відповідності блокуванню утримання:     
(ADMIN USER) # system retention-lock compliance enable
Примітка: У новіших випусках DDOS це завдання має виконуватися за допомогою інтерфейсу Data Domain UI. Дотримання вимог адміністрації >
  • Режим відповідності блокуванню утримання включений для будь-яких необхідних MTree:
(ADMIN USER) # mtree retention-lock enable mode compliance mtree [mtree]


Як можна визначити, на яких MTrees увімкнено блокування утримання?
MTrees з увімкненим блокуванням утримання вказуються у виводі 'mtree list', наприклад:      

sysadmin@ddxxxx# mtree list
Name                                Pre-Comp (GiB)   Status    Tenant-Unit
---------------------------------   --------------   -------   -----------
...
/data/col1/rich-retention-lock                 0.0   RW/RLGE   -
/data/col1/rl_test                             0.0   RW/RLGD   -
/data/col1/rl_test_comp                        0.0   RW/RLCE   -
/data/col1/test                                3.1   RW/RLGE   -
...
---------------------------------   --------------   -------   -----------
...
 RLGE : Retention-Lock Governance Enabled
 RLGD : Retention-Lock Governance Disabled
 RLCE : Retention-Lock Compliance Enabled


Чи можна перетворити MTree з увімкненим керуванням замком утримання на відповідність вимогам Retention Lock?
Як зазначено в Керівництві з адміністрування DDOS, це неможливо.

Чи можна перетворити MTree з увімкненою відповідністю Retention Lock на Retention Lock Governance?
Як зазначено в Керівництві з адміністрування DDOS, це неможливо.

Як встановлюються періоди зберігання файлів або блокування?
Після ввімкнення блокування зберігання для MTree необхідно встановити мінімальний і максимальний період зберігання. Ці періоди визначають мінімальний і максимальний час, протягом якого файл може бути заблокований. Наприклад:     

# mtree retention-lock set min-retention-period [period] mtree [mtree]
# mtree retention-lock set max-retention-period [period] mtree [mtree]

Періоди можуть бути наведені в різних одиницях наступним чином:     

  • 1 хв
  • 1 год.
  • 1 доб.
  • 1 міс.
  • 1 рік
Примітка:
  • Мінімальний період зберігання не може бути менше 12 годин.
  • Максимальний термін зберігання не може перевищувати 70 років.
  • Мінімальний період зберігання має бути меншим за максимальний період зберігання.
  • Періоди зберігання для кожного MTree встановлюються однаково, незалежно від того, який смак використовується блокування утримання.

Як можна відобразити існуючі періоди зберігання?
Це можна зробити за допомогою наступних двох команд:     

# mtree retention-lock show min-retention-period mtree [mtree]
# mtree retention-lock show max-retention-period mtree [mtree]

Наприклад:     

sysadmin@dd630# mtree retention-lock show min-retention-period mtree /data/col1/rl_test
Retention-lock min-retention-period of mtree /data/col1/rl_test is: 720 minutes.
sysadmin@dd630# mtree retention-lock show max-retention-period mtree /data/col1/rl_test
Retention-lock max-retention-period of mtree /data/col1/rl_test is: 30 days.


Як блокуються файли в MTree з увімкненим блокуванням збереження?

  • Коли на MTree увімкнено блокування збереження, існуючі файли в MTree не блокуються автоматично (тобто, всі вже існуючі файли залишаються прочитаними або записаними).
  • Коли новий файл записується на MTree з увімкненим блокуванням збереження, файл не блокується автоматично. Тобто новий файл залишається як прочитаний або записаний.
Примітка: Починаючи з DDOS 6.2.0.20, в DDOS є функція під назвою "автоматичне блокування утримання", яка може автоматично встановлювати блокування всіх записаних файлів. Щоб дізнатися більше, перегляньте розділ "Автоматичне блокування утримання" нижче в цій статті бази знань.
  • Щоб заблокувати певний файл, час збереження файлу має бути змінено, щоб він відповідав даті, а час блокування збереження файлу має бути заблоковано. Це дата та час, до яких файл має залишатися доступним лише для читання. До тих пір, поки час не буде змінено таким чином, файл не може бути заблокований при збереженні (і його можна змінити або видалити).

Час роботи файлу можна змінити в клієнті NFS або CIFS за допомогою команди 'touch':

# touch -a -t [expiry time] [file to be locked]

Наприклад, щоб встановити час /data/col1/rl_test/testfile на 07:05 8 червня: 

# touch -a -t 06080705 /data/col1/rl_test/testfile

Період від поточного часу до майбутнього часу повинен бути в межах мінімального та максимального періодів зберігання для MTree. В іншому випадку при часовій зміні файлів генерується помилка: 

# touch -a -t 08080705 /data/col1/rl_test/testfile
touch: setting times of `/data/col1/rl_test/testfile': Permission denied

У файлових файлових системах домену даних (DDFS) також відображається відповідне повідомлення:     

06/07 13:44:57.197 (tid 0x2b28ee5258c0): Attempt to set atime of /data/col1/rl_test/testfile to larger than maximum retention period of mtree.

Клієнти CIFS (Windows) за замовчуванням не включають сенсорну команду або утиліту, однак кілька таких утиліт є у вільному доступі для завантаження з різних сторонніх веб-сайтів.

Примітка: Файли не можуть бути заблоковані, доки їх не буде записано в DDR. Неможливо створити порожній файл, заблокувати цей файл, а потім записати дані у файл.

Які програми для резервного копіювання підтримують автоматичне блокування файлів після запису в DDR?
Блокування збереження домену даних сумісне зі стандартними протоколами запису (WORM) на базі NAS. Інтеграція кваліфікується з архівними додатками, такими як Symantec Enterprise Vault, SourceOne, Cloud Tiering Appliance або DiskXtender.

Для Dell NetWorker підтримуються режими управління та відповідності.

Станом на червень 2024 року, останні версії Avamar підтримують як дотримання вимог Data Domain Retention Lock, так і Governance) як частину функції Avamar «Незмінні резервні копії». Подробиці дивіться в статті нижче і в документації Avamar:
Avamar і Data Domain: Увімкнення незмінного резервного копіювання Avamar і блокування

збереження режиму відповідності домену данихДуже важливо, щоб кроки для ввімкнення функції «Незмінні резервні копії» Avamar суворо дотримувалися. Якщо цього не зробити, це може закінчитися тим, що в DD з'явиться Avamar MTree, на який не можна буде додатково записати, або який має проблеми з роботою, які змушують до тривалого відновлення. Avamar не працює з DD Automatic Retention Lock (ARL), і ARL не повинен бути включений для будь-якого Avamar MTree на DD.

Клієнти, які використовують інші програми для резервного копіювання, які не підтримують блокування збереження домену даних, також можуть розробляти власні сценарії для використання блокування збереження домену даних для ручного встановлення періодів зберігання файлів. У цьому сценарії переконайтеся, що користувацькі сценарії встановлюють час файлу таким чином, щоб вони були розблоковані, перш ніж програма резервного копіювання спробує видалити файл. Якщо цього не зробити, програма резервного копіювання може спробувати видалити заблоковані файли (що не вдається); Файл залишається на DDR нескінченно довго займаючи місце на диску. Перегляньте посібник із адміністрування домену даних.

Автоматичне блокування
утриманняДля програм резервного копіювання, які не підтримують функцію блокування збереження домену даних, для клієнтів завжди було проблемою використовувати цю функцію. Адміністратор резервної копії повинен налаштувати сценарії для встановлення блокування збереження нових файлів для MTree. Блокування має бути встановлено таким чином, щоб термін його дії закінчувався незадовго до того, як резервна копія має бути завершена (і видалена) адміністратором резервної копії.

ARL встановлює блокування для кожного файлу, записаного в MTree після включення функції, запобігаючи зміні або видаленню файлу протягом заданого періоду часу після закінчення налаштованого періоду охолодження. Це означає, що ARL не повинен бути включений для робочих навантажень або додатків резервного копіювання, які повинні багаторазово оновлювати деякі файли протягом певного часу, наприклад, у пулах VTL (файли стрічки VTL постійно записуються), або для програм резервного копіювання, які зберігають інформацію метаданих разом із самими файлами резервних копій клієнтів (наприклад, NetWorker або Avamar). Увімкнення ARL у цих випадках дозволяє заблокувати важливі файли на деякий час, і коли ці файли потрібно записати пізніше для інших резервних копій, запис не вдається, як і будь-які подальші резервні копії.

Щоб допомогти адміністраторам резервних копій зменшити тягар зберігання файлів блокування збереження та підняти DDOS на рівень паритету функцій з іншими постачальниками, починаючи з DDOS 6.2.0.20, існує функція, яку можна ввімкнути з CLI для кожного MTree з налаштованим Retention Lock, щоб встановити блокування на кожен прийнятий файл (на заданий період), після того, як пройде деякий заданий проміжок часу з моменту завершення запису файлу на диск. Таким чином, адміністраторам більше не доведеться турбуватися про ручне (або сценарнерове) налаштування блокування збереження, і це може відбуватися автоматично без співпраці програми резервного копіювання. 
До DDOS 7.8 автоматичне блокування утримання не можна використовувати на логічних накопичувачах DD Boost (LSU), і спроба ввімкнути його повертає помилку про те, що він не підтримується.
Починаючи з версії 7.8, ARL підтримується для DD Boost LSU.

(ARL, що використовується на цільових DD для керованої реплікації файлів (MFR), як і клон NW, повинен мати достатньо довгий "automatic-lock-delay", щоб гарантувати, що операції клонування завершені для набору резервних копій до того, як буде встановлено блокування файлів. Приклад: Малий файл, який є частиною набору резервних копій, швидко завершує реплікацію, тоді як більший файл займає більше часу, тоді перший файл блокується до того моменту, коли більший файл закінчує реплікацію, і стикається з помилкою, коли NW намагається перемістити всі файли набору резервних копій до кінцевого архівного каталогу.)

Автоматичне блокування збереження не підтримується на VTL домену даних.

У відповідних версіях є додаткові опції в командному рядку "mtree retention-lock", як показано нижче. Цю функцію також можна налаштувати через інтерфейс користувача, вибравши «Автоматично» замість «Вручну» в опції «Використання»:     

# mtree retention-lock set
{min-retention-period | max-retention-period |
automatic-retention-period | automatic-lock-delay} <period>
mtree <mtree-path>

Функція автоматичного блокування утримання блокує файл одразу після закінчення попередньо налаштованого періоду охолодження (автоматичне блокування-затримка). Після того, як файл записано в MTree з увімкненим блокуванням утримання, і блокування діє протягом "automatic-retention-period" з моменту його встановлення, якщо значення знаходиться в межах значень "min-retention-period" та "max-retention-period", встановлених для MTree, відбувається блокування.

Для отримання додаткової інформації про цю функцію та загальних відомостей зверніться до відповідного Посібника з адміністрування DDOS. Ця функція не дуже добре підходить для ситуацій, коли той самий MTree використовується як ціль для резервних копій, які повинні мати або набори блокування на різні періоди, або резервних копій, які повинні мати не встановлений блокування.

Що можна або не можна робити із заблокованим файлом?

  • Файли, заблоковані під час збереження, доступні лише для читання та не можуть бути змінені або видалені.
  • Як тільки термін зберігання файлу закінчується, він «розблоковується» - коли файл знаходиться в розблокованому стані, його все одно не можна змінити, однак його можна видалити. DDR не видаляє файл автоматично після закінчення терміну його зберігання (подальше видалення має виконуватися з клієнтської системи або резервної програми).
  • Один раз встановлений період зберігання для певного файлу не може бути скорочений (тобто файли не можуть бути перенесені вперед).
  • Однак періоди зберігання можуть бути збільшені (час може бути збільшений до максимального терміну зберігання для MTree).
  • Параметри права власності та дозволів для файлу можна змінювати, коли файл заблоковано
  • Перейменувати або видалити каталог можна лише в MTree з увімкненим блокуванням утримання, якщо цей каталог не містить файлів. Якщо каталог містить файли (навіть якщо ці файли не заблоковано при зберіганні), перейменувати або видалити каталог не вдасться
  • Навіть якщо він не змінює сам вміст файлу, не дозволяється змінювати ім'я (перейменовувати) файли, для яких встановлено блокування, але перейменування також забороняється після закінчення терміну блокування файлу. Для файлів, які більше не блокуються, єдиною дозволеною операцією є видалення. Це змінено в DDOS 7.7.4, коли для файлів, які більше не блокуються, дозволяється перейменування файлу.

Чи можна повністю зняти фіксатор з файлу або набору файлів?
"Скасувати" (зняти) блокування збереження файлів можна в MTrees за допомогою режиму управління - це робиться за допомогою наступної команди:     

# mtree retention-lock revert [path]

Після зняття блокування збереження файлу його можна змінити або видалити як зазвичай. Якщо ця команда виконується з каталогом, то всі файли в цьому каталозі та всіх підкаталогах видаляються блокування збереження.

Скасувати блокування збереження файлів у MTrees за допомогою режиму відповідності неможливо - при спробі цього відображається відповідна помилка:     

# mtree retention-lock revert /data/col1/rl_test_comp/testfile
This operation is not allowed. Mtree is in retention-lock compliance mode.


Що станеться, якщо файл, заблокований у збереженні, спробують змінити або видалити?
Будь-яка спроба змінити або видалити файл, заблокований на збереження, спричиняє відповідну помилку «відмовлено в дозволі»:     

# echo " test2" >> /data/col1/rl_test/testfile
bash: testfile: Permission denied
# rm testfile
rm: remove write-protected regular file `testfile'? y
rm: cannot remove `testfile': Permission denied

Журнали DDFS вказують на те, що операцію не вдалося виконати через блокування збереження файлу:     

06/07 07:06:59.756 (tid 0x2b5a77605d50): Atime of retention-lock file /data/col1/rl_test/testfile is not expired.
06/07 07:07:42.504 (tid 0x2b5a79111390): Atime of retention-lock file /data/col1/rl_test/testfile is not expired.


Чи можна вивести список усіх файлів, які заблоковано при зберіганні?
Так, це можна виконати за допомогою команди 'mtree retention-lock report generate retention-details':     

mtree retention-lock report generate retention-details
mtrees {<mtree-list> | all}
[format {text | tsv | csv}]
[output-file <file-name>]
               Report detailed information of
               retention-lock files.

Наприклад, щоб вивести відомості про всі заблоковані файли в MTree /data/col1/rl_test, слід виконати наступне:     

sysadmin@ddxxxx# mtree retention-lock report generate retention-details mtrees /data/col1/jftest
Report generated on: Fri Jul  1 14:19:31 2016

Report for mtree: /data/col1/jftest
File Path        Mode        Size(Bytes)        Expiration Date
/data/col1/jftest/file1 governance 10521456 Sat Jul  2 22:35:48 2016
/data/col1/jftest/testdir/file2 governance 10521680 Sat Jul  2 22:35:42 2016
/data/col1/jftest/file3 governance 10521820 Sun Jul 10 22:36:09 2016
Total files: 3


Чи можна повністю відключити блокування утримання для MTree (після його включення)?
Так, для MTrees з використанням режиму управління, це виконується за допомогою команди 'mtree retention-lock disable':    

# mtree retention-lock disable mtree [mtree]

For example:     
sysadmin@xxxx# mtree retention-lock disable mtree /data/col1/rl_test
Retention-lock feature is disabled (previously enabled) for mtree /data/col1/rl_test.

Once disabled, MTree list indicates that retention lock was used against the MTree but has since been disabled, that is: 
sysadmin@ddxxxx# mtree list
Name                                Pre-Comp (GiB)   Status    Tenant-Unit
---------------------------------   --------------   -------   -----------
...
/data/col1/rl_test                             0.0   RW/RLGD   -
...
Примітка: Після того, як блокування утримання вимкнено на MTree:
  • Нові файли, записані на MTree, не можуть бути заблоковані при зберіганні.
  • Файли, які вже заблоковано, залишаються заблокованими протягом раніше визначеного періоду зберігання (тобто всі блокування не скасовуються автоматично, коли блокування збереження вимкнено проти MTree).
  • Існуючі блокування файлів у MTree, де блокування утримання вимкнено, не можуть бути скасовані. Перед вимкненням блокування утримання необхідно виконати всі необхідні реверсії:
sysadmin@ddxxxx# mtree retention-lock revert /data/col1/rl_test/testfile
**** Retention-lock feature is disabled (previously enabled) for mtree which contains the path /data/col1/rl_test/testfile.
  • Блокування утримання не може бути відключено для MTree за допомогою режиму відповідності:     
sysadmin@ddxxxx# mtree retention-lock disable mtree /data/col1/rl_test_comp
**** Operation is not allowed because the system is a retention-lock compliance system

Чи можна використовувати реплікацію проти MTrees , у яких увімкнено блокування утримання?
Так, заблоковані MTrees або файли можуть бути відтворені за допомогою різних топологій реплікації:     
  • Реплікація каталогів - підтримується лише для файлів, що використовують режим управління - не реплікує мінімальні та максимальні періоди зберігання в цільову систему.
  • Реплікація MTree - може використовуватися як для даних, так і для даних режиму відповідності, і реплікує мінімальні та максимальні періоди зберігання в цільову систему.
  • Реплікація збору - може використовуватися як для даних, так і для даних режиму відповідності, і реплікує мінімальні та максимальні періоди зберігання в цільову систему.
Примітка: Для збереження утримуючих замків на системах призначення:
  • Як вихідна, так і цільова системи повинні мати відповідні встановлені ліцензії на блокування збереження.
  • У контекстах реплікації MTree для параметра "Proplication propagate-retention-lock" має значення "Увімкнено".
  • Для файлів, відтворених шляхом реплікації каталогів, відповідні мінімальні та максимальні періоди зберігання MTrees повинні бути встановлені вручну в системі призначення.
Чи існують інші обмеження під час реплікації файлів із заблокованим зберіганням?
Так, повторна синхронізація контекстів реплікації (тобто спроба відновити раніше налаштований, але пошкоджений контекст), де використовуються заблоковані дані, може зазнати невдачі.
 
Примітка:
  • Якщо використовується реплікація MTree, а адресат MTree містить файли, заблоковані під час збереження, які не існують на джерелі, повторна синхронізація не вдається.
  • Якщо використовується реплікація каталогів, а цільова сторінка має блокування збереження, яке ввімкнено, а джерело — ні, то повторна синхронізація не вдається.
Примітка: При використанні реплікації MTree повторна синхронізація успішна в наступних сценаріях, якщо цільова MTree не містить файлів, заблокованих при збереженні, відсутніх на вихідному DDR:
  • У вихідному MTree не ввімкнено блокування утримання, але місце призначення має.
  • У MTree призначення не увімкнено блокування утримання, але джерело має.
Також неможливо ввімкнути режим відповідності блокуванню утримання на MTree, який вже є учасником контексту реплікації MTree. У цьому сценарії:
  • Контекст реплікації MTree повинен бути розбитий як на вихідних, так і на цільових системах:
# replication break mtree://[destination system]/data/col1/[mtree]
  • Новий контекст реплікації MTree повинен бути створений як у вихідних, так і в цільових системах:
# replication add source mtree://[source system]/data/col1/[mtree] destination mtree://[destination system/data/col1/[mtree]
  • У системі джерела має бути ввімкнено режим відповідності блокуванню утримання:
# mtree retention-lock enable mode compliance mtree [mtree]
  • Новостворений контекст реплікації має бути повторно синхронізований у вихідній системі:
# replication resync mtree://[destination system/data/col1/[mtree]

Чи можна швидко копіювати файли, заблоковані під час утримання?
Так, файли, які заблоковано при зберіганні, можна швидко копіювати у звичайному режимі. Якщо в адресаті MTree, що утримує швидку копію, увімкнено блокування збереження, то блокування збереження файлу зберігається проти швидкої копії. Якщо в адресаті MTree не ввімкнено блокування утримання, то швидка копія не блокується при зберіганні.

Чи є інші обмеження у функціональності системи при використанні retention lock?
У системах, що використовують режим відповідності блокуванню утримання, заборонено виконувати такі команди:
# user reset
# filesys destroy
# filesys archive unit del [archive unit name]
Такі системи не можуть бути завантажені в однокористувацький режим для відновлення технічною підтримкою без використання USB-накопичувача та фізичного доступу до системи.

Наступні команди заборонені проти MTrees, які використовують режим відповідності блокуванню утримання:
# mtree delete [mtree]
# mtree retention-lock reset [min-retention-period period | max-retention-period period] mtree [mtree]
# mtree retention-lock disable mtree [mtree]
# mtree retention-lock revert
Однак у DDOS 7.3 і пізніших версіях було передбачено можливість видаляти MTrees із підтримкою Retention Lock Compliance, якщо:
  • DD працює під управлінням DDOS 7.3 або новішої версії.
  • RLCE MTree, який потрібно видалити, порожній (не містить файлів і каталогів).
  • Адміністратор успішно проходить аутентифікацію співробітника служби безпеки.
У системах, налаштованих з функцією довгострокового утримання (Cloud Tier), аналогічні руйнівні команди також можуть бути заборонені, наприклад:
# cloud unit del <cloud unit name>
Примітка: MTrees, що використовують режим управління збереженням блокування (або де цей режим колись був включений), можуть бути видалені тільки після того, як MTree не містить файлів - якщо в MTree залишилися якісь файли, повертається помилка.

Чи важливий системний годинник у системах із підтримкою блокування утримання?
Так, системи з підтримкою відповідності замків збереження вмикають внутрішній «годинник безпеки», щоб запобігти зловмисному втручанню в роботу системного годинника (що може дозволити достроково видаляти файли, заблоковані під час збереження). Час роботи охоронного та системного годинника регулярно порівнюється, і якщо між ними протягом одного календарного року накопичується 2-тижневий перекіс, файлова система домену даних (DDFS) автоматично вимикається для запобігання доступу до даних на DDR. Це може статися і в тому випадку, якщо системний годинник раптово змінився і час змінилося більш ніж на 2 тижні.

У цьому сценарії DDFS можна повторно ввімкнути за допомогою:
  • Вхід в DDR
  • Перевірте, чи правильно встановлено системний годинник.
  • Увімкнення файлової системи:
    # filesys enable
  • Коли з'явиться запит, введіть дані користувача з роллю безпеки, щоб дозволити скидання охоронного годинника, і ввімкніть DDFS.
Чи можна синхронізувати системний годинник з Active Directory в системах
із підтримкою збереження замка?Ні, коли ввімкнено відповідність блокуванню збереження, сервери CIFS більше не синхронізують системний час з Active Directory. Якщо між системою та Active Directory різниця в часі перевищує п'ять хвилин, сервер CIFS відображає повідомлення про помилку, коли користувач Active Directory намагається увійти в систему або система намагається приєднатися до домену Active Directory. Налаштуйте час Active Directory за допомогою NTP, щоб уникнути цієї помилки.

Це на відміну від систем, де відповідність вимогам блокування утримання не ввімкнено, але використовується Active Directory.  У цій ситуації не рекомендується включати NTP, оскільки між Active Directory та NTP можуть виникнути конфлікти часових налаштувань.

Які кроки можна вжити, якщо файл DDR, який використовує файли з блокуванням утримання, заповнюється на повну потужність?
Припускаючи, що на DDR немає «чистого» простору (чистота запущена, але система залишається заповненою вщерть), його вміст слід переглянути, щоб визначити, чи:
  • Є будь-які файли, які не заблоковані при зберіганні, які можна видалити.
  • Є будь-які файли, які заблоковано за допомогою режиму керування, блокування яких може бути скасовано та видалено.
Як тільки це буде зроблено, clean слід знову запустити, щоб фізично звільнити місце в системі. Крім того, якщо жодні фізичні дані не можуть бути видалені з системи, до DDR слід додати додаткове фізичне сховище та розширити файлову систему (за умови, що розширення підтримується поточною DDR або конфігурацією).

Якщо єдині файли в системі заблоковано в режимі відповідності, скасувати блокування та видалити ці файли неможливо. В результаті простір не в змозі звільнитися, якщо:
  • Термін зберігання настає для деяких або всіх файлів. Після цього моменту їх можна видалити і запустити в чисту воду (як було описано вище).
  • Система перевстановлюється з USB-накопичувача (що викликає втрату всіх даних на DDR).
  • У систему додається більше фізичного сховища (як описано вище).
Примітка: Цілком можливо повністю заповнити DDR файлами, заблокованими за допомогою режиму відповідності. У цьому сценарії адміністратор або технічна підтримка нічого не можуть зробити, щоб звільнити місце (тобто немає низькорівневої функціональності для видалення/скасування блокувань режиму відповідності та раннього видалення відповідних файлів).

文書のプロパティ


影響を受ける製品

Data Domain, Data Domain Retention Lock

製品

Data Domain

最後に公開された日付

18 7月 2024

バージョン

17

文書の種類

Solution