Data Domain: Aplikacja do tworzenia kopii zapasowych zintegrowana z funkcją Retention Lock może napotykać awarie kopii zapasowej z powodu problemu z konfiguracją

Niektóre zadania tworzenia kopii zapasowych na kliencie kopii zapasowej nie powiodą się i są wysyłane komunikaty takie 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 nazywa funkcję zaplecza DD, która pozwala administratorowi ustawić okres, w którym plik znajdujący się w wewnętrznej fazie przetwarzania danych nie może zostać zmodyfikowany lub usunięty w celu ochrony przed przypadkowym lub złośliwym usunięciem danych. Funkcja ta jest nazywana blokadą retencji domeny danych (RL w skrócie).

Po stronie DD dzienniki pokazują następujące elementy 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 DD RL dla każdego pojedynczego M-drzewa, które ma włączoną funkcję, obejmuje ustawienie minimalnego (minimalnego okresu retencji blokady) i maksymalnego czasu (retention-lock max-retention-period) blokad, które mogą być ustawione na dowolnym z plików w MTree. W przypadku DD RL aplikacja do tworzenia kopii zapasowych musi indywidualnie ustawiać blokadę plików, chyba że włączona jest funkcja DD Automatic Retention Lock (ARL). Opcje dla M-drzewa 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 M-drzewie RL można ustawić tylko 720 minut od bieżącego czasu (lub dłuższego) i 35 dni od bieżącego czasu (lub krótszego). Innymi słowy, w przypadku 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 (wykonywana przez aktualizację pliku atime, w przypadku korzystania z BOOST; za pośrednictwem połączenia "ddp_utime") na krótszy lub dłuższy czas będzie skutkować błędem przedstawionym 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 zapisu kopii zapasowej do obrazu w wewnętrznej łatce, a następnie ostatecznie ustaw blokadę na obrazie kopii zapasowej (lub obrazy, ponieważ niektóre oprogramowanie może używać więcej niż jednego pliku do przechowywania jednego zadania tworzenia kopii zapasowej). Biblioteki BOOST będą używane do nazywania "ddp_utime", aby ustawić blokadę na czas trwania równy przewidywanemu przechowywaniu kopii zapasowych na poziomie aplikacji do tworzenia kopii zapasowych. Ma to dwie konsekwencje:

• Jeśli czas nie jest zsynchronizowany między aplikacją do tworzenia kopii zapasowej a DD, aplikacja do tworzenia kopii zapasowych może obliczać wartość "X days from now" i uzyskać datę i godzinę, która nie jest dokładnie taka sama jak w przypadku DD, co skutkowałoby blokowaniem obrazu kopii zapasowej na krótszy lub dłuższy czas w zależności od różnicy czasu
• Jeśli planowane przechowywanie kopii zapasowej nie jest zgodne z limitami RL w DD MTree, aplikacja do tworzenia kopii zapasowych może próbować ustawić blokadę zbyt daleko w przyszłości (przez okres dłuższy niż "okres maksymalnej retencji blokady" i dlatego ustawienie blokady zostanie odrzucone. Jeśli, na przykład, przechowywanie aplikacji do tworzenia kopii zapasowych wynosi 60 dni, a "retention-lock max-retention-period" ustawiono na 30 dni w DD, ustawienie blokady oczywiście zakończy się niepowodzeniem

W sytuacjach, w których zachowywanie oprogramowania do tworzenia kopii zapasowych jest równe okresowi maksymalnego retencji blokady na DD, wszelkie niewielkie różnice czasowe 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 zapasowej miały prawidłowy czas, a zatem były synchronizowane za pośrednictwem protokołu NTP lub (jeśli dotyczy) usługi Windows AD.

Aby uniknąć przypadków narożnych, takich jak opisane, dobrą praktyką jest, że "okres maksymalnego retencji blokady" w M-drzewie z obsługą RL jest ustawiony na nieco dłuższy niż najdłużej zachowujący się zasady tworzenia kopii zapasowych przechowywane w tym M-drzewie. Na przykład, jeśli przechowywanie danych jest ustawione na 35 dni w aplikacji do tworzenia kopii zapasowych, ustawienie "Retention-lock max-retention-period" na DD MTree używane do przechowywania tych zasad na 36 lub nawet 40 dni jest właściwym sposobem, aby uniknąć przypadkowych awarii ustawienia RL.

Uwaga: "Okres maksymalnej retencji blokady" większy niż okres przechowywania obrazów kopii zapasowych nie stanowi problemu. W przypadku 100 dni "retention-lock max-retention-period" dla 35-dniowej zasady przechowywania kopii zapasowej, po 35 dniach obrazy zostaną usunięte przez aplikację, a wyczyszczenie spowoduje usunięcie zużytego miejsca przy następnym uruchomieniu. Jedyną wadą jest przypadkowe ustawienie obrazów z dłuższą blokadą, z obsługą RL nie będzie można usunąć plików dłużej niż oczekiwano. Zaleca się zatem ustawienie "retention-lock max-retention-period" nieco dłużej, ale nie zbyt wiele.