Data Domain: Jak NetWorker współpracuje z Data Domain i Cloud Tier

Rozwiązanie NetWorker (NW) ma wbudowaną obsługę Data Domain Cloud Tier (DD CT). Oznacza to, że administrator NW może ustawić zasady dla tworzenia warstw w chmurze: NW oznacza poszczególne obrazy kopii zapasowych, aby później ruch danych DD do chmury przebiegał i wysyłał te pliki do skonfigurowanej jednostki chmury.

Pierwszym ważnym faktem, na który należy zwrócić uwagę, jest to, że NW nie przenosi ani nie kopiuje (nie klonuje) danych do chmury. Tworzy kopie (klony) identyfikatorów SSID do wysłania do chmury, ale klony znajdują się (początkowo) w warstwie aktywnej DD. Dopiero po wdrożeniu skonfigurowanego harmonogramu ruchu danych DD identyfikator SSID oznaczony dla chmury ma zostać wysłany do pamięci masowej w chmurze.

Cały proces od wykonania kopii zapasowej do momentu, w którym ten identyfikator SSID jest dostępny w chmurze, działa bardzo podobnie do poniższego:

1. NW skonfigurowano do przechowywania kopii zapasowych w DD (przyswajanie zawsze następuje do aktywnej warstwy DD). Zazwyczaj wykorzystuje się do tego pojedynczą jednostkę pamięci masowej:

DDBOOST Storage-Unit Show Type BoostFS
-------------------------

Name                   Pre-Comp (GiB)   Status   User            Report Physical   BoostFS
                                                                    Size (MiB)
--------------------   --------------   ------   -------------   ---------------   -------
NW-STORAGE-UNIT            25680542.0   RW       boostuser                    -    no
--------------------   --------------   ------   -------------   ---------------   -------

2. W NetWorker każda zasada tworzenia kopii zapasowych jest przechowywana w obszarze, który NetWorker nazywa „urządzeniem”. Urządzenie to tylko podkatalog podrzędny pod katalogiem głównym jednostki pamięci masowej, na przykład:

/data/col1/NW-STORAGE-UNIT/DAILY-DB-DEV01/00/80/ee140226-00000006-2b625ef6-66625ef6-0e095000-e36c9c56
/data/col1/NW-STORAGE-UNIT/DAILY-DB-DEV02/00/48/f8959462-00000006-3f775a89-66775a89-b8fa5000-e36c9c56
/data/col1/NW-STORAGE-UNIT/MONTHLY-DB-DEV01/03/93/30e0c543-00000006-3d5cac26-665cac26-f6f75000-e36c9c56
/data/col1/NW-STORAGE-UNIT/MONTHLY-FS-DEV06/92/30/05729157-00000006-cc5a6431-665a6431-9e685000-e36c9c56

W tym miejscu zasady lub urządzenia to „DAILY-DB-DEV01”, „DAILY-DB-DEV02”, „MONTHLY-DB-DEV01” i „MONTHLY-FS-DEV06”.

3. NW ostatecznie skonfigurowano dla DD CT, powodując konfigurację ruchu danych zarządzaną przez aplikację w DD, taką jak poniżej:

Cloud Data-Movement Configuration
---------------------------------
Mtree                             Target(Tier/Unit Name)   Policy        Value
-------------------------------   ----------------------   -----------   -------
/data/col1/NW-STORAGE-UNIT        Cloud/CLOUD-UNIT         app-managed   enabled
-------------------------------   ----------------------   -----------   -------

Konfiguracja przenoszenia danych DD do chmury pobiera źródłowe drzewo MTree (jednostkę pamięci masowej NW), docelową jednostkę chmury (CLOUD-UNIT) oraz zasady, które dla NetWorker (i Avamar) muszą być „zarządzane przez aplikację”, a nie przez „próg wieku”, ponieważ pliki do przeniesienia do chmury są określane (oznaczane) przez NW, a nie wybierane na podstawie wieku samych plików.

4. Sposób, w jaki NW działa dla DD CT, nie powoduje „oznaczenia” plików do przeniesienia do chmury w ich pierwotnej lokalizacji: Gdy klient ustawi NW dla warstw chmury, klient musi najpierw utworzyć inne urządzenie w tej samej jednostce pamięci masowej, do którego najpierw zostaną sklonowane pliki wysyłane do chmury. Na przykład dany identyfikator SSID, który jest skonfigurowany do przechowywania w DD CT, pojawi się jako dwa oddzielne (ale identyczne) pliki w raporcie lokalizacji pliku DD:

# filesys report generate file-location tiering
--------------------------------                                                                                  ----------------------      -----         ---------------------------
File Name                                                                                                         Location(Unit Name)         Size          Placement Time
--------------------------------                                                                                  ----------------------      -----         ---------------------------
/data/col1/NW-STORAGE-UNIT/MONTHLY-FS-DEV05/85/72/365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56                        Active         1.15 TiB      Thu May 30 04:00:59 2024
/data/col1/NW-STORAGE-UNIT/CLOUD-LONG-TERM-DEV04/85/72/365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56               CLOUD-UNIT         1.15 TiB      Sat Jun  1 11:13:33 2024

Z powyższych informacji wynika, że:

• Obraz kopii zapasowej z długim identyfikatorem SSID „365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56” został zapisany w warstwie aktywnej DD, a ostatnio zapisany w „Thu May 30 04:00:59 2024” pod nazwą urządzenia „MONTHLY-FS-DEV05”
• Istnieje zasada tworzenia warstw (z urządzeniem docelowym) o nazwie „CLOUD-LONG-TERM-DEV04/”
• Po uruchomieniu zasad tworzenia warstw (prawdopodobnie nastąpi to zaraz po zakończeniu tworzenia kopii zapasowej) wykonano kopię (klon) identyfikatora SSID z oryginalnego urządzenia do urządzenia w chmurze NW o nazwie „CLOUD-LONG-TERM-DEV04”
• Ostatecznie uruchomiono przenoszenie danych DD, a klon oryginalnej kopii zapasowej został przeniesiony z pozycji Aktywna do jednostki w chmurze, proces został zakończony dla pliku przed „Sat Jun 1 11:13:33 2024”
• W momencie zbierania powyższych informacji o lokalizacji pliku istniała kopia tego samego długiego identyfikatora SSID zarówno w warstwie Aktywna, jak i DD w chmurze
• Wygaśnięcie i usunięcie poszczególnych kopii w odpowiednim czasie będzie zależało od NW, teoretycznie kopia w warstwie aktywnej wygaśnie wcześniej niż kopia w chmurze, która ma być przechowywana dłużej (w przeciwnym razie wysyłanie tego obrazu kopii zapasowej do chmury w ogóle nie miałoby sensu)

5. Dokumentacja NetWorker monituje, aby urządzenie warstwy chmury w kreatorze NW zostało utworzone w tej samej jednostce pamięci masowej, co pliki w warstwie aktywnej. Utworzenie urządzenia w chmurze na innej jednostce pamięci masowej może spowodować, że klony zostaną wykonane przy użyciu innej kopii niż „szybka kopia”, co spowoduje znacznie wolniejsze klonowanie. To właściwa sekcja w dokumentacji NW:
https://www.dell.com/support/manuals/en-us/networker/nw_p_ddboostdedup_integration/configuring-networker-devices-for-dd-cloud-tier?guid=guid-680d906f-10c7-4266-822e-1a0f3ba3e201⟨=en-us
 

Configuring NetWorker devices for DD Cloud Tier
-----------------------------------------------
Use the Device Configuration Wizard to configure NetWorker devices for the DD Cloud Tier devices.

The Data Domain devices that contain the source backup data must reside on the same mtree as the DD Cloud Tier device that will store the clone data. The storage node that manages the Data Domain devices must be a NetWorker 19.7 storage node. 

6. Jedna z implikacji powyższego stwierdzenia z dokumentacji NW jest taka, że w konfiguracji NetWorker / Data Domain z warstwą chmury zwykle wszystkie dane są przechowywane w tej samej jednostce pamięci masowej w ramach DD i nie ma obsługiwanego sposobu wysyłania obrazów kopii zapasowych NW do dwóch oddzielnych jednostek chmury. Konfiguracja ruchu danych DD nie może mieć więcej niż jednej zasady dla tego samego źródłowego obiektu MTree, co może stanowić problem w takich sytuacjach, jak na przykład maksymalna pojemność pierwszej jednostki chmury (przykład poniżej):

Active Tier:                                                                                       
Resource           Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*                        
----------------   --------   ---------   ---------   ----   --------------                        
/data: pre-comp           -   8477328.0           -      -                -                        
/data: post-comp   944180.2    769927.8    174252.4    82%          90605.3                        
----------------   --------   ---------   ---------   ----   --------------                        

Cloud Tier unit-wise space usage                                                                   
--------------------------------                                                                   
CLOUD-UNIT                                                                                         
Resource             Size GiB     Used GiB   Avail GiB   Use%   Cleanable GiB                      
----------------   ----------   ----------   ---------   ----   -------------                      
/data: pre-comp             -   16935910.0           -      -               -                      
/data: post-comp   1572768.4*    1572755.0        13.4   100%             0.0                      
----------------   ----------   ----------   ---------   ----   -------------                      

Cloud Data-Movement Configuration                                        
---------------------------------                                        
Mtree                      Target(Tier/Unit Name)   Policy        Value  
------------------------   ----------------------   -----------   -------
/data/col1/NW-STORAGE-UNIT Cloud/CLOUD-UNIT         app-managed   enabled
------------------------   ----------------------   -----------   -------

7. Podczas próby pokonania powyższego ograniczenia klient może utworzyć nową jednostkę pamięci masowej NetWorker dla przyszłych kopii zapasowych. Może też wykonać klony istniejącej jednostki pamięci masowej na urządzeniu w nowej, a następnie dodać drugą zasadę ruchu danych DD z nowej jednostki pamięci masowej do nowej jednostki w chmurze. Kończy się to następującą konfiguracją:

Cloud Unit List
---------------
Name           Profile              Status   Reason
------------   ------------------   ------   -------------------------------
CLOUD-UNIT     CLOUD-UNIT_profile   Active   Cloud unit connected and ready.  <<-- existing Cloud Unit
CLOUD-UNIT02   CLOUD-UNIT_profile   Active   Cloud unit connected and ready.  <<-- new Cloud Unit
------------   ------------------   ------   -------------------------------

Cloud Data-Movement Configuration
---------------------------------
Mtree                             Target(Tier/Unit Name)   Policy        Value
-------------------------------   ----------------------   -----------   -------
/data/col1/NW-STORAGE-UNIT          Cloud/CLOUD-UNIT         app-managed   enabled
/data/col1/NW-STORAGE-UNIT-NEW      Cloud/CLOUD-UNIT02       app-managed   enabled
-------------------------------   ----------------------   -----------   -------

Poza wymogiem z dokumentacji NW, problem polega na tym, że klonowanie będzie powolne. Ponadto w DD SSP (system show performance) może pojawić się coś takiego:

                     -----------Throughput (MB/s)----------- ---------------Protocol-----------------  Compression  ------Cache Miss--------  -----------Streams-----------  -MTree Active-  ----State---  -----Utilization-----  --Latency-- 
                                                                                                                                                                       Repl
Date       Time      Read  Write Repl Network  Repl Pre-comp ops/s    load    data(MB/s)    wait(ms/MB)  gcomp lcomp  thra unus ovhd data meta    rd/  wr/  r+/  w+/  in/ out      rd/wr      'CDPVMSFIRL'     CPU        disk       in ms     stream   
---------- --------  ----- ----- ----in/out--- ----in/out--- -----    --%--   --in/out---   --in/out---  ----- -----  ---- ---- ---- ---- ----  ----------------------------- --------------  -----------  -avg/max---- --max---  --avg/sdev-  -----------
2024/06/13 18:27:00    0.0    0.0   0.00/  0.00   0.00/  0.00     2   NaN%   0.00/  0.00  20.97/ 37.46    1.7   1.7    0%   0%  21%   0%   2%     0/   0/   0/   0/   0/   0       0/ 0       ---V---I---    6%/  8%[13]  7%[28]  2.1/  7.5  116.0/  2.2 
2024/06/13 18:37:00    0.0    0.0   0.00/  0.00   0.00/  0.00    89   NaN%   0.01/  0.01  19.45/ 68.12    2.8   2.1    0%   0%  21%   0%   1%     0/   0/   0/   0/   0/   0       0/ 0       ---V---I---    5%/  6%[4]   7%[28]  0.7/  3.7  115.8/  3.0 
2024/06/13 18:47:00   39.6   39.5   0.00/  0.00   0.00/  0.00  1160   NaN%   0.54/ 37.82   4.27/  0.42   62.5   1.7    0%   0%  11%   0%   1%     1/   1/   0/   0/   0/   0       1/ 1       ---V---I---    5%/  7%[4]   7%[28]  0.4/  3.0  118.8/  3.4 
2024/06/13 18:57:00  215.5  215.5   0.00/  0.00   0.00/  0.00   825   NaN%   0.93/205.66   4.29/  0.30  291.2   1.2    0%   0%   7%   0%   1%     1/   1/   0/   0/   0/   0       1/ 1       ---V---I---    7%/  9%[14]  8%[28]  0.1/  3.8  118.8/  3.7 
2024/06/13 19:07:00  223.9  223.9   0.00/  0.00   0.00/  0.00   856   NaN%   0.94/213.74   4.32/  0.29  327.5   1.1    0%   0%   7%   0%   1%     1/   1/   0/   0/   0/   0       1/ 1       ---V---I---    7%/  9%[14]  8%[28]  0.1/  0.8  118.5/  4.4 
2024/06/13 19:17:00  218.5  218.5   0.00/  0.00   0.00/  0.00  1916   NaN%   1.01/208.56   5.34/  0.32  278.3   1.3    0%   0%   9%   0%   1%     1/   1/   0/   0/   0/   0       1/ 1       ---V---I---    7%/  9%[4]   8%[28]  0.2/  3.7  118.2/  3.6 
2024/06/13 19:27:00  174.3  174.3   0.00/  0.00   0.00/  0.00   696   NaN%   2.25/166.37   2.02/  0.30   64.7   1.5    0%   1%  19%   0%   1%     1/   1/   0/   0/   0/   0       0/ 2       ---V---I---    8%/ 12%[13]  9%[28]  0.4/  6.5  121.5/  4.6 
2024/06/13 19:37:00  182.6  183.5   0.00/  0.00   0.00/  0.00   719   NaN%   5.40/174.31   1.24/  0.29   34.8   1.1    2%   6%  28%   0%   3%     1/   3/   0/   0/   0/   0       0/ 2       ---V---I---    8%/ 11%[43] 12%[28]  0.3/  6.0  121.8/  6.9 
...
2024/06/20 15:39:00  150.4  293.6   0.00/  0.00   0.00/  0.00   6716  NaN%  25.47/146.12   1.39/  0.59   11.8   1.0    1%   0%  19%   0%   4%     0/   2/   0/   0/   0/   0       0/ 2       ---V---I---    7%/ 13%[15]  5%[14]  0.2/  1.0  119.2/  4.0 
2024/06/20 15:49:00  215.9  298.8   0.00/  0.00   0.00/  0.00  12448  NaN%  31.55/212.33   1.60/  0.65    9.8   1.0    2%   0%   0%   0%   2%     0/   2/   0/   0/   0/   0       0/ 2       ---V---I---    8%/ 15%[15]  4%[21]  0.2/  0.5  117.5/  2.7 
2024/06/20 15:59:00  186.5  344.3   0.00/  0.00   0.00/  0.00   1854  NaN%  24.07/178.14   1.04/  0.33   14.6   1.0    5%   0%  21%   0%   2%     1/   2/   0/   0/   0/   0       0/ 2       ---V---I---    6%/ 14%[15]  5%[ 3]  0.4/  4.4  119.2/  2.3 
2024/06/20 16:09:00  205.3  426.2   0.00/  0.00   0.00/  0.00    808  NaN%  18.73/196.08   1.09/  0.30   24.4   1.0    4%   5%  27%   0%   3%     0/   2/   0/   0/   0/   0       0/ 2       ---V---I---    6%/ 14%[47]  5%[ 3]  0.3/  0.3  117.5/  2.6 
2024/06/20 16:19:00  211.7  399.3   0.00/  0.00   0.00/  0.00    843  NaN%  17.86/202.10   1.09/  0.29   23.5   1.0    2%   0%   0%   0%   2%     1/   2/   0/   0/   0/   0       0/ 2       ---V---I---    6%/ 13%[15]  3%[ 3]  0.3/  4.8  119.2/  1.8 
...                                                                                        
2024/06/23 18:21:00  470.3  484.6   0.00/  0.00   0.00/  0.00   1807  NaN%   9.85/448.86   2.59/  0.30   50.2   1.1    1%  21%  34%   0%   0%     4/   5/   0/   0/   0/   0       0/ 2       ---V---I---    7%/ 11%[9]   9%[13]   0.2/  1.5  126.8/  8.8 
2024/06/23 18:31:00  477.2  494.6   0.00/  0.00   0.00/  0.00   1846  NaN%   8.99/455.44   2.69/  0.29   57.3   1.1    1%  13%  27%   0%   0%     4/   5/   0/   0/   0/   0       0/ 2       -------I---    5%/  9%[0]   7%[17]   0.2/  1.7  127.0/  6.8 
2024/06/23 18:41:00  458.9  481.3   0.00/  0.00   0.00/  0.00   2913  NaN%  10.17/438.07   2.57/  0.30   48.3   1.1    1%  12%  28%   0%   0%     4/   5/   0/   0/   0/   0       0/ 2       -------I---    5%/  8%[0]   7%[ 3]   0.2/  1.2  127.0/  5.8 
2024/06/23 18:51:00  468.7  481.2   0.00/  0.00   0.00/  0.00   1807  NaN%  10.60/447.40   2.27/  0.29   46.5   1.1    1%  19%  34%   0%   1%     4/   5/   0/   0/   0/   0       0/ 2       -------I---    7%/  9%[9]   9%[ 3]   0.2/  1.5  127.0/  5.6 
2024/06/23 19:01:00  474.0  485.5   0.00/  0.00   0.00/  0.00   1814  NaN%  14.32/452.44   1.99/  0.29   33.6   1.1    2%  26%  39%   0%   0%     4/   5/   0/   0/   0/   0       0/ 2       ---V---I---    6%/ 10%[15] 11%[ 3]   0.2/  1.5  126.2/  6.4

Gdy NW używa „szybkiej kopii” dla klonów (co ma miejsce w przypadku klonów w tej samej jednostce pamięci masowej), nie powinniśmy widzieć obciążenia odczytu. Tutaj je widzimy, ponieważ klonowanie między jednostkami pamięci masowej jest wykonywane przez NW poprzez „szybką kopię”, a w przypadku tego przykładu było jeszcze gorzej:

06/19 08:24:14.178358 [7fbbf6b4a390] ddboost-<nw-node1.example.com-52424>: JOB START IMAGE_READ ip=10.20.30.40 pid=1727382 cd=1 enc=off //NW-STORAGE-UNIT/MONTHLY-FS-DEV06/03/54/d2b98e7a-00000006-4f5a1067-665a1067-88e55000-e36c9c56

06/19 08:24:14.286608 [7facd6691b70] ddboost-<nw-node2.example.com-58788>: JOB START IMAGE_WRITE ip=10.20.30.40 pid=18392 cd=1 enc=off //NW-STORAGE-UNIT-CT/CLOUD-LONG-TERM02-DEV07/03/54/d2b98e7a-00000006-4f5a1067-665a1067-88e55000-e36c9c56

Tutaj powstaje klon identyfikatora SSID „d2b98e7a-00000006-4f5a1067-665a1067-88e55000-e36c9c56”:

• Z urządzenia „MONTHLY-FS-DEV06” w oryginalnej jednostce pamięci masowej o nazwie (NW-STORAGE-UNIT), gdzie zadanie READ jest wykonywane z węzła NW o nazwie „nw-node1.example.com”
• Do urządzenia o nazwie „CLOUD-LONG-TERM02-DEV07” w nowej jednostce pamięci masowej (NW-STORAGE-UNIT-CT), gdzie zadanie WRITE jest wykonywane w węźle NW o nazwie „nw-node2.example.com”

Ten odczyt powodował, że dane wychodziły z DD do sieci, przechodząc przez sieć klienta z jednego węzła NW do drugiego, który następnie wykorzystuje ten sam strumień bajtów do zapisania nowego pliku w tej samej DD, z której pochodzą.

8. W przypadku takim jak w przykładzie (konfiguracja NW z pojedynczą jednostką pamięci masowej i DD CT z już pełną jednostką chmury) prawidłową konfiguracją dla NW jest utworzenie nowej jednostki chmury w DD.
Pozwala to uniknąć utworzenia drugiej jednostki pamięci masowej w DD i nowych zasad tworzenia warstw chmury w NW dla innego urządzenia w tej samej istniejącej jednostce pamięci masowej.
Następnie zachodzi zmiana konfiguracji przenoszenia danych DD dla nadchodzących przebiegów przenoszenia danych, aby nowa jednostka chmury była obiektem docelowym.
Ostateczna konfiguracja po stronie DD wygląda następująco:

Cloud Unit List
---------------
Name           Profile              Status   Reason
------------   ------------------   ------   -------------------------------
CLOUD-UNIT     CLOUD-UNIT_profile   Active   Cloud unit connected and ready.  <<-- existing Cloud Unit
CLOUD-UNIT02   CLOUD-UNIT_profile   Active   Cloud unit connected and ready.  <<-- new Cloud Unit
------------   ------------------   ------   -------------------------------

Cloud Data-Movement Configuration
---------------------------------
Mtree                             Target(Tier/Unit Name)   Policy        Value
-------------------------------   ----------------------   -----------   -------
/data/col1/NW-STORAGE-UNIT        Cloud/CLOUD-UNIT02       app-managed   enabled  <<-- target cloud unit changed from "CLOUD-UNIT"
-------------------------------   ----------------------   -----------   -------

Po uruchomieniu zarówno istniejących, jak i nowych zasad tworzenia warstw NW, utworzą one klony zestawów zapisów do wysłania do chmury, klony zostaną wykonane w tej samej jednostce pamięci masowej na innym urządzeniu (podkatalogu), a pliki w „urządzeniach w chmurze” NW zostaną oznaczone do przenoszenia danych.

Gdy przenoszenie danych DD przebiegnie zgodnie z harmonogramem, zostaną wyświetlone wszystkie pliki w pojedynczej jednostce pamięci masowej NW i zostanie określone, czy kwalifikują się (są oznaczone) do przenoszenia danych, nie będąc jeszcze w żadnej jednostce chmury. Bez względu na podkatalog (urządzenie), w którym się znajdują w obrębie DD, wszystkie pliki oznaczone do przenoszenia danych, które nie znajdują się jeszcze w jednostce chmury, zostaną z kolei indywidualnie wysłane do docelowej jednostki chmury (CLOUD-UNIT02).

Po pomyślnym skopiowaniu pliku do chmury i zweryfikowaniu przez DD plik zostanie „zainstalowany”, co oznacza, że DD zmienia CH (Content Handle) pliku, aby wskazać fizyczną lokalizację pliku (aby umożliwić zlokalizowanie danych pliku w warstwie aktywnej lub w dowolnej z dwóch jednostek chmury).

Gdy później aplikacja do tworzenia kopii zapasowych próbuje odczytać lub przywołać pliki w chmurze, fizyczna lokalizacja danych pliku jest niewidoczna dla NW, ponieważ DD dokładnie wie, skąd odczytać dane. Jest to oddzielone od bieżącej konfiguracji ruchu danych DD.


9. Wreszcie, klient w przykładzie nie postępował zgodnie z dokumentacją NW na początku (doświadczył poważnych problemów z wydajnością klona NW) i skończyło się na trzykrotnym zapisaniu pewnego identyfikatora SSID (raz w aktywnej i raz w każdej z dwóch jednostek chmury), co nie jest błędem (chociaż może powodować marnowanie miejsca w zależności od skonfigurowanych zasad przechowywania):

--------------------------------                                                                                  ----------------------      -----         ---------------------------
File Name                                                                                                         Location(Unit Name)         Size          Placement Time
--------------------------------                                                                                  ----------------------      -----         ---------------------------
/data/col1/NW-STORAGE-UNIT/MONTHLY-FS-DEV05/85/72/365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56                        Active         1.15 TiB      Thu May 30 04:00:59 2024
/data/col1/NW-STORAGE-UNIT/CLOUD-LONG-TERM-DEV04 /85/72/365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56              CLOUD-UNIT         1.15 TiB      Sat Jun  1 11:13:33 2024
/data/col1/NW-STORAGE-UNIT-CT/CLOUD-LONG-TERM02-DEV07/85/72/365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56        CLOUD-UNIT02         1.15 TiB      Tue Jun 18 10:49:10 2024

Istnieją trzy kopie tego samego pliku, z których dwie zostały przeniesione do chmury, po jednej do każdej jednostki chmury.
Gdy NW próbuje odczytać dane z którejkolwiek z nich, DD wie, gdzie znajduje się każda z nich, i w przejrzysty sposób robi to, co trzeba, aby dostarczyć dane z powrotem do NW bez żadnej różnicy w porównaniu z sytuacją tylko z warstwą aktywną.
Każdy z tych trzech plików jest ostatecznie wygasły i zostanie usunięty przez NW.

Istnieją trzy kopie tego samego pliku, z których dwie zostały przeniesione do chmury, po jednej do każdej jednostki chmury.
Gdy NW próbuje odczytać dane z którejkolwiek z nich, DD dokładnie wie, gdzie znajduje się każda z nich, i w przejrzysty sposób zrobi to, co konieczne, aby dostarczyć dane z powrotem do NW bez żadnej różnicy w porównaniu z sytuacją tylko z warstwą aktywną.
Każdy z tych trzech plików będzie ostatecznie wygasły (i zostanie usunięty) przez NW.