Data Domain: Hoe NetWorker werkt met Data Domain en Cloud Tier

NetWorker (NW) heeft ingebouwde ondersteuning voor Data Domain Cloud Tier (DD CT). Dit betekent dat de NW-beheerder beleidsregels kan instellen voor tiering naar de cloud: NW markeert afzonderlijke back-upimages, zodat DD-dataverplaatsing naar de cloud later wordt uitgevoerd en deze bestanden naar de geconfigureerde cloudeenheid worden verzonden.

Het eerste belangrijke feit om te benadrukken is dat NW geen data verplaatst of kopieert (klonen) naar de cloud. Er worden kopieën (klonen) van SSID's gemaakt die naar de cloud moeten worden verzonden, maar de klonen bevinden zich (in eerste instantie) in de DD Active-laag. Pas nadat het geconfigureerde DD-schema voor dataverplaatsing in werking treedt, moet de SSID die is gemarkeerd voor (tiered to) cloud naar cloudstorage worden verzonden.

Het hele proces van het maken van een back-up tot het punt waarop die SSID beschikbaar is in de cloud werkt ongeveer zoals hieronder:

1. NW is geconfigureerd voor het opslaan van back-ups op een DD (opname vindt altijd plaats op de DD Active-laag). Daarvoor wordt meestal één storage-eenheid gebruikt:

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. Binnen NetWorker wordt elk back-upbeleid opgeslagen onder wat NetWorker een 'apparaat' noemt. Een apparaat bevindt zich slechts een submap onder de hoofdmap van de storage-eenheid, bijvoorbeeld:

/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

Hier zijn de beleidsregels of apparaten "DAILY-DB-DEV01", "DAILY-DB-DEV02", "MONTHLY-DB-DEV01" en "MONTHLY-FS-DEV06".

3. NW wordt uiteindelijk geconfigureerd voor DD CT en resulteert in een door de app beheerde configuratie voor dataverplaatsing in het DD, zoals hieronder:

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

Voor de configuratie van DD-dataverplaatsing naar de cloud is een bron-MTree (de NW-storage-eenheid), een doelcloudeenheid (CLOUD-UNIT) en een beleid nodig, die voor NetWorker (en Avamar) moeten worden "app-managed", in plaats van "age-threshold", omdat voor welke bestanden naar de cloud moet worden verplaatst, worden bepaald (gemarkeerd) door NW, niet gekozen op basis van de leeftijd van de bestanden zelf.

4. De manier waarop NW voor DD CT werkt, "markeert" geen bestanden die naar de cloud moeten worden verplaatst op hun oorspronkelijke locatie: Wanneer de klant NW instelt voor cloudopslaglagen, moet de klant een ander apparaat maken binnen dezelfde storage-eenheid, waar de bestanden die naar de cloud moeten worden verzonden, eerst door NW worden gekloond. Een bepaalde SSID die is geconfigureerd om te worden opgeslagen in de DD CT, wordt bijvoorbeeld weergegeven als twee afzonderlijke (maar identieke) bestanden in een DD-bestandslocatierapport:

# 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

Uit de bovenstaande informatie blijkt dat:

• Back-upimage met lange SSID "365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56" is geschreven naar de DD Active-laag en voor het laatst geschreven naar in "Thu May 30 04:00:59 2024", onder apparaatnaam "MONTHLY-FS-DEV05"
• Er bestaat een tieringbeleid (met een doelapparaat) met de naam "CLOUD-LONG-TERM-DEV04/"
• Toen het tieringbeleid werd uitgevoerd (dit gebeurt waarschijnlijk al nadat de back-up is voltooid), is er een kopie (kloon) van de SSID gemaakt van het oorspronkelijke apparaat naar het NW-cloudapparaat met de naam "CLOUD-LONG-TERM-DEV04"
• DD data-movement werd uiteindelijk uitgevoerd en de kloon van de oorspronkelijke back-up werd verplaatst van Active naar de cloudeenheid, waarbij het proces voor het bestand voltooid was door "Sat Jun 1 11:13:33 2024"
• Op het moment dat de bovenstaande bestandslocatie-informatie werd verzameld, bestaat er een kopie van dezelfde lange SSID in zowel de Active- als de Cloud DD-lagen
• Het is aan NW om de individuele kopieën te laten verlopen en te verwijderen wanneer deze verschuldigd zijn, in theorie zal de kopie in de actieve laag eerder verlopen zijn dan die in de cloud, die langer moet worden bewaard (anders zou het zinloos zijn om die back-upafbeelding in de eerste plaats naar de cloud te sturen)

5. In de NetWorker-documentatie wordt gevraagd dat het Cloud Tier-apparaat in de NW-wizard wordt gemaakt onder dezelfde storage-eenheid als de bestanden in de actieve laag. Het maken van het cloudapparaat op een andere storage-eenheid kan ertoe leiden dat de klonen worden uitgevoerd met andere dan "fastcopy", wat resulteert in veel langzamere kloontijden. Dit is de toepasselijke sectie in de NW-documentatie:
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. Een van de implicaties van de bovenstaande verklaring uit de NW-documentatie is dat in een NetWorker/Data Domain-installatie met cloudlaag gewoonlijk alle data worden opgeslagen in dezelfde storage-eenheid binnen het DD en dat er geen ondersteunde manier is om NW-back-upimages naar twee afzonderlijke cloudeenheden te verzenden. De configuratie voor verplaatsing van DD-gegevens kan niet meer dan één beleid hebben voor dezelfde bron-Mtree, wat een probleem kan vormen in situaties zoals bijvoorbeeld de capaciteit voor de eerste cloudeenheid die maximaal is (zie hieronder voor een voorbeeld):

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. Wanneer een klant de bovenstaande beperking probeert te omzeilen, kan hij een nieuwe NetWorker-storage-eenheid maken voor toekomstige back-ups. Of ze klonen van de bestaande storage-eenheid naar een apparaat in de nieuwe, en voegen later een tweede DD-beleid voor dataverplaatsing toe van de nieuwe storage-eenheid naar de nieuwe cloudeenheid. Dit resulteert in een configuratie zoals hieronder:

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

Naast de eis van de NW-documentatie is het probleem dat het klonen traag zal zijn. Mogelijk ziet u ook iets als dit in DD SSP (systeemshowprestaties):

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

Wanneer NW "fastcopy" gebruikt voor de klonen (wat gebeurt voor klonen binnen dezelfde opslageenheid), zouden we geen leesbelasting moeten zien. Hier zien we het omdat de kloon over opslageenheden wordt gedaan door NW via "filecopy", en in het geval van dit voorbeeld was het zelfs nog erger dan dat:

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

Hier gebeurt een kloon voor SSID "d2b98e7a-00000006-4f5a1067-665a1067-88e55000-e36c9c56":

• Vanaf apparaat "MONTHLY-FS-DEV06" in de oorspronkelijke storage-eenheid met de naam (NW-STORAGE-UNIT), wordt de READ-taak uitgevoerd vanaf NW-knooppunt met de naam "nw-node1.example.com"
• Naar het apparaat met de naam "CLOUD-LONG-TERM02-DEV07" onder de nieuwe storage-eenheid (NW-STORAGE-UNIT-CT), de WRITE-taak die wordt uitgevoerd naar NW-knooppunt met de naam "nw-node2.example.com"

Deze lezing had gegevens die uit het DD in het netwerk kwamen, waarbij het klantnetwerk van het ene NW-knooppunt naar het andere werd doorkruist, dat vervolgens dezelfde stroom bytes gebruikte om een nieuw bestand naar hetzelfde DD te schrijven van waar ze in de eerste plaats vandaan kwamen.

8. Een geval zoals in het voorbeeld (NW-configuratie met een enkele opslageenheid en DD CT met de wolkeneenheid die al vol is) is de juiste configuratie voor NW het maken van een nieuwe wolkeneenheid in het DD.
Dit voorkomt het maken van een tweede storage-eenheid in de DD en het maken van een nieuw cloudopslagbeleid in NW naar een ander apparaat binnen dezelfde bestaande storage-eenheid.
Vervolgens wordt de configuratie voor DD-dataverplaatsing voor aankomende dataverplaatsing uitgevoerd om de nieuwe cloudeenheid als doel te hebben.
De uiteindelijke configuratie aan de DD-zijde ziet er als volgt uit:

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

Wanneer zowel het bestaande als het nieuwe NW-opslagbeleid wordt uitgevoerd, worden klonen van de savesets gemaakt die naar de cloud moeten worden verzonden en worden de klonen gemaakt binnen dezelfde storage-eenheid onder een ander apparaat (submap), en de bestanden binnen de NW-cloudapparaten worden gemarkeerd voor gegevensverplaatsing.

Wanneer DD-dataverplaatsing volgens planning verloopt, worden alle bestanden in de enkele NW-storage-eenheid weergegeven en bepaald of ze in aanmerking komen (gemarkeerd) voor dataverplaatsing en nog niet in een cloudeenheid staan. Ongeacht de subdirectory (apparaat) bevinden ze zich in de DD; alle gemarkeerde bestanden voor gegevensverplaatsing die zich nog niet in een cloudeenheid bevinden, worden om de beurt afzonderlijk naar de doelcloudeenheid (CLOUD-UNIT02) verzonden.

Nadat een bestand naar de cloud is gekopieerd en door de DD is geverifieerd, wordt het bestand "geïnstalleerd", wat betekent dat de DD het bestand CH (Content Handle) wijzigt om de fysieke locatie van het bestand aan te geven (om het in staat te stellen de gegevens voor het bestand in de actieve laag of in een van de twee cloudeenheden te lokaliseren).

Wanneer de back-upapplicatie later bestanden in de cloud probeert te lezen of op te roepen, is de fysieke locatie van de data van het bestand transparant voor NW, omdat de DD precies weet waar de data vandaan moet worden gelezen. Dit is losgekoppeld van de huidige configuratie voor verplaatsing van DD-data.


9. Ten slotte heeft de klant in het voorbeeld de NW-documentatie in het begin niet gevolgd (ernstige prestatieproblemen met NW-klonen ervaren) en eindigde met een SSID die drie keer was opgeslagen (één keer in Active en één keer in elk van de twee cloudeenheden), wat prima is (hoewel het een verspilling van ruimte kan zijn, afhankelijk van het geconfigureerde bewaarbeleid):

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

Er zijn drie kopieën van hetzelfde bestand, waarvan er twee zijn verplaatst naar de cloud, één naar elk van de cloudeenheden.
Wanneer NW van een van hen probeert te lezen, weet DD waar ze zich bevinden en doet het transparant wat nodig is om de gegevens terug te leveren aan NW zonder enig verschil in vergelijking met een situatie met alleen een actieve laag.
Elk van de drie bestanden is uiteindelijk verlopen en verwijderd door NW.

Er zijn drie kopieën van hetzelfde bestand, waarvan er twee zijn verplaatst naar de cloud, één naar elk van de cloudeenheden.
Wanneer NW van een van hen probeert te lezen, weet de DD precies waar elk van hen zich bevindt en zal het transparant doen wat nodig is om de gegevens terug te leveren aan NW zonder enig verschil in vergelijking met een situatie met alleen een actieve laag.
Elk van de drie bestanden zal uiteindelijk verlopen (en verwijderd) worden door NW.