Data Domain: Aplikacja do tworzenia kopii zapasowych zintegrowana z blokadą retencji może doświadczać awarii kopii zapasowych z powodu problemu z konfiguracją

Niektóre zadania tworzenia kopii zapasowych kończą się niepowodzeniem na kliencie tworzenia kopii zapasowych z komunikatami takimi jak:
 

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.

Tryb "tylko do odczytu" dla kopii zapasowych i obrazów to sposób, w jaki to konkretne oprogramowanie do tworzenia kopii zapasowych wywołuje funkcję zaplecza DD, która umożliwia administratorowi ustawienie okresu, w którym plik w zapleczu nie może być modyfikowany ani usuwany, w celu ochrony przed przypadkowym lub złośliwym usunięciem danych. Funkcję tę nazywa się Data Domain Retention Lock (w skrócie RL).

Po stronie DD dzienniki pokazują następujące informacje dla tej samej jednostki pamięci masowej, podkatalogu i pliku kopii zapasowej:

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)

Konfiguracja zabezpieczeń na poziomie wiersza DD dla każdego drzewa MTree z włączoną funkcją obejmuje ustawienie minimalnego (blokada przechowywania, min. okres przechowywania) i maksymalnego (blokada przechowywania, maks. okres przechowywania) blokad, które można ustawić dla dowolnych plików w drzewie MTree. W przypadku DD RL aplikacja do tworzenia kopii zapasowych musi indywidualnie ustawić blokadę plików, chyba że włączona jest funkcja DD Automatic Retention Lock (ARL). Opcje dla MTree w przykładzie były następujące:
 

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
-----------------------------------------   -----------

Oznacza to, że dla każdego pliku w drzewie MTree wartość wiersza może być ustawiona tylko na 720 minut od bieżącego czasu (lub dłużej) i 35 dni od bieżącego czasu (lub krótszego). Innymi słowy, przy powyższej konfiguracji plik może być chroniony przed modyfikacją lub usunięciem tylko przez okres dłuższy niż 12 godzin, ale krótszy niż 35 dni. Każda próba ustawienia blokady przez aplikację do tworzenia kopii zapasowych (która odbywa się poprzez aktualizację atime pliku przy użyciu BOOST; poprzez wywołanie "ddp_utime") na krótszy lub dłuższy czas spowoduje błąd przedstawiony powyżej:

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.

Gdy aplikacja do tworzenia kopii zapasowych wie, jak korzystać z funkcji DD RL, będzie czekać na zakończenie zapisywania kopii zapasowej na obrazie w zapleczu, a następnie ostatecznie ustawi blokadę obrazu kopii zapasowej (lub obrazów, ponieważ niektóre programy mogą używać więcej niż jednego pliku do przechowywania jednego zadania tworzenia kopii zapasowej). Biblioteki BOOST zostaną użyte do wywołania polecenia "ddp_utime" w celu ustawienia blokady na czas równy zamierzonemu przechowywaniu kopii zapasowej na poziomie aplikacji do tworzenia kopii zapasowych. Ma to dwie konsekwencje:

• Jeśli czas nie jest zsynchronizowany między aplikacją do tworzenia kopii zapasowych a DD, aplikacja do tworzenia kopii zapasowych może obliczyć "X dni od teraz" i uzyskać datę i godzinę, które nie są dokładnie takie same jak w przypadku DD, co spowoduje, że obraz kopii zapasowej zostanie zablokowany na krótszy lub dłuższy okres czasu, w zależności od znaku różnicy czasu
• Jeśli zamierzone przechowywanie kopii zapasowej nie jest zgodne z limitami RL w drzewie MTree DD, aplikacja do tworzenia kopii zapasowych może próbować ustawić blokadę zbyt daleko w przyszłości (na okres dłuższy niż "Retention-lock max-retention-period") i w związku z tym ustawienie blokady zostanie odrzucone. Jeśli na przykład przechowywanie aplikacji kopii zapasowej wynosi 60 dni z wartością "Retention-lock max-retention-period" ustawioną na 30 dni w DD, ustawienie blokady oczywiście się nie powiedzie

W sytuacjach, w których retencja oprogramowania kopii zapasowej jest równa "Retention-lock max-retention-period" na DD, wszelkie drobne różnice czasu mogą spowodować odmowę ustawienia blokady ze względu na różnicę czasu między dwoma hostami.

Ważne jest, aby wszystkie hosty w infrastrukturze kopii zapasowych miały prawidłowy czas, a co za tym idzie, aby synchronizowały się za pośrednictwem NTP lub (jeśli dotyczy) Windows AD.

Aby uniknąć przypadkowych przypadków, takich jak opisany, dobrym rozwiązaniem jest ustawienie wartości "Retention-lock max-retention-period" w drzewie MTree z obsługą zabezpieczeń na poziomie wiersza na poziomie nieco dłuższym niż zasady tworzenia kopii zapasowych z najdłuższym okresem przechowywania przechowywane w tym drzewie MTree. Na przykład, jeśli retencja danych jest ustawiona na 35 dni w aplikacji do tworzenia kopii zapasowych, ustawienie "Retention-lock max-retention-period" w DD MTree używanym do przechowywania tych zasad na 36 lub nawet 40 dni jest właściwym działaniem, aby uniknąć przypadkowych awarii ustawienia RL.

Należy pamiętać, że wartość "Retention-lock max-retention-period" wyższa niż okres przechowywania kopii zapasowych nie stanowi problemu. Jeśli mieliśmy 100 dni "Retention-lock max-retention-period" dla zasad tworzenia kopii zapasowych przechowywania 35 dni, po 35 dniach obrazy zostaną usunięte przez aplikację, a przy następnym uruchomieniu aplikacja usunie ich zajęte miejsce. Jedyną wadą jest przypadkowe ustawienie obrazów z dłuższą blokadą, przy zgodności z RL, nie będzie można usunąć plików dłużej niż oczekiwano. Dlatego zaleca się ustawienie "Retention-lock max-retention-period" nieco dłużej, ale nie za dużo.