NetApp | SVM災難還原（三）DR寫回到本地

延續上一篇，假設DR Site已經起來服務並有資料的異動，當本地端可以正常服務的時候，那麼這段時間資料的異動必須寫回本地端，也就是反向SnapMirror的Reverse Resync功能，這邊我們用指令去做，原因是SVM災難還原只能使用CLI，不過透過CLI有個好處就是會知道Reverse Resync做了哪些動作，但歸納起來就只有兩個大動作：

1. 刪除原來的SnapMirror
2. 建立DR Site到本地端的SnapMirror

NetApp | SVM災難還原（二）SnapMirror設定

這個LAB主要目標就是把來源的SVM與此SVM的Volume都備分到另一台NetApp，然後再讓目的端的SVM起來服務，SVM環境是以CIFS來做LAB，所以請先準備好一些設定

• 在來源端建立SVM，並設定好Volume, CIFS, Share, Quota, LIF之後用來驗證有把這些設定到異地
• 建立好兩端的Cluster Peer
• 確定兩端的License要一致
• 確定至少有一個10GB空間的non-root aggregate可以使用

LAB_NetApp是本地端，VM-NA是DR Site，以下步驟要注意是在本地端還是DR Site下指令。

NetApp | SVM災難還原（一）概念介紹

這篇主要是介紹SVM的災難還原，這功能是屬於SnapMirror的一部分，但是設定必須都透過CLI指令去完成，這功能可以達到SVM設定的還原，意思是說SVM裡面的Quota, CIFS, Namespace, Network...這些設定都可以在另一個地方直接備份並還原，下圖是9.3目前可以做到複寫設定的部分，可以看到SAN的設定目前都無法做到，也就是說這個功能可以將本地端的SVM設定備分到異地端，當災難發生的時候，就不擔心異地端的SVM設定會跟本地端不一致
。

下圖是SVM的災難還原設定的工作流程圖，這邊主要有一個參數indentity-preserve是影響整個流程最關鍵的地方，可以看到圖片如果選擇Yes或No會有不同的流程，最主要差別就是會不會自動備份跟來源SVM一樣的設定，但我們希望設定越簡單越好，所以會以最右邊的那條路來做配置，大部分企業應該是中間那條路，因為異地端的網段通常不會跟來源端一樣，這次LAB主要是以右邊的路徑來完成，不過設定這些東西還是要先好好閱讀SVM Disaster Recovery PreparationExpress Guide這份文件，裡面會有許多前置作業的準備，還有哪些功能是可以備份過去也會有詳細的列表，接下來就去下一章節來開始做此次的LAB。

[Netapp教學] SnapMirror進階指令使用時機

----以下都只是討論SnapMirror而非SnapVault----

這邊在簡單解釋一下SnapMirror的原理，SnapMirror總共會使用兩份Snapshot做差異的備分比較的傳輸，第一次會在要保護的Volume做快照，然後將快照傳輸到備份端，等到下一次排程時間，再產生一份快照，然後將這兩次快照的差異傳輸到備分的地方，接著重複這些動作。以下解釋進階的SnapMirror指令功能。

[NetApp教學] ONTAP升級

這邊介紹簡單的ONTAP升級方式，首先到官網找一下版本，這邊有一個小技巧就是搜尋patch版本，如下圖，在To access a specific輸入版本號跟patch號，如果不這樣做就找不到版本的patch檔案下載。

[VMware] ESXi 6.5無法抓到USB裝置

最近剛好接連遇到客戶說ESXi底下的VM無法讀取USB，共通點就是該USB裝置是

ERP產商的Key Pro認證使用的裝置，google了一下找到一個值得一試的KB，裡面的內容簡單說ESXi 6.5預設是舊的驅動包含xhci, ehci-hcd, usb-uhci, usb, usb-storage被新的驅動vmkusb給取代，但如果想要讓這些舊的USB驅動生效，可以透過一個指令來達成，客戶使用後也解決了這個小問題，讓Key Pro可以正常讀取到，只需要下面幾個步驟。