Data Domain Restorer 和雲端長期保留：常見問題

本文解決有關設定和使用 Data Domain Restorer (DDR) 和長期保留 (LTR) 或雲端功能的常見問題。
 

什麼是 LTR？

• 從 Data Domain 作業系統 (DDOS) 6.0 開始，推出了名為 LTR 的新功能。
• LTR 可讓特定型號的 DDR 將檔案或資料子集，從一系列支援的公有雲或私有雲提供商遷移至物件或雲端儲存空間 (稱為 Cloud Tier)。
• 若要將檔案或資料實體遷移至物件儲存，會在 DDR 上執行資料移動程序。
• 若要從 Cloud Tier 實際釋放冗餘資料，會在 DDR 上執行 Cloud Tier 清理程序。
• LTR 是一項授權功能，且需要 CLOUDTIER_CAPACITY license。
• LTR 需要一些本機儲存空間來儲存 Cloud Tier 中繼資料。

LTR 適用於哪些 DDR 系統？
這取決於安裝的 DDOS 版本以及系統型號類型。大多數型號都有特定硬體需求，必須提前滿足這些需求才能設定 LTR。請參閱特定型號的硬體安裝指南，以及 DDOS 管理指南以瞭解需求。

LTR 需要哪些授權？

• 由於 LTR 被視為 DDOS 6.x 及更新版本的新功能，因此需要 elicense （電子授權）。 
• 所需的電子授權類型稱為 CLOUDTIER_CAPACITY license。範例 CLOUDTIER_CAPACITY license 如下：

Capacity licenses:
##   Feature              Shelf Model   Capacity     Mode        Expiration Date
--   ------------------   -----------   ----------   ---------   ---------------
1    CLOUDTIER-CAPACITY   n/a           136.42 TiB   permanent   n/a
--   ------------------   -----------   ----------   ---------   ---------------

不同層級的運作方式為何？

• 一般 DDR (沒有 LTR 授權) 有一個稱為作用層的層級。
• 作用層是所有「標準」DDR 上的傳統儲存層級。
• LTR 系統具有第二個儲存層級，稱為 Cloud Tier。

每個層級的最大大小取決於特定硬體組態和 DDOS 版本的支援限制。請參閱 DDOS 管理指南和硬體指南，以瞭解所討論的特定型號。

下面顯示了雙層 (一個作用層和一個雲端分層) LTR 組態的範例：   

Active Tier:
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   --------   --------   ---------   ----   --------------
/data: pre-comp           -    36674.6           -      -                -
/data: post-comp    65460.3      585.4     64874.8     1%              0.1
/ddvar                 29.5       24.7         3.3    88%                -
/ddvar/core            31.5        1.1        28.8     4%                -
----------------   --------   --------   ---------   ----   --------------

Cloud Tier
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB
----------------   --------   --------   ---------   ----   -------------
/data: pre-comp           -       33.1           -      -               -
/data: post-comp      912.2       42.3       869.9     5%             4.1
----------------   --------   --------   ---------   ----   -------------

Total:
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB
----------------   --------   --------   ---------   ----   -------------
/data: pre-comp           -    36674.6           -      -               -
/data: post-comp    65460.3      585.4     64874.8     1%             0.1
/ddvar                 29.5       24.7         3.3    88%               -
/ddvar/core            31.5        1.1        28.8     4%               -
----------------   --------   --------   ---------   ----   -------------

如何結構化 Cloud Tier？

• Cloud Tier 包含：   
  • 本機保留的中繼資料，如果使用實體 DDR，則儲存在機櫃中；如果使用 DDVE，則儲存在 LUN 或裝置中。
  • 物件儲存提供商
• 上述兩項整合到雲端裝置中。
• 如果設定了多個雲端裝置，則可共用本機保留的中繼資料。
• 每個系統最多可設定兩個雲端裝置。每個雲端裝置可以從不同的物件儲存提供商佈建。
• 每個雲端裝置的大小可達指定 DDR 型號支援的最大作用層大小。如需詳細資訊，請參閱 DDOS 管理指南。

設定 LTR 時，典型備份生命週期會發生什麼情況？

• 所有資料一開始都會寫入作用層，並在此層級開始老化。
• 達到保留期的短期資料會過期/刪除，如同在一般 DDR 上一樣。
• 但是，需要長期保留的資料子集會遷移至 Cloud Tier。
• 檔案系統在所有層級中維持單一命名空間，因此，當檔案遷移到雲端時，命名空間不會變更，因此，對使用者或備份應用程式保持合理透明度。
• 若已遷移到 Cloud Tier 的檔案達到其保留期，它會像其他任何檔案一樣過期/刪除。
• 檔案在 Cloud Tier 中使用的空間不會立即回收，而是必須執行 Cloud Tier 清理。

如何在各層級之間刪除重複資料？

• 每個雲端裝置都是一個獨立的磁碟區，這表示它是一個獨立的重複資料刪除裝置。
• 因此，寫入每個雲端裝置的資料只能針對相同雲端裝置中的資料進行重複資料刪除。

什麼是放置時間 (稱為 ptime)？

• 檔案和目錄具有各種與之關聯的時間戳記。
• 例如，檔案或目錄具有建立時間、上次存取時間和修改時間。
• DDOS 已進一步強化，也包括放置時間。放置時間是將檔案從作用層遷移到 Cloud Tier 的日期和時間。
• 視 DDOS 版本而定，檢查檔案所在層級時，可以看到放置時間。如果檔案已遷移至 Cloud Tier，則會顯示放置時間，例如：  

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-4        cloudunit2           Tue Sep 5 10:17:00 2017
/data/col1/mtree1/random-data-file-5        cloudunit2           Tue Sep 12 15:52:23 2017
/data/col1/mtree1/random-data-file-6        cloudunit2           Tue Sep 13 09:42:55 2017

• 雖然 ptime 不顯示欄位標題，但它仍是上述輸出中的最後一個欄位。

資料如何從作用層移動到 Cloud Tier？

• 稱為資料移動的程序負責檢查作用層中 MTree 內的檔案。
• 資料移動會先建立為資料移動而設定之所有 MTree 的快照。
• 每個檔案都有修改時間，其會儲存上次寫入檔案的時間。
• 如果之前已將檔案遷移至 Cloud Tier，則會設定稱為放置時間的額外時間欄位。放置時間會儲存將檔案遷移到 Cloud Tier 的日期和時間。如果已設置放置時間，則會使用此時間，而非修改時間。這是為了避免在回收檔案時，檔案不斷遷移回 Cloud Tier (因為回收檔案並不會變更其修改時間)。
• 資料移動會遍歷以上建立的快照。
• 如果檢查的檔案已達到定義的閾值 (如相關 MTree 的資料移動原則所設定)，則會檢查該檔案，以確認該檔案中所保留的哪些資料必須從作用層遷移到 Cloud Tier。資料移動原則依 MTree 設定。
• 所選檔案的唯一區段會寫入或複製到 Cloud Tier。 
• 複製唯一區段後，會透過讀回檔案來驗證檔案，以確保遷移成功。
• 驗證檔案後，中繼資料會更新，以反映檔案現在位於 Cloud Tier 上。
• 資料移動程序可以安排為以特定頻率執行，也可以手動啟動。

當開始資料移動時，有哪些階段？每個階段執行哪些動作？

• 與資料移動關聯的三個階段分別為複製階段、驗證階段和安裝階段。
• 複製階段負責識別必須複製到雲端的區段，然後將這些區段遷移到雲端。
• 複製階段開始後，即為雲端或物件儲存，並用作複製階段將已識別的區段從作用層複製到 Cloud Tie。
• 驗證階段負責確保檔案的區段已成功遷移到雲端。
• 安裝階段負責更新與已遷移檔案相關的中繼資料，以顯示其現在位於雲端或物件儲存上。
• 每個檔案必須完成全部三個階段，才能視為該檔案的資料移動成功。因此，在檔案的安裝階段完成之前，該檔案將保留在作用層中。

有哪些資料移動原則可用？

• 資料移動原則可以是下列其中一項：   
  • 時間閾值：如果檔案放置或修改時間超過設定的時間範圍，則會選取該檔案以遷移至 Cloud Tier。
  • 時間範圍：如果檔案放置或修改時間在特定範圍內，則會選取該檔案以遷移至 Cloud Tier。
  • 定義的應用程式：備份應用程式會指定是否要選取遷移至 Cloud Tier 的檔案。
• 原則是互斥的，即 MTree 一次只能設定一個原則。

如何在 MTree 上設定資料移動原則?

• 可以使用以下命令。例如：   

data-movement policy set <policy name> <policy type values> totier cloud cloud-unit <cloud unit name> mtrees <mtree list>

sysadmin@dd4500 # data-movement policy set age-threshold 14 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
sysadmin@dd4500 # data-movement policy set age-range min-age 14 max-age 100 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
sysadmin@dd4500 # data-movement policy set app-managed to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1

已設定哪些資料移動原則？

• 以下命令提供清單，列出哪些 MTree 已指派任何資料移動原則。例如：   

data-movement policy show

sysadmin@dd4500 # data-movement policy show
Mtree               Target(Tier/Unit Name)   Policy      Value      
-----------------   ----------------------   ---------   -----------
/data/col1/mtree1   Cloud/cloudunit1         age-range   14-100 days
-----------------   ----------------------   ---------   -----------

應用程式管理的資料移動原則如何運作？

• 所討論 MTree 的資料移動原則設定為應用程式管理。此操作可以手動完成，或是由備份應用程式使用 Data Domain REST API 介面執行。
• 備份應用程式必須為 LTR 感知。
• 備份應用程式必須使用 DD Boost，且 DD Boost 的版本必須可感知 LTR 且相容。
• 使用 DD Boost 程式庫/API，備份應用程式會將必須遷移至雲端層的檔案放置時間設定為特殊值，表示下次執行資料移動時，檔案將遷移到雲端。
• 在 Data Domain 系統上執行資料移動時，會檢查放置時間，如果設定為特殊值 (如上所述)，則會將檔案遷移至雲端。

如何手動啟動資料移動？

• 可以使用以下命令，例如：   

data-movement start

sysadmin@dd4500 # data-movement start
Data-movement started.

如何監控資料移動？

• 以下命令可用來檢查資料移動的狀態。例如：   

data-movement status

sysadmin@dd4500 # data-movement status
Data-movement to cloud tier:
----------------------------
Data-movement is initializing..

Data-movement recall:
---------------------
No recall operations found. 

• 如果正在執行資料移動，則可以使用以下命令，例如：   

data-movement watch 

sysadmin@dd4500 # data-movement watch
Data-movement: phase 1 of 3 (copying)
   92% complete; time: phase  0:08:04, total  0:08:14
      Copied (post-comp): 3.35 GiB, (pre-comp): 3.29 GiB,B,
      Files copied: 7, Files verified: 3, Files installed: 3

如何停止資料移動？

• 可以使用以下命令。例如：   

data-movement stop 

sysadmin@dd4500 # data-movement stop
Data-movement stop initiated. Run the status command to check its status.

如果有多個雲端裝置，資料移動是否可以同時執行至兩個雲端裝置？

• 否。基本上，資料移動一次只能將資料遷移到一個雲端裝置。

如何設定 LTR？

• 這是高階概觀，請參閱 DDOS 管理指南中的詳細程序。
• 新增適當的 CLOUDTIER_CAPACITY license。
• 設定系統密碼片語 (若尚未設定)。
• 啟用雲端功能。
• 為 Cloud Tier 新增中繼資料儲存空間。
• 為適當的雲端或物件儲存廠商設定雲端設定檔或設定檔。
• 新增雲端裝置。
• 為需要將資料儲存在雲端的一或多個 MTree 設定資料移動原則。
• 手動啟動資料移動或等待自動或排程的資料移動啟動。

是否可以刪除雲端裝置？若可以，如何操作？

• 警示：這會銷毀雲端裝置上保留的任何資料，因此資料無法復原，請謹慎操作。
• 請參閱本知識文件中標題為「使用者如何確定檔案所在的層級」的一節，以瞭解哪些檔案位於要刪除的雲端裝置上。
• 如果不再需要這些檔案，則應將其刪除，或是如果必須保留這些檔案，則應將其回收至作用層。
• 如果必須保留檔案，請確保已回收所有檔案後再繼續。
• 雲端裝置上不應有任何已刪除的檔案。
• 為使用此雲端裝置的一或多個 MTree 重設任何資料移動原則。
• 停用檔案系統。
• 刪除雲端裝置。這表示雲端裝置處於 DELETE_PENDING 狀態，這是設計的狀態。
• 啟用檔案系統。
• 檔案系統啟動後，會以非同步方式開始刪除雲端或物件儲存提供商中由此雲端裝置使用的所有物件。刪除所有物件後，此雲端裝置使用的貯體也會刪除。如果有許多物件，則雲端裝置可能會長時間處於 DELETE_PENDING 狀態。
• 成功移除所有物件和貯體後，雲端裝置便會從雲端裝置清單中消失。

如果因為物件儲存不再可用或連線問題而導致雲端裝置刪除失敗，會發生什麼情況？

• 請聯絡 Dell 支援，以尋求進一步的協助。

是否可以在同一系統上設定 LTR 和延長保留 (ER)？

• 否。ER 和 LTR 是互斥的功能。

如何從 Cloud Tier 釋放或清理資料？

• 其運作方式與作用層上的檔案類似
• 檔案達到其保留期後，即會從檔案系統命名空間中刪除。
• Cloud Tier 清理已排程執行。依預設，Cloud Tier 清理會在每四個作用層清理工作階段後執行。
• 若要執行 Cloud Tier 清理，要清理的雲端裝置必須至少有 1% 的多餘或可清理資料，才能啟動。這是因為任何雲端網路流量都可能收費，因此 DDR 會盡可能限制網路流量。
• Cloud Tier 以預設的 50% 清理節流執行。
• Cloud Tier 清理排程和清理節流都可以變更。
• 作用層和 Cloud Tier 清理無法同時執行。
• 如果正在執行自動或排程的 Cloud Tier 清理，則會由作用層清理搶佔。
• 如果啟動手動 Cloud Tier 清理，則在完成 Cloud Tier 清理之前，無法啟動作用層清理。
• 如果 Cloud Tier 有兩個雲端裝置，則每次排程或自動 Cloud Tier 清理時，只會清理一個雲端裝置。從 Cloud Tier 清理的角度來看，雲端裝置會以循環制運作。當有兩個雲端裝置時，必須指定從命令行執行時要清理的雲端裝置 (cloud clean start <unit-name>)
• 如果 Cloud Tier 清理無法在雲端裝置上啟動 (例如，目前雲端裝置沒有足夠的可清理資料，系統認為不值得清理)，則系統會自動嘗試從下一個雲端裝置進行清理。
• 如需更多有關雲端層級清理的資訊，請參閱下列文章 Data Domain：Data Domain Restorer (DDR) 的長期保留、Cloud Tier 清理與垃圾收集簡介

如何開始手動清理 Cloud Tier？

• 可以使用以下命令。例如：   

cloud clean start <cloud unit> 

sysadmin@dd4500 # cloud clean start cloudunit2
Cloud tier cleaning started for cloud unit "cloudunit2". Use 'cloud clean watch' to monitor progress.

如何監控 Cloud Tier 清理？

• 以下命令可用來檢查是否正在執行雲端清理。例如：   

cloud clean start <cloud unit> 

sysadmin@dd4500 # cloud clean status
Previous cloud tier cleaning attempt was unsuccessful.
 Failure reason:
cloud unit "cloudunit2" did not have sufficient cleanable data.
Cloud tier cleaning finished at 2017/03/15 12:16:06.

• 如果正在執行雲端清理，可以使用下列命令加以監控：

cloud clean watch

作用層清理是否可以與 Cloud Tier 清理同時執行？

• 否。作用層清理和 Cloud Tier 清理都使用相同的通用內部共用資料結構，需要專屬存取權。

如何顯示或變更 Cloud Tier 清理排程？

• 以下命令可用來顯示目前雲端清理排程。例如：   

cloud clean frequency show

sysadmin@dd4500 # cloud clean frequency show
Cloud tier cleaning frequency is set to run after every 4 active tier cleaning cycles.

• 以下命令可用來變更排程。例如：  

cloud clean frequency set <value>

sysadmin@dd4500 # cloud clean frequency set 3
Cloud tier cleaning frequency is set to run after every 3 active tier cleaning cycles.

如何變更或顯示 Cloud Tier 清理節流？

• 根據預設，Cloud Tier 清理節流會設定為 50%。以下命令可用於將其重設為預設節流百分比。

cloud clean throttle reset

• 以下命令可用來顯示目前雲端清理節流。例如：   

cloud clean throttle show

sysadmin@dd4500 # cloud clean throttle show
Cloud tier cleaning throttle is set to 28 percent

• 以下命令可用來變更清理節流。例如：   

cloud clean throttle set <value> 

sysadmin@dd4500 # cloud clean throttle set 20
Cloud tier cleaning throttle set to 20 percent

Cloud Tier 清理節流控制是什麼？

• Cloud Tier 清理節流的運作方式與作用層清理節流類似，因為節流限制 Cloud Tier 清理可以使用的 I/O 和 CPU 資源。
• 它不會限制網路傳輸。

為什麼 Cloud Tier 清理未如預期釋放/刪除許多物件？

• 清理將一律視為預估值。請參閱下列 KB 文章，其描述本主題的各個方面，因為其同樣適用於 Cloud Tier 中的資料：  

• 此外，還有與如何實作 Cloud Tier 相關的進一步特定詳細資訊。
• 已實作多種方法來限制雲端或物件儲存提供商的網路流量，因為這可能會產生相關費用。
• 如上所述，至少需要 1% 的資料流失才能執行清理。
• 當遍歷檔案系統以搜尋符合資料移動原則的檔案時，僅檢查中繼資料的本機副本。
• 若發現雲端或物件儲存上保留的任何區段僅包含使用者資料，則會標示為以非同步方式刪除。
• 會跳過包含至少一個即時區段的任何區段，因為 DDOS 不希望因涉及網路流量而整合少量資料。

使用者如何確定檔案所在的層級？

• 使用以下命令取得此命令產生的輸出範例：  

filesys report generate file-location

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-1        Active
/data/col1/mtree1/random-data-file-2        Active
/data/col1/mtree1/random-data-file-4        cloudunit2
/data/col1/mtree1/random-data-file-5        cloudunit2
/data/col1/mtree1/random-data-file-6        cloudunit2

檔案遷移至 Cloud Tier 後，是否可以直接讀取/存取？

• 這取決於使用的 DDOS 版本以及雲端提供商：   

• 可以直接還原檔，而無需先回收檔案。這稱為「直接還原」功能，僅限於作為雲端或物件提供商的 ECS。
• 如需有關 Avamar「直接還原」的詳細資訊，請參閱「從 Data Domain Cloud Tier 進行 Avamar 精細或檔案層級還原」白皮書。
• Avamar GLR/FLR (直接還原) 功能至少需要 Avamar 18.1 或 DDOS 6.1 的組合，且雲端提供商為 ECS。 

• 必須先回收檔案。即將資料從 Cloud Tier 遷移回作用層。
• 必須使用資料移動回收命令，將檔案從 Cloud Tier 回收至作用層，以允許從檔案讀取或修改 Cloud Tier 中的檔案。
• 如果未先回收檔案，則讀取或修改 Cloud Tier 中檔案的任何嘗試都會導致 I/O 錯誤傳回至嘗試讀取作為備份應用程式之檔案的人員。
• 某些雲端感知備份應用程式可以啟動檔案回收，否則必須手動回收檔案。
• 自 DDOS 7.7+ 起：
  • 直接還原可讓非整合式應用程式直接從 Cloud Tier 讀取檔案，而不經過作用層。
  • 選擇使用直接還原的重要考量包括：
  • 直接還原不需要整合式應用程式，且對非整合式應用程式是透明的。
  • 從 Cloud Tier 讀取不需要先複製到作用層。
  • 長條圖和統計資料可用於追蹤 Cloud Tier 的直接讀取。
  • 只有 AWS 和 ECS 雲端提供商支援直接還原。
  • 應用程式確實會遇到 Cloud Tier 延遲。
  • 直接從 Cloud Tier 讀取並未實現頻寬最佳化。

可同時回收多少個檔案？

• DDOS 6.0 支援同時佇列並回收四個檔案。
• DDOS 6.1 支援同時佇列 1,000 個檔案，以及回收回收佇列中的 4 個檔案。

根據 Data Domain 管理員指南 7.9：

• 擁有 256 GB 或更多記憶體的系統一次最多可以回收 16 個檔案。
• 記憶體小於 256 GB 的系統一次最多可回收八個檔案。
• DDVE 執行個體一次最多可回收四個檔案。

如何回收檔案？

• 可以使用以下命令回收檔案。例如：   

data-movement recall path <path-name> 

sysadmin@dd4500 # data-movement recall path /data/col1/mtree1/file1

如何回收 MTree 中的所有檔案？

• 視 DDOS 版本而定，可透過執行如下所示的命令，回收雲端中的所有檔案：   

sysadmin@dd4500 # data-movement recall mtree /data/col1/mtree1

• 如需詳細資訊，請參閱 DDOS 版本的「Dell DDOS 命令參考指南」

如何監控回收操作？

• 回收操作可以使用以下命令監控，或者在需要特定檔案時監控。例如：   

data-movement status path all

data-movement status path /data/col1/mtree/file1

sysadmin@dd4500 # data-movement status path /data/col1/mtree1/file1
Data-movement recall:
---------------------
Data-movement for  /data/col1/mtree1/file1 : phase 2 of 3
(Verifying)
80% complete; time: phase XX:XX:XX total XX:XX:XX
Copied (post-comp): XX XX, (pre-comp) XX XX 

重新命名檔案是否會導致將檔案從 Cloud Tier 回收至作用層？

• 否。如果重新命名檔案，其會保留在目前層級中。

支援哪些雲端提供商？

•  根據所使用的 DDOS 版本而定，DDOS 支援下列雲端提供商：   
• Amazon Web Services (AWS)。
• Microsoft Azure Cloud
• Dell Elastic Cloud Storage (ECS)
• Virtustream
• 如需詳細資訊，請參閱 DDOS 管理指南。

Cloud Tier 是否支援加密，是否必須取得授權？

• 是，Cloud Tier 支援加密。與作用層加密不同，這並不需要額外授權。
• 這可以在啟用或之後修改雲端功能時設定。 
• 寫入時，Cloud Tier 加密僅支援內嵌式金鑰管理員，且只有一種加密演算法可用於整個 LTR 系統。

會在雲端提供商物件存放區中建立哪些貯體？

• DDOS 會建立三個貯體
• 貯體以字串結束：

'-d0'

'-c0' 

'-m0'

• 以字串「-d0」結尾的貯體用於資料區段。
• 以字串「-c0」結尾的貯體用於組態資料。
• 以字串「-m0」結尾的貯體用於中繼資料。
• 在 DDOS 6.1 之前，雖然建立了三個貯體，但只會使用以「-d0」結尾的貯體。但是，這三個貯體都是必需的，因此，請確保未將其移除。

是否可以使用先前建立的現有貯體名稱？

• 不可以。

除了硬體要求之外，在設定 LTR 之前，是否還需要其他任何強制要求？

• 是
• 如果使用 ECS，則負載平衡器是強制要求。若沒有負載平衡器，Data Domain 會與單一節點上的 ECS 通訊，並在發出多個要求後中斷連線。
• DDR 和雲端提供商之間的 1Gb 網路

是否需要憑證，如果需要，應使用哪些憑證？

• 這取決於使用的物件或雲端提供商以及組態。
• AWS、Virtustream 或 Azure 需要憑證。如需詳細資訊，請參閱 DDOS 管理指南。
• 如果使用 http 端點設定 ECS，則不需要憑證。
• 如果使用 https 端點設定 ECS，則需要憑證。由於負載平衡器是強制要求，因此所需憑證來自負載平衡器系統，而非 ECS 系統。如需進一步詳細資料，請與負載平衡器提供商聯絡。
• 匯入憑證時，必須採用 PEM 格式。某些提供商不提供 PEM 格式的憑證，因此必須在匯入之前對其進行轉換。

支援哪些複製拓撲？

• _不_支援集合複製。
• 支援目錄複製，但只能由「/data/col1/backup」MTree 使用，但此 MTree 不支援資料移動。
• 完全支援 MTree 複製。
• 完全支援 MFR 或 VSR 複製。

在已設定 LTR 的系統上設定/初始化/重新初始化複製時，應考慮什麼？

• 來源系統會拍攝 MTree 的快照 (此快照包含作用層和 Cloud Tier 上的檔案詳細資料)。
• 來源系統會將快照複製到目的地系統的作用層。
• 只有在快照已完全複製後，它才會在目的地系統上公開 (此時，檔案在目的地系統檔案系統命名空間中可用)。
• 只有在檔案公開後，才能在目的地系統上執行資料移動 (假設其設定為 LTR)。
• 因此，如果目的地作用層不夠大，無法保留來自來源的完整快照，則快照永遠不會公開，複製也無法完成初始化。

如果在已設定 LTR 的系統上設 MFR 或 VSR 複製，應考慮什麼？

• 如果必須複製已遷移至來源 DDR 上 Cloud Tier 的資料，它會自動從雲端提供商回收至作用層，然後才能透過網路傳送。
• 將檔案從 Cloud Tier 回收至作用層可能會產生成本或延遲。

為什麼 Data Domain 的「檔案系統顯示空間」命令輸出未反映雲端或物件儲存的實際大小？

• 由於雲端或物件儲存固有的運作方式，Data Domain 系統無法查詢雲端裝置的實體大小，因為這可能會視為看似無限的空間。
• 但是，DDOS 必須開發一種方式，以從 DDOS 的角度顯示目前使用/重複資料刪除統計資料。
• 因此，會使用以下兩種方法之一：

1. Cloud Tier 的大小取決於 CLOUDTIER_CAPACITY license
2. Cloud Tier 的大小會根據設定的雲端裝置數量，顯示為該型號類型之作用層裝置大小的倍數。如需有關作用層大小的詳細資訊，請參閱相關型號的硬體安裝指南。

當雲端裝置無法使用時，如何啟動檔案系統？

• 確保檔案系統已停用。
• 使用以下命令停用無法使用的雲端裝置：

cloud unit disable <cloud unit name>

• 啟用檔案系統。

如果雲端裝置已停用，如何啟用？

• 確保檔案系統已停用。
• 使用以下命令啟用雲端裝置：

cloud unit enable <cloud unit name>

• 啟用檔案系統。

為什麼檔案仍存在於已刪除雲端裝置的檔案系統中？

•  如果在刪除雲端裝置之前並未從 MTree 移除檔案，這些檔案會繼續存在於檔案系統命名空間中。
• 因此，檔案位置報告會顯示檔案是已刪除雲端裝置的一部分。例如：  

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-3  Deleted cloud-unit
/data/col1/mtree1/random-data-file-4  Deleted cloud-unit

• 透過存取此 MTree 的 CIFS/NFS 共用，仍然可以在檔案系統命名空間中看到檔案。
• 但是，檔案無法讀取，因為已刪除其所在的雲端裝置。
• 因此，唯一的選擇是刪除這些檔案，因為其參考的資料不再存在。

建立雲端裝置後，是否可以變更 ECS 或 S3 彈性雲端提供商的通訊協定端點或連接埠？

• 例如，如果從 http 變更為 https (或反之)，遷移到新負載平衡器時可能需要這樣做。
• 寫入時，Data Domain 系統管理員無法執行此變更。正在考慮將此功能納入未來的 DDOS 版本中。
• 但是，這可以由支援或工程部門來執行。
• 必須停用檔案系統，才能執行此變更。
• 如果需要，系統會先在 Data Domain 系統外部執行所有組態，因為變更後，檔案系統啟用時，會預期能夠使用更新的通訊協定或連接埠進行通訊，並像先前一樣讀取貯體或物件。