第八回 某外商公司的備份還原演練

小弟公司服務的範圍其實相當廣，還包含了異地異機還原演練這種服務，記得去年接了一家外商公司的 Case ，就是將該公司平常一直在外送的備援磁帶做還原演練。

理想值是這樣的，該公司每天都會將公司重要主機的備份再另行複製一份透過快遞送到異地的保險箱，隔天再去取回來使用，總共有三組這種磁帶在輪替，輪替的時間可能己經兩年多了，從未有過演練。

這次我們將磁帶一拿到後，就先回復備份用主機之資料庫，因為備援中心的同事將資料庫倒回來後，一直覺得有問題請我過去支援，我檢查了一下後發現有些怪怪的地方後就跟客戶連絡，我想去直接看目前備份用的系統主機做檢察，這才發現一件事。

原有的備份系統可能大約在上線一年半後，就己經發生放置 Copy 帶子的空間不足的問題，而因為原廠商設定的方法並沒去檢核每個步驟，造成每天備份的 Report 都是成功的，一直到我發現。雖然客戶還是一直質疑我說明明每天的 Report 都說備份是成功的，為何我說是失敗的呢? 只好開了一個會說明目前備份的內容和架構，並列出正常 Pool 和 Copy Pool 的備份空間並不同，客戶才相信我的說法。

所以意思就是說，其實己經不知道有多久時間了，每天從磁帶機拿出來請快遞送走，鎖到銀行保險箱的磁帶都是空的。我將客戶的現有備份系統備份的 Script 稍作了一些修改，並調整了帶子的數量，重新再執行了一次磁帶 Copy ，因為己許久沒執行過，這次執行可能會稍久，我看了程序有在跑就先離開了。

直到第二天確認完成後，磁帶再度送到驗證中心去，這次就確定內容物是有資料的，可以開始做還原演練了。

最後要提醒各位人客啊，備份不是備完了送走就好了，平常定時要演練一下啊，快遞公司和銀行應該感謝你們，白白給了他們每天送幾捲空白磁帶保存和運送的這筆生意機會。所以挨踢人這次又救了一家公司，如果等到哪天他們機房出了什麼事後才發現送到異地的磁帶是空白的不知老闆會有什麼表情。

第七回 AIX 的記憶體配置

AIX 這套作業系統是 IBM 在自家的 UNIX 上使用的作業系統，也是由IBM 開發的，目前只有　BULL 和 IBM 的 Power 伺服器能夠使用 AIX 。 最新版本是 6.1 ，但隨著 Power 7 的上市， AIX 7 己經快出現了，小弟覺得 AIX 6.1 可能是有始以來最短命的一個版本。由過往歴史看來，過去的 4.3.2 和 5.1 都很短命，4.3.2 之後沒多久，4.3.3 就出了，5.1 馬上就5.2，沒多久又 5.3，目前看來 5.3 大概是 AIX 最命長的一個版本。

有關AIX 的記憶體配置一直有個奇怪的問題，就是無論你的記憶體裝了多少，系統配置時都會儘可能的讓作業系統拿來當成檔案系統 JFS/JFS2 操作的 Cache，而且會儘可能的把記憶體都吃光，這使得有些正常的使用者作業要用到記憶體時，系統就要去做記憶體分頁切換，而在 AIX 5.2 ML5 和 AIX 5.3 ML2之前，這個動作並沒有被最佳化過，意思就是平常記憶體可能都會被 File System Cache 佔用，但真正使用者要執行的程式要使用時，實體記憶體己經被佔用光了，所以系統就會大量的使用 VMM 上面定義的磁碟分頁的部份，如此一來，真正的效能就會被磁碟分頁這個動作整個拖住。造成效能非常的差。

在剛剛說的 AIX 5.2 ML5 和 AIX 5.3 ML2 之前，我們使用 VMO 中的 Min Perm 和 Max Perm 來限制 File System Cache ，讓系統可保有最小有 Min Perm 定義的百分比 Size 的 File Cache ，最大又只能使用 Max Perm 定義的 Cache ，這樣的話就能改善上述的一些狀況。

另外在搭配 Oracle 9i /10g 版本時，更可以在系統上去改動 v_pinshm=1 ，然後將 Oracle 的 Lock_SGA 啟動，讓 Oracle 的 SGA 部份啟動後就佔住記憶體，不會再接受系統操作去切換分頁位置，但是 v_pinshm=1 這個設定如果在記憶體較小的設備上(其實己經遇過幾次，說比較小，也不一定，有很大的系統還是當過)，經常造成系統當掉，每次原廠工程師把 Report 收回去一看就會說這個要關掉不能開，但 Oracle 明明有文件說這個開了效能才會上來。每次就為了這個參數在吵。

一直到 AIX 5.2 ML5 和 AIX 5.3 ML2 之後，有了一個新的參數叫 LRU_FILE_REPAGE ，系統預設是 1 ，建議是 0 (AIX 6 好像己經將這個參數拿掉，直接預設就是 0 ，就是叫你一定要設成 0 就對了啦，不過要我裝過 AIX6 時再來確認這件事) ，這個參數設定為 0 後，系統就會將記憶體優先配置給使用者使用，假設記憶體己經全部被 Filesystem Cache 部份佔掉了，當有使用者要使用時，Filesystem Cache 就會優先被釋放出來供使用者的應用程式使用。

有這個參數以後，在各種應用系統的記憶體問題效能就有比較大幅度的解決，起碼記憶體不會再莫明奇妙的一直被吃光，然後用到磁碟分頁去了，除非，你的記憶體是真的不夠的。但是記住一點，你在各種記憶體監控程序去檢視記憶體時，你仍然會發現記憶體的 Free Space 可能還是 2%~3%或者是更少，除非你的系統開起來都沒有任何運作。

另外 File System Cache 只有在有使用 JFS/JFS2 的狀態下，有執行 OS Level 的 檔案操作時會被使用到，比如說 copy 檔案， tar 檔案等等這些檔案的 I/O 行為，如果是像 Oracle 那種直接由 Block Level 或是說使用 RAW Device 是不會用到 File Cache的。

第六回 VMWARE 的 VCB 搭配備份軟體使用，以 TSM 為例

VMWare 搭配 VCB 再搭配 TSM 有幾種做法，一種是從 TSM Client 6.1 的設定裏面設定，看書上寫的好像要設定什麼 Proxy Node ，有點不太懂，所以我就沒有使用這個方法。

另外的話就是使用 VMWare 提供的 TSM Integragtion 的工具，我後來就是使用這個方法，因為看起來好像比較簡單一點，接下來就來說說大概的說法，首先去 VMWare 官方下載 VMware Consolidated Backup 這包工具，其實他是由 WSH 組成的，意思就是 VMWare 己經寫好一套方法，讓你可以用很簡單的指令去 Mount 來自 ESX 上面的 Filesystem ，無論是透過 LAN 或 SAN 。

http://www.vmware.com/support/vi3/doc/releasenotes_vcb103.html

記得除了這個工具，原有的 VCB Backup (又稱 VCB Proxy)的工具原本就必須要安裝，安裝方式和路徑就不再提了。

安裝完成後在 c:\Program Files\VMware\VMware Consolidated Backup Framework\config \ 下可以找到 config.js 這個設定檔，裏面重要的參數有

BACKUPROOT="E:\\mnt1";備份之 VMDK 檔放置路徑

HOST="VC Server IP address";備份之 ESX 主機或 VC 主機之TCP/IP 位置

USERNAME="tsmuser";備份之 ESX 主機或 VC 主機之使用者名稱

*PASSWORD="passw0rd";上列使用者之密碼，如使用Register 的方式註冊，不需提供此參數，但在 Register 裏面密碼仍然是明碼顯示

TRANSPORT_MODE="san";傳輸模式，預設為 SAN，我試過在 Gigabit Ethernet 的環境和 SAN 的速度差異應該近十倍，非常建議使用 SAN 的模式，前提是你的 VMESX 的 Guest Host 的 Lun 要在 SAN Disk 上面，但有用 VMWare ESX 的人應該都會有好幾台 ESX 做 VMotion ，這應該不是什麼問題。

VM_LOOKUP_METHOD="name";VM找尋方式，預設為 ipaddr ，目前設定為 name

首先你需要在 VC 上面建立一個 User ，必須有 VCB Backup 的權限，將使用者名稱及密碼設定在上述參數中。

設定完成後就可以透過 pre-command vcb 及 vmname 去備份你的 VM ，這隻程式會透過呼叫 VC 去觸發你的 ESX 完成 Snapshoot 的動作，然後用 vcbmount 把 VM 的 Image Copy 到你所設定的目錄上，再由 TSM 將該目錄完整的備份下來即可。

為此我寫了一個 Windows 的批次檔，目標是完成，檢查 e:\vmesx2.lst 裏面提供的 VM 清單，並觸發 vcbmounter 去備份清單中每個 VM Guest 的 Image 內容。另外在前面加了一段會將前一次備份的內容先行移轉到 e:\mnt2 去，如此確保在這台 VCB Server 上面會有最新的兩次備份內容(一份在 e:\mnt1，一份會在 e:\mnt2)，批次檔內容如下：

@echo off
REM TSM 環境變數設置
set DSM_CONFIG=C:\Program Files\Tivoli\TSM\baclient\dsm.opt
set DSM_DIR=C:\Program Files\Tivoli\TSM\baclient
set DSM_LOG=C:\Program Files\Tivoli\TSM\baclient

REM 備份前置部驟，刪除硬碟中前兩次備份資料，另將上次備份資料轉移至 e:\mnt2
for /f "delims==" %%i In (e:\vmesx2.lst) do rmdir e:\mnt2\%%i /s/q
for /f "delims==" %%i In (e:\vmesx2.lst) do move e:\mnt1\%%i e:\mnt2\%%i

REM 執行 VCB 程序，開始備份 e:\vmesx2.lst 中所列出之 Guest Host 之 VMDK 檔至 e:\mnt1
for /f "delims==" %%i In (e:\vmesx2.lst) do call pre-command vcb %%i

REM 執行 TSM備份 程序，開始備份 e:\vmesx2.lst 中所列出之 Guest Host 於 e:\mnt1 中對應之目錄
for /f "delims==" %%i In (e:\vmesx2.lst) do dsmc incr e:\mnt1\%%i -subdir=yes

REM 檢查 TSM備份結果，導出至 e:\tsmlog\vcb_backup_esx02.log
for /f "delims==" %%i In (e:\vmesx2.lst) do dsmc q backup e:\mnt1\%%i\* >> e:\tsmlog\vcb_backup_esx02.log

vmesx2.lst之內容如下：
XXX01-FullVM
XYZ01-FullVM
ABC01-FullVM

使用 VMware Consolidated Backup Framework 的規則就是你要備份 Snap Shoot 的VMDK Image 時，給的 VM Name 必須要加上 -FullVM 的關鍵字，他就會自動轉換為對應的 VcbMounter 指令。

原本我這個 Job 是 Work 的，但在客戶端，我遇到問題了。

因為客戶隨時會把 VM 移來移去，或者換名字換 IP ，甚至原本己在 SAN Disk 裏面的 VMDK 檔在客戶移動後變成在 Local Disk ，造成了幾個問題如下：

1.可能是客戶換網段，換名字，造成 VMTOOLS 好像有點問題，使用 VCBVMNAME 都 Scan 不到該 VM ，這時可能要移除 VMTOOLS ，再重新安裝，讓VCBVNMAME 至少要看的到這個 VM 才能進行備份，記住，從 VC 上看的到該 VM 仍然是不足夠的。

2.因為客戶會將 VMDK 從 SAN 的 Disk 移到 Local 的 Disk，造成我原本己設定成 SAN Disk 備份的屬性己可備份結果又變成不能備，針對這點用 pre-command 就無法隨時變來變去了，我寫 Windows Batch 的技巧還沒這麼出神入化，最後我決定告訴客戶，在你這個隨時會變化的環境，可能必須要自己手動備份才有辦法。

唉....花了大把心力幫客戶完成的方案結果無法使用，不過還是公佈個大概給大家瞧瞧。其實這個作法應該是用別的備份軟體也能做，不限於 TSM 吧。反正就是先把 VMDK 檔備份下來，再由 TSM 備走而己。

第五回 某物流業資料庫備份問題

這次是今年發生的事，因為專案的關係，我們協助某物流業建立備份程序，在這個客戶環境中，存在了一個將近 100G 的 MYSQL 資料庫。

原本 100G 的資料庫，無論是 MS 的 SQL ，或 Oracle Database ,Sybase , Informix 都不會有什麼問題，但是因為他是 MYSQL ，所以有一些限制存在，偏偏在事前我們並不知道這個限制，問題就是在使用 mysqldump 備份時，如果 table engine 是屬於 defulat 的 MYISAM 模式的話，會造成 table 在備份的過程中，發生 table lock ，所以任何有關 update , delete , insert 的 DML 將無法執行，在備份的 Script 排程下去後的當天凌晨，該客戶的 MYSQL 資料庫就這樣被 Lock 了一個小時無法運作。

在問題發生了之後，我們試過了各種方法，無論是用硬體 做 Disk snap，或 Linux 的LVM snap，在客戶的環境下運作都還是有問題，最後只能依造 MYSQL 的做法，建立一台 Replication Server ，但是這仍然是有問題的。

最主要還是在 MYSQL 架構上，MYISAM 下並沒有交易的機制，每一個 DML 就是一個獨立的交易，無法 Rollback ，所以如果正常執行下，Replication 機制是運作的，但是只要 Disk Crash ，File system Crash ，Power Outage 發生時，造成 Master 或 Slave 中任一 Database 有資料損壞，就會發生一件事，兩端的資料會原本的一致，變成有落差，而且如何去判別這些落差，哪些是你要的或不需要的，抱歉，DBA或系統管理人員並不是開發人員，不知道你程式怎麼執行的前提下，無法取得哪些資料是你不要的資訊。假設 Master 因為任何原因資料損壞修復後，Slave 端就會多出一些資料，而多了哪些資料，除非你把兩邊資料庫停下來做比較，不然無法得知。如果客戶無法忍受 RTO 太長而需要儘快的將資料庫啟動的話，是無法完成這件事的。

那假設把資料表轉換成另外一種 Engine Innodb 的話，看起來好像事情可以得到解決，因為有了 Transaction 機制，MYSQL 會記錄每一筆交易到 LOG 檔中，亦會將這些交易跟 Replication 用的 bin log 同步，所以 Replication 端會去讀取所有的交易記錄，不過我還是發現了問題，就是如果這回輪到 Slave 端斷電的話，一樣會不同步，只是還原的方法就比上面簡單多了。問題發生的原因跟上述的原因一樣，只是這次是發生在 Slave 端。

但是無論如何，Master 應該都會比 Slave 重要，個人覺得重要的資料庫還是需要開啟 Innodb 的，只是這樣就失去 Mysql 又小速度又快的特性了，可能為了要維持資料庫本身的一致性，而拖垮資料庫系統的效能。

第四回 某外商銀行安裝磁帶機問題

因為承接了某家銀行集中備份的服務，需要將現有環境中的磁帶機更換為光纖通道介面的，前提就是主機上也需要新增一片光纖通道卡，選了一個平日晚上，我們將備份伺服器停機，準備進行這個工作，在整個工作完成後，有趣的事情發生了，主機的網路無法通連，連網卡都看不到，我們做了許多測試，還原硬體環境，重開機，修改檢查登錄機碼，都無法再看到系統內的任何一張網卡。

為了加這張卡片。測試了兩天，最後和客戶討論後決定，還原回系統中原有7個月前的作業系統備份，因為備份伺服器的主要檔案都存放在非系統碟，因此還原後，備份伺服器順利的啟動了。

最後我判斷，因為銀行的 Policy 特別嚴格，在Windows 環境中做了許多安全性強化原則，設的太過頭了，己經影響到 Windows 作業系統的運作。才導致這次事件發生。但是無法指出是哪條安全性原則造成，因為整本手冊洋洋灑灑幾百條，慶幸的是我們將備份系統還原，但是客戶己不讓我們安裝這張卡片了。只好另外安排時間。

第二次安裝排在四週後，而且在安裝前還特別找了台機器向客戶證明卡片是可用的，但是安裝當天仍然不順利，卡片安裝上去後，一直無法抓到磁帶機，於是這次又測了一整天，最後客戶說，再不行又得還原為安裝前的狀態，我們想了許久，告知客戶，希望能將環境還原至 Windows 強化之前的環境來測試，勸說了許久，客戶終於同意，花了30分鐘還原至比上次更久之前的備份後，重新接上磁帶機，安裝驅動程式，直接的磁帶機就順利安裝成功。

你問我怎麼回事，我的解釋原因一樣，就是安全性設定設的太過了，讓系統連新增移除硬體都有問題，白白的浪費了兩次加班時間快20個小時，只為了做這次 2個小時就能完成的事情。

第三回 回顧 200X 年某書局的 Oracle Database 問題

這是回顧某一年凌晨，我接到老闆電話，某書局 ERP 資料庫檔案放置的 Filesystem Crash ，目前己經是一個空目錄，我詢問了狀況後，出門去協助解救，過去了以後，還是先看看那個己經全空的 Filesystem ，原廠的 Support 工程師己經線上電話諮詢過，客戶也重建了該 Filesystem ，所以我也沒什麼好看的了，理所當然的空空如也.

只好.....開始看客戶的備份環境，首先客戶依當初導入 ERP Consultant 的手冊實施每日的備份，然後上帶，所以只能反客操作回來，所幸磁碟系統中所存的那份備份內容仍在，只要使用 RMAN 就能 Restore 回來，只是要找出是哪份資料，因為客戶使用了 RMAN Catalog DB ，但在我去之前的兩個小時，客戶就己經依 Oracle Support 的步驟執行了 List Backup ，結果系統沒有任何回應就卡在那，個人感覺不對勁及沒道理，詢問了客戶後，找出該 Catalog DB Server ，居然是台 Pentium Pro 的機器，那時主流應該是 Pentium 4 ，結果客戶那居然還有這種古董。(依照記錄Pentium Pro 是 1995 年的時候出來的，那年至少是 2004 ~ 2005 年的時候吧)

我判斷因為客戶從未整理 Catalog DB ，裏面有太多的垃圾，造成這台古董機根本跑不出要回傳的資料，就先請客戶找一台比較快的機器來，把Catalog DB 在那台機器上建立起來，重新下 List Backup 後，終於在半小時後有資訊出現了。但是下 Restore Backup 後還是沒有反應，後來我只好試著 Restore Datafiel ID ，忽然就有資料被倒出來了，終於是出現了一道曙光，但是客戶存放 Backup File 的 Medida 實在是慢到嚇人，結果這近 200G 的資料預估需花費48小時才 Restore 完成，

在 Restore 完成後，我又前往去協助 Recovery Database ，到最後都 Recovery 完成後，我嘗試著要 Open Database ，又發現有一個 Datafile 需要 Apply 一個三年前的 Archive Log ，我問客戶說這怎麼可能，前天的備份，現在還要跟你要三年前的 Archive Log ，後來我看了一下那個檔名的命名方式跟現存的不同，因此猜測當初有人建錯檔案，就直接把該檔案設為 Offline 後就沒去理他了，所以我也把該檔案直接 Drop 掉，再重新開一次資料庫就啟動了。

這家書局的 ERP 系統也48 小時無法登錄使用，慶幸的是這兩天是盤點的時間，因此損失也不大。

不過我最近又去訪問過客戶，當年的 DBA 己經是資訊部的經理了，我呢....還是工程師.....。

第二回 某財團法人之系統當機

在 2008 年接了一個財團法人重要系統的轉換案，目的是將現有設備轉換至新年度採購設備上，同時做 Oracle 9i 昇級至 10gR2，但在初步評估時，客戶的 Application 開發人員太過樂觀，實際測試時，遇到很多問題，其中包含 Database 昇級的問題及系統面臨昇級時所要處理的一些小問題，在初步測試時，我發現客戶在 Oracle 9i 時代完全不敢去動這個資料庫，因此 Patch Level 還是在 9201 ，但是要昇至 10gR2 至少需要 9204 以上的 Patch 才能做，表示了正式轉換當天我需要做二次昇級的動作。而正式轉換僅有8小時的時間，我面臨的是兩個資料庫，一個 800GB 左右，一個 1.2TB，我預估我的工作時間是4個小時，其他是給 AP 測試的時間，至於你問我將近 2 TB 的資料我如何在 4 小時內轉換完成，那我就不多談了。(事實上我上線當天我的工作只有2個小時，用什麼方法，可能內行人都知道)

因己經演練過許多次上線步驟，所以實際上線當天算是順利的，只不過新系統很不給面子，在上線二週後面臨了第一次的當機，當天原廠的工程師前往檢查，收了 Log ，最後將系統重新啟動帶起服務後，就開始開會檢討當機原因，發生的問題在原本連接在 SAN 上的 Storage 忽然之間全部斷線，造成 Oracle 無法運作，至於 HA 為何沒啟動，因為 SAN Storage 的離線本來就不在 HA 的偵測範圍，因為 LOG 要遠渡重洋到XXX實驗室去，所以問題的原因需要等檢查報告。

所以就這樣又過了不知道幾天，又發生第二當，這時原廠的專家說初步原因是因為 SAN Storage 的資料流跟備份資料庫的資料流都集中在同樣一個 Loop 的卡片上，可能 Load 太重，我們心裏都很 OOXX ，那以後是不是叫全世界的人要做 SAN Backup 的話，要多買卡片，但是這種專家就是自視甚高，我們也不能去當面吐他槽，而且他說的事情實際上還是有這個可能性的，只要問題能解決，用什麼方法不重要，因此我們就依說明去調整了。

調整完畢後，差不多同樣在第一當和第二當的週期的同樣時間，第三當又發生了，這次原廠頭可大了，來了好幾個專家和工程師，聽說把作業系統的 Trace Mode 都啟動了，還安裝了不知什麼監控用程式在上面。然後呢...就等第四次當機的發生，新系統也是很給面子的，只是這次不在週期內發生，我也忘了實際的時間，第四當發生了，將所有的 Log 送回原廠分析後，原廠的報告是不知作業系統內哪個程式被觸發，把 Fiber Channel 上面的 Connect 全部 Disable 掉，所以 SAN Storage 才會忽然被離線，他們緊急開發了一個 Patch 去阻擋這個行為。

終於在這個 Patch 安裝了以後，就不再發生當機的事情。但是是為什麼發生的，最後的報告還是不知道。真要慶幸這個案子原廠的服務我們並沒有接回來，雖然在途中還是幫原廠做了不少事，但是至少這次出事，原廠是義無反顧的在處理這件事。