Data Domain: Funktionsweise von NetWorker mit Data Domain und Cloud Tier

NetWorker (NW) bietet integrierte Unterstützung für Data Domain Cloud Tier (DD CT). Das bedeutet, dass NW-AdministratorInnen Policies für das Tiering in die Cloud festlegen können: NW markiert einzelne Backup-Images, sodass später eine DD-Datenverschiebung in die Cloud ausgeführt und diese Dateien an die konfigurierte Cloudeinheit gesendet werden.

Die erste wichtige Tatsache, die betont werden sollte, ist, dass NW keine Daten in die Cloud verschiebt oder kopiert (klont). Er werden Kopien (Clones) von SSIDs erstellt, die an die Cloud gesendet werden, aber die Clones befinden sich (zunächst) im DD Active-Tier. Erst nachdem der konfigurierte Zeitplan für die DD-Datenverschiebung in Kraft getreten ist, soll die für die Verschiebung zur Cloud markierte SSID an den Cloud-Storage gesendet werden.

Der gesamte Vorgang von der Erstellung eines Backups bis zu dem Punkt, an dem diese SSID in der Cloud verfügbar ist, läuft wie folgt ab:

1. NW ist so konfiguriert, dass Backups auf einer DD gespeichert werden (Aufnahme erfolgt immer auf dem DD Active Tier). In der Regel wird dafür eine einzige Storage-Einheit verwendet:

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. In NetWorker wird jede Backup-Policy unter einem von NetWorker sogenannten „Gerät“ gespeichert. Ein Gerät ist nur ein Unterverzeichnis unterhalb des Stammverzeichnisses der Storage-Einheit, z. B.:

/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 wären die Policys oder Geräte „DAILY-DB-DEV01“, „DAILY-DB-DEV02“, „MONTHLY-DB-DEV01“ und „MONTHLY-FS-DEV06“.

3. NW wird schließlich für DD CT konfiguriert, was eine von der App verwaltete Konfiguration der Datenverschiebung in der DD ergibt, wie im Folgenden gezeigt:

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

Die Konfiguration der DD-Datenverschiebung in die Cloud verwendet einen Quell-MTree (die NW-Storage-Einheit), eine Ziel-Cloudeinheit (CLOUD-UNIT) und eine Policy, die für NetWorker (und Avamar) „app-gemanagt“ anstelle von „Altersschwellenwerte“ sein muss, da die in die Cloud zu verschiebenden Dateien von NW bestimmt (markiert) und nicht anhand des Alters der Dateien selbst ausgewählt werden.

4. So wie NW für DD CT funktioniert, werden Dateien, die in die Cloud verschoben werden sollen, an ihrem ursprünglichen Speicherort nicht „markiert“: Wenn der Kunde NW für Cloud-Tiering festlegt, muss er ein anderes Gerät innerhalb derselben Storage-Einheit erstellen, in dem die an die Cloud zu sendenden Dateien zuerst vom NW geklont werden. Beispielsweise wird eine bestimmte SSID, die für die Speicherung im DD CT konfiguriert ist, als zwei separate (aber identische) Dateien in einem DD-Dateispeicherortbericht angezeigt:

# 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

Die obigen Informationen zeigen Folgendes:

• Das Backup-Image mit der langen SSID „365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56“ wurde in den DD Active Tier geschrieben und zuletzt am „Thu May 30 04:00:59 2024“ unter dem Gerätenamen „MONTHLY-FS-DEV05“ beschrieben.
• Es ist eine Tiering-Policy (mit einem Zielgerät) namens „CLOUD-LONG-TERM-DEV04/“ vorhanden.
• Beim Ausführen der Tiering-Policy (dies geschieht wahrscheinlich, sobald das Backup abgeschlossen ist) wurde eine Kopie (Clone) der SSID vom ursprünglichen Gerät im NW-Cloudgerät mit dem Namen „CLOUD-LONG-TERM-DEV04“ erstellt.
• Die DD-Datenverschiebung wurde schließlich ausgeführt und der Clone des ursprünglichen Backups wurde von Active in die Cloud-Einheit verschoben. Der Prozess für die Datei wurde am „Sat Jun 1 11:13:33 2024“ abgeschlossen.
• Zu dem Zeitpunkt, an dem die obigen Informationen über den Dateispeicherort erfasst wurden, war eine Kopie derselben langen SSID sowohl in der aktiven als auch in der Cloud DD-Tier vorhanden.
• Es ist Sache von NW, die einzelnen Kopien bei Fälligkeit ablaufen zu lassen und zu löschen. Theoretisch läuft die Kopie im aktiven Tier früher ab als die in der Cloud, die länger aufbewahrt werden muss (da es sonst von vornherein sinnlos wäre, das Backup-Image in die Cloud zu übertragen).

5. In der NetWorker-Dokumentation wird verlangt, dass das Cloud-Tier-Gerät im NW-Assistenten unter derselben Storage-Einheit wie die Dateien im aktiven Tier erstellt wird. Das Erstellen des Cloudgeräts auf einer anderen Storage-Einheit kann dazu führen, dass die Clones anderweitig als mit „fastcopy“ erstellt werden, was zu viel längeren Cloningzeiten führt. Dies ist der entsprechende Abschnitt in der NW-Dokumentation: 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. Eine der Folgerungen der obigen Aussage aus der NW-Dokumentation ist, dass in einem NetWorker-/Data Domain-Setup mit Cloud-Tier in der Regel alle Daten in derselben Storage-Einheit innerhalb der DD gespeichert werden und es keine unterstützte Methode gibt, NW-Backup-Images an zwei separate Cloud-Einheiten zu senden. Die Konfiguration der DD-Datenverschiebung kann nicht mehr als eine Policy für denselben Quell-MTree haben, was in Situationen wie z. B. der ausgereizten Kapazität für die erste Cloudeinheit ein Problem darstellen kann (siehe nachstehendes Beispiel):

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. Beim Versuch, die oben genannte Einschränkung zu umgehen, können KundInnen eine neue NetWorker-Storage-Einheit für anstehende Backups erstellen. Oder sie können die Clones von der vorhandenen Storage-Einheit auf einem Gerät in der neuen Storage-Einheit erstellen und später eine zweite DD-Datenverschiebungs-Policy von der neuen Storage-Einheit auf der neuen Cloudeinheit hinzufügen. Dies ergibt eine Konfiguration wie die folgende:

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

Neben der Anforderung aus der NW-Dokumentation besteht das Problem darin, dass das Klonen langsam erfolgt. Möglicherweise wird in DD SSP (System Show Performance) auch Folgendes angezeigt:

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

Wenn NW „fastcopy“ für die Clones verwendet (was bei Clones innerhalb derselben Storage-Einheit der Fall ist), sollte kein Lesevorgang erfolgen. Hier sehen wir es, weil das Klonen über Storage-Einheiten hinweg von NW mit „filecopy“ durchgeführt wird, was in diesem Fall sogar noch schlimmer war:

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 wird ein Klon für die SSID „d2b98e7a-00000006-4f5a1067-665a1067-88e55000-e36c9c56“ erstellt:

• Vom Gerät „MONTHLY-FS-DEV06“ in der ursprünglichen Storage-Einheit namens (NW-STORAGE-UNIT) wird der READ-Job vom NW-Node namens „nw-node1.example.com“ ausgeführt
• Auf das Gerät mit dem Namen „CLOUD-LONG-TERM02-DEV07“ unter der neuen Storage-Einheit (NW-STORAGE-UNIT-CT), der SCHREIB-Job, der auf dem NW-Node namens „nw-node2.example.com“ ausgeführt wird

Bei diesem Lesevorgang wurden Daten aus der DD in das Netzwerk geleitet und über das Kundennetzwerk von einem NW-Node zu einem anderen geleitet, der dann denselben Strom von Bytes verwendet, um eine neue Datei in dieselbe DD zu schreiben, von der diese ursprünglich stammten.

8. In einem Fall wie im Beispiel (NW-Konfiguration mit einer einzelnen Storage-Einheit und DD CT mit bereits voll belegter Cloudeinheit) wird bei einer richtigen Konfiguration von NW eine neue Cloudeinheit in der DD erstellt.
Dadurch wird vermieden, dass eine zweite Storage-Einheit in der DD erstellt wird und eine neue Cloud-Tiering-Policy in NW auf einem anderen Gerät innerhalb derselben vorhandenen Storage-Einheit erstellt wird.
Dann wird die Konfiguration der DD-Datenverschiebung für kommende Datenverschiebungsläufe so geändert, dass die neue Cloud-Einheit das Ziel ist.
Die endgültige DD-seitige Konfiguration sieht wie folgt aus:

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

Wenn sowohl die vorhandenen als auch die neuen NW-Tiering-Policies ausgeführt werden, erstellen sie Clones der Savesets, die an die Cloud gesendet werden sollen, die Clones werden innerhalb derselben Storage-Einheit unter einem anderen Gerät (Unterverzeichnis) erstellt und die Dateien innerhalb der NW-„Cloudgeräte“ werden für die Datenverschiebung markiert.

Wenn die DD-Datenverschiebung wie geplant ausgeführt wird, werden alle Dateien in der einzelnen NW-Storage-Einheit aufgelistet und es wird bestimmt, ob sie für die Datenverschiebung qualifiziert (markiert) sind und sich noch in keiner Cloudeinheit befinden. Unabhängig davon, in welchem Unterverzeichnis (Gerät) sie sich innerhalb der DD befinden, werden alle für die Datenverschiebung markierten Dateien, die sich noch nicht in einer Cloud-Einheit befinden, einzeln an die Ziel-Cloudeinheit (CLOUD-UNIT02) gesendet.

Nachdem eine Datei erfolgreich in die Cloud kopiert und von der DD überprüft wurde, wird die Datei „installiert“, was bedeutet, dass die DD den Datei-CH (Content Handle) so ändert, dass dieser den physischen Speicherort der Datei angibt (damit die Daten für die Datei entweder im aktiven Tier oder in einer der beiden Cloudeinheiten gefunden werden können).

Wenn die Backupanwendung später versucht, Dateien in der Cloud zu lesen oder abzurufen, ist der physische Speicherort der Dateidaten für NW sichtbar, da die DD genau weiß, von wo die Daten zu lesen sind. Dies ist von der aktuellen DD-Datenverschiebungskonfiguration entkoppelt.


9. Schließlich hat der/die KundIn im Beispiel die NW-Dokumentation am Anfang nicht befolgt (es traten schwerwiegende NW-Clone-Performanceprobleme auf) und am Ende wurden einige SSIDs dreimal gespeichert (einmal in der Active- und einmal in jeder der beiden Cloudeinheiten), was völlig in Ordnung ist (obwohl es je nach konfigurierten Aufbewahrungspolicies eine Verschwendung von Speicherplatz sein kann):

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

Es gibt drei Kopien derselben Datei, von denen zwei in die Cloud verschoben wurden, eine in jede der Cloudeinheiten.
Wenn NW versucht, aus einer von ihnen zu lesen, weiß DD, wo sich jede einzelne befindet, und liefert die Daten auf transparente Weise wie erforderlich und ohne Unterschied im Vergleich zu einer Situation mit nur einem aktiven Tier wieder an NW.
Jede der drei Dateien läuft irgendwann ab und wird von NW gelöscht.

Es gibt drei Kopien derselben Datei, von denen zwei in die Cloud verschoben wurden, eine in jede der Cloudeinheiten.
Wenn NW versucht, aus einer von ihnen zu lesen, weiß DD, wo sich jede einzelne befindet, und liefert die Daten auf transparente Weise wie erforderlich und ohne Unterschied im Vergleich zu einer Situation mit nur einem aktiven Tier wieder an NW.
Jede der drei Dateien läuft irgendwann ab und wird von NW gelöscht.