Data Domain: Sådan fungerer NetWorker med Data Domain og Cloud Tier

Summary: NetWorker (NW) har indbygget understøttelse af Data Domain Cloud Tier (DD CT). Der er misforståelser og terminologiske sammenstød, som denne artikel behandler.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

NetWorker (NW) har indbygget understøttelse af Data Domain Cloud Tier (DD CT). Det betyder, at NW-administratoren kan angive politikker for niveauinddeling til clouden: NW markerer individuelle sikkerhedskopieringsbilleder, så DD-dataflytning til cloud senere kører og sender disse filer til den konfigurerede cloudenhed.

Den første vigtige kendsgerning at fremhæve er, at NW ikke flytter eller kopierer (klon) data til skyen. Det opretter kopier (kloner) af SSID'er, der skal sendes til skyen, men klonerne sidder (oprindeligt) i DD Active-niveauet. Det er først, når den konfigurerede DD-dataflytningsplan starter, når det SSID, der er markeret for (lagdelt til) skyen, skal sendes til skylager.

Hele processen fra at tage en sikkerhedskopi til det punkt, hvor SSID er tilgængeligt i skyen, fungerer meget som nedenfor:

Cause

1. NW er konfigureret til at gemme sikkerhedskopier på en DD (indtagelse forekommer altid på niveauet DD Active). Den bruger typisk en enkelt lagerenhed til det: 
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. I NetWorker gemmes hver sikkerhedskopieringspolitik under det, NetWorker kalder en "enhed". En enhed er blot en undermappe under roden af lagerenheden, f.eks.: 
/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
Her vil politikkerne eller enhederne være "DAILY-DB-DEV01", "DAILY-DB-DEV02", "MONTHLY-DB-DEV01" og "MONTHLY-FS-DEV06".

3. NW konfigureres til sidst til DD CT og resulterer i en app-administreret dataflytningskonfiguration for dataflytning i DD som nedenfor: 
Cloud Data-Movement Configuration
---------------------------------
Mtree                             Target(Tier/Unit Name)   Policy        Value
-------------------------------   ----------------------   -----------   -------
/data/col1/NW-STORAGE-UNIT        Cloud/CLOUD-UNIT         app-managed   enabled
-------------------------------   ----------------------   -----------   -------
DD-dataflytningskonfiguration til cloud kræver et kilde-MTree (NW-lagerenheden), en cloud-destinationsenhed (CLOUD-UNIT) og en politik, som for NetWorker (og Avamar) skal være "app-administreret" i stedet for "aldersgrænse", da de filer, der skal flyttes til clouden, bestemmes (markeres) af NW og ikke vælges af filernes alder.

4. På den måde NW fungerer for DD CT, "markeres" det ikke filer, der skal flyttes til skyen på deres oprindelige placering: Når kunden indstiller NW til cloudniveauinddeling, skal kunden oprette en anden enhed i den samme storageenhed, hvor de filer, der skal sendes til clouden, først klones af NW. For eksempel vises et givet SSID, der er konfigureret til at blive gemt i DD CT, som to separate (men identiske) filer i en DD-filplaceringsrapport: 
# 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
Ovenstående oplysninger viser, at:
  • Sikkerhedskopieringsbillede med langt SSID "365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56" blev skrevet til DD Active-niveauet og senest skrevet til i "Thu May 30 04:00:59 2024" under enhedsnavnet "MONTHLY-FS-DEV05"
  • Der findes en niveauinddelingspolitik (med en destinationsenhed) med navnet "CLOUD-LONG-TERM-DEV04/"
  • Da niveauinddelingspolitikken blev kørt (dette sker sandsynligvis, så snart sikkerhedskopieringen er fuldført), blev der lavet en kopi (klon) af SSID'et fra den oprindelige enhed til NW-cloudenheden med navnet "CLOUD-LONG-TERM-DEV04"
  • DD-dataflytning blev til sidst kørt, og klonen af den oprindelige sikkerhedskopi blev flyttet fra Active til cloudenheden, processen blev fuldført for filen af "Sat Jun 1 11:13:33 2024"
  • På det tidspunkt, hvor oplysningerne om filplaceringen ovenfor blev indsamlet, findes der en kopi af det samme lange SSID på både aktivt og cloud DD-niveau
  • Det vil være op til NW at udløbe og slette de enkelte kopier, når de forfalder, i teorien vil kopien i Active tier udløbe tidligere end den i skyen, som skal opbevares i længere tid (ellers ville det være meningsløst at sende det sikkerhedskopibillede til skyen i første omgang)

5. NetWorker-dokumentationen beder om, at Cloud Tier-enheden i NW-guiden oprettes under den samme lagerenhed som filerne på det aktive niveau. Oprettelse af skyenheden på en anden lagerenhed kan medføre, at klonerne udføres ved hjælp af andet end "fastcopy", hvilket resulterer i meget langsommere kloningstider. Dette er det relevante afsnit i NW-dokumentationen:
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. En af implikationerne af erklæringen ovenfor fra NW-dokumentationen er, at i en NetWorker/Data Domain-opsætning med cloudniveau gemmes alle data normalt i den samme lagerenhed i DD, og der er ingen understøttet måde at sende NW-sikkerhedskopieringsbilleder til to separate cloudenheder. DD-dataflytningskonfigurationen kan ikke have mere end én politik for det samme kilde-Mtree, hvilket kan udgøre et problem i situationer som f.eks. kapaciteten for den første cloudenhed, der skal maksimeres (se nedenfor for et eksempel): 
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
------------------------   ----------------------   -----------   -------

Resolution

7. Når en kunde forsøger at overvinde ovenstående begrænsning, kan vedkommende oprette en ny NetWorker-storageenhed til kommende sikkerhedskopieringer. Eller de kan udføre klonerne fra den eksisterende lagerenhed til en enhed i den nye og senere tilføje en anden DD-dataflytningspolitik fra den nye lagerenhed til den nye skyenhed. Dette ender med en konfiguration som nedenfor: 
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
-------------------------------   ----------------------   -----------   -------

Udover kravet fra NW-dokumentationen er problemet, at kloningen vil være langsom. Du kan også se noget som dette i DD SSP (system show performance): 
                     -----------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

Når NW bruger "fastcopy" til klonerne (hvilket er hvad der sker for kloner inden for samme lagerenhed), bør vi ikke se en læsebelastning. Her ser vi det, fordi klonen på tværs af lagerenheder udføres af NW gennem "filecopy", og i tilfældet med dette eksempel var det endnu værre end det: 
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
Her sker en klon for SSID "d2b98e7a-00000006-4f5a1067-665a1067-88e55000-e36c9c56":
  • Fra enheden "MONTHLY-FS-DEV06" i den oprindelige lagerenhed med navnet (NW-STORAGE-UNIT) udføres READ-jobbet fra NW-noden med navnet "nw-node1.example.com"
  • Til enheden med navnet "CLOUD-LONG-TERM02-DEV07" under den nye lagerenhed (NW-STORAGE-UNIT-CT) udføres WRITE-jobbet til NW-noden med navnet "nw-node2.example.com"
Denne læsning havde data, der kom ud af DD til netværket og krydsede kundenetværket fra en NW-node til en anden, som derefter bruger den samme strøm af bytes til at skrive en ny fil til den samme DD, hvorfra de kom fra i første omgang.

8. I et tilfælde som i eksemplet (NW-konfiguration med en enkelt lagerenhed og DD CT, hvor cloudenheden allerede er fuld) er den korrekte konfiguration for NW at oprette en ny cloudenhed i DD.
På den måde undgår du at oprette en ekstra storageenhed i DD og oprette en ny cloudniveauinddelingspolitik i NW til en anden enhed inden for den samme eksisterende storageenhed.
Derefter ændres DD-dataflytningskonfigurationen for kommende dataflytningskørsler, så den får den nye cloudenhed som mål.
Endelig DD-sidekonfiguration ser sådan ud: 
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"
-------------------------------   ----------------------   -----------   -------
Når både den eksisterende og den nye NW-niveauinddelingspolitik kører, opretter de kloner af de savesets, der skal sendes til clouden, og klonerne oprettes i den samme lagerenhed under en anden enhed (underbibliotek), og filerne i NW's "cloudenheder" markeres til dataflytning.

Når DD-dataflytning kører som planlagt, vises alle filer i den enkelte NW-storageenhed og bestemmes, om de er berettiget (markeret) til dataflytning og endnu ikke i nogen cloudenhed. Uanset undermappe (enhed) er de inden for DD, alle markerede filer til dataflytning, der ikke er i en skyenhed, men sendes individuelt til målskyenheden (CLOUD-UNIT02) igen.

Når en fil er kopieret til skyen og verificeret af DD, bliver filen "installeret", hvilket betyder, at DD ændrer filen CH (Content Handle) for at angive filens fysiske placering (for at give den mulighed for at finde dataene for filen i enten det aktive niveau eller i en af de to skyenheder).

Når sikkerhedskopieringsprogrammet senere forsøger at læse eller tilbagekalde filer i skyen, er den fysiske placering af filens data gennemsigtig for NW, da DD ved præcis, hvor dataene skal læses fra. Dette er afkoblet fra den aktuelle DD-dataflytningskonfiguration.


9. Endelig fulgte kunden i eksemplet ikke NW-dokumentation i begyndelsen (oplevede alvorlige problemer med NW-klonydelse) og endte med noget SSID gemt tre gange (en gang i aktiv og en gang i hver af de to skyenheder), hvilket er helt fint (selvom det kan være spild af plads afhængigt af de konfigurerede opbevaringspolitikker): 
--------------------------------                                                                                  ----------------------      -----         ---------------------------
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

Der er tre kopier af den samme fil, hvoraf to er blevet flyttet til skyen, en til hver af skyenhederne.
Når NW forsøger at læse fra nogen af dem, ved DD, hvor hver enkelt er, og transparentlys gør efter behov for at levere dataene tilbage til NW uden nogen forskel sammenlignet med en situation med kun et Active-niveau.
Hver af de tre filer er til sidst udløbet og slettet af NW.

Der er tre kopier af den samme fil, hvoraf to er blevet flyttet til skyen, en til hver af skyenhederne.
Når NW forsøger at læse fra nogen af dem, ved DD præcis, hvor hver enkelt af dem er, og vil gennemsigtigt gøre efter behov for at levere dataene tilbage til NW uden nogen forskel sammenlignet med en situation med kun et Active-niveau.
Hver af de tre filer vil til sidst blive udløbet (og slettet) af NW.

Affected Products

Data Domain
Article Properties
Article Number: 000226881
Article Type: Solution
Last Modified: 19 Aug 2024
Version:  2
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.