搬站與備份

存在同一台主機等於沒有備份

這是最基本也最常被忽略的原則。

如果備份檔就放在網站主機上，那麼以下情況會讓備份一起消失：

• 主機硬體故障
• 主機被入侵——攻擊者通常會一併刪除或加密備份
• 帳號被停用或方案到期
• 誤操作刪除整個目錄
• 服務商本身出問題

備份的意義就在於「當主機出事時還有東西可用」。 放在同一台，這個意義就不存在了。

更糟的情況：備份放在網站目錄下

這不只是無效，而是資安風險。

如果備份檔放在網站可存取的路徑下，任何人只要猜到檔名就能下載——等於公開了整個資料庫，包含會員資料與後台密碼。

常見的疏失檔名

• 以網站名稱或日期命名的壓縮檔
• 資料庫匯出檔放在根目錄
• 舊版網站的整站壓縮檔沒有刪除

自動化掃描工具會主動嘗試這些常見檔名。 備份必須放在網站無法存取的位置。

相關的存取控制見主機層與存取控制的防護設定。

常見的存放位置比較

建議的組合

對多數中小企業，「主機商備份 + 自行保存一份到雲端」是成本與安全的平衡點。

• 主機商的備份用於快速還原
• 自行保存的那一份用於服務商出問題時的保險

異地的定義

「異地」不只是不同資料夾，而是不會被同一個事件同時影響。

不算異地

• 同一台主機的不同目錄
• 同一個帳號下的不同空間
• 同一個服務商的另一個服務

算是異地

• 不同服務商的雲端儲存
• 公司內部的實體儲存
• 不同機房的另一台伺服器

判斷方式：如果服務商整個出問題，這份備份還在嗎？

備份要加密

備份檔包含網站的所有資料——會員名單、訂單、後台帳號、設定檔中的資料庫密碼。

它的敏感度等同於整個網站，甚至更高（因為集中在一個檔案中）。

建議的做法

• 備份檔加密後再上傳到雲端
• 加密的密碼另外保管——不要與備份放在一起
• 確認至少兩個人知道密碼——避免唯一知情者離職或請假時無法還原

最後一項很重要。 加密的備份若沒有人知道密碼，等於沒有備份。

存取權限的控制

• 只有必要的人能存取備份
• 不要存在個人的雲端帳號——離職時會失去
• 使用公司名義的帳號
• 保留存取紀錄
• 離職時移除權限

這與網域、分析工具的帳號歸屬是同樣的道理——重要資產的所有權應該在公司手上。

個資的考量

備份中包含大量個人資料，因此：

• 備份也在個資保護的範圍內
• 保存期限應納入整體的資料保存政策——不是留越久越好
• 刪除資料時，備份中的資料如何處理應一併說明
• 若備份存放在境外服務，需留意相關規範

詳見網站會蒐集到哪些個資。

儲存成本的控制

備份會持續累積，成本也會。控制方式：

• 壓縮——資料庫的文字內容壓縮率很高
• 階梯式保留——近期密集、久遠稀疏
• 增量備份——只備份變動的部分
• 分開處理——很少變動的程式檔不必天天備份
• 設定自動清理——過期的自動刪除

自動清理要小心

先用「只列出不刪除」的方式確認過一次，再啟用實際刪除。刪錯備份是無法復原的。

網站以外也要備份的東西

這些不在主機上，但同樣重要：

• DNS 記錄的完整清單——建議截圖或匯出保存
• 各服務的帳號與到期日
• 憑證與續期設定
• 設計原始檔
• 合約與授權證明

DNS 記錄特別容易被忽略——它不是檔案，但遺失時要重建很麻煩，而且期間郵件與網站都會受影響。

見DNS 是什麼？常見的記錄類型。

檢查現況的五個問題

1. 備份放在哪裡？與網站是同一台主機嗎？
2. 備份檔能被外部直接存取嗎？
3. 有沒有一份在主機商以外的地方？
4. 備份有加密嗎？密碼誰知道？
5. 存取權限是誰的帳號？離職會不會失去？

如果第三題的答案是「沒有」，那是最該優先處理的。

各主機商與服務商提供的備份機制差異很大，本文說明的是規劃原則與該確認的項目。實際的功能與條款請以服務商的現行說明為準。

沒有測試過的備份，不算備份

這句話值得放在最前面。

實務上很常見的情況是：備份檔案每天都在產生，看起來一切正常。直到真的需要還原時，才發現用不了。

而那個時刻，通常是最沒有餘裕處理的時刻。

備份失效的常見原因

這些問題都只有在實際還原時才會浮現。

演練的三個層級

層級一：檔案檢查（每月）

最低限度的確認，花不到十分鐘：

• 備份檔案的時間戳是否為最新
• 檔案大小是否合理——與上次相比是否異常
• 能否正常解壓縮
• 檔案數量是否符合預期

檔案大小突然變小是最明顯的警訊——可能代表備份過程中斷。

層級二：部分還原（每季）

• 把資料庫備份匯入測試環境
• 確認資料表數量與筆數
• 抽查幾筆資料的內容
• 確認中文顯示正常

層級三：完整演練（每半年）

在乾淨的環境還原整個網站並實際操作。這是唯一能真正確認備份可用的方式。

完整演練的流程

1. 準備一個乾淨的測試環境——可用測試站或本機環境
2. 取得備份檔案——用平常的取得方式，不要走捷徑
3. 還原檔案與資料庫
4. 調整設定——資料庫連線、網址設定
5. 實際操作測試
6. 記錄過程與所花的時間

第二步的重點

要用真實情境下的取得方式。 如果實際發生災難時需要從雲端下載，演練時就應該從雲端下載，而不是用手邊剛好有的檔案。

這樣才能發現「原來下載要三小時」這類問題。

演練時要確認的項目

1. 首頁與主要頁面正常顯示
2. 後台可以登入
3. 中文與特殊字元正常——沒有亂碼
4. 圖片與附件都在
5. 資料筆數與正式站相符——文章數、會員數、訂單數
6. 表單功能正常
7. 會員登入正常
8. 排程工作的設定是否包含在備份中

第五項最重要。 數量對不上就代表備份不完整，要找出原因。

記錄還原所需的時間

這是演練最有價值的產出之一。要記錄：

• 取得備份檔的時間
• 還原資料庫的時間
• 還原檔案的時間
• 調整設定與測試的時間
• 總共花了多久

為什麼重要

知道總時間，你才能回答一個關鍵問題：如果現在網站掛了，多久能恢復？

如果答案是「八小時」而業務只能接受「兩小時」，那就需要調整方案——例如改用更快的備份方式，或準備熱備援環境。

把流程寫成文件

演練時把步驟記錄下來，做成一份還原手冊：

• 備份存放的位置與取得方式
• 解密的方式與密碼保管處
• 還原的完整步驟
• 需要調整的設定項目
• 驗證的檢查清單
• 相關人員的聯絡方式

放在哪裡

不要只存在網站或主機上——真的需要它的時候，那些可能正好無法存取。

建議：紙本一份、離線可取得的位置一份。

演練會發現的典型問題

以下都是實際常見的情況：

• 「備份裡沒有資料庫」——只設定了檔案備份
• 「還原後中文變亂碼」——匯出時沒有指定字元集
• 「上傳的圖片都不見了」——上傳目錄不在備份範圍內
• 「不知道加密密碼」——設定的人已離職
• 「下載要花很久」——沒有考慮到檔案大小與頻寬
• 「不知道還原後要改哪些設定」——沒有文件
• 「最後一次成功的備份是三個月前」——腳本早就失敗了

每一項在演練時發現，都只是花一個下午；在真的災難時發現，代價完全不同。

誰來做演練

• 如果有維護廠商——可以要求納入服務範圍，並提供演練報告
• 如果自行管理——指定負責人與代理人
• 建議由「不是設定備份的那個人」執行——才能測出文件是否足夠清楚

最後一項很有價值。 設定的人憑記憶就能還原，但真的出事時可能是別人在處理。

納入合約或維護方案

建議明確約定：

• 多久做一次還原演練
• 演練的範圍與驗證項目
• 是否提供演練報告
• 發現問題時的處理方式

「有備份」與「備份可用」是兩件事，合約中值得分別寫清楚。

見保固與維護有什麼不同。

最小可行的起步

如果從來沒做過演練，建議這樣開始：

1. 這個月先下載一份完整備份，確認能解壓縮
2. 下個月把資料庫匯入測試環境，確認筆數與中文正常
3. 下一季做一次完整還原，並記錄時間
4. 把過程寫成文件

不必一開始就做到完美。 第一步的「確認能解壓縮」就已經能排除相當比例的問題了。

資料庫還原的技術細節見資料庫備份與還原的技術要點。

各主機商與服務商提供的備份機制差異很大，本文說明的是規劃原則與該確認的項目。實際的功能與條款請以服務商的現行說明為準。

先確認是哪一種搬遷

「搬站」可能是四種不同的事，涉及的範圍與風險差很多：

不要同時做多件

同時換主機又換網域、或同時改版又換系統，出問題時會無法判斷原因。

建議拆開進行，每一步確認穩定後再做下一步。時程雖然拉長，但風險與排查成本都低得多。

盤點的四個面向

不論哪一種搬遷，都應該先把現況完整記錄下來。

一、資產與帳號

這一項在換廠商時特別重要。

最關鍵的一欄是「登記在誰名下」

如果網域、分析工具、廣告帳戶登記在前廠商名下，搬遷前必須先處理移轉，否則搬完才發現拿不回來。

見網域要自己註冊還是交給網頁設計公司。

二、技術現況

• 程式語言版本與已載入的擴充
• 資料庫版本與字元集
• 網站系統與版本
• 安裝了哪些模組或外掛——含來源與授權狀態
• 伺服器的特殊設定——上傳大小、執行時間、轉址規則
• 排程工作的清單與內容
• 與外部系統的串接——金流、物流、發票、ERP

三個最常遺漏的

排程工作——搬遷後靜默停止，通常數日後才被發現。

外部串接的設定值——金流的商店代號、API 金鑰、白名單中的來源位址。換主機後位址改變，對方的白名單需要更新。

轉址規則——過去累積的舊網址對應，若沒帶過去，那些連結就全部失效了。

三、DNS 記錄

這不是主機上的檔案，但遺失時的影響很大。

建議把目前的完整記錄截圖或匯出保存，特別注意：

• MX 記錄——郵件的接收設定
• SPF、DKIM、DMARC——寄件驗證
• 各種驗證用的 TXT 記錄——搜尋主控台、網域驗證、第三方服務
• 子網域的指向
• 目前的存活時間設定

驗證用的記錄最容易被漏掉，因為平常完全不會注意到它們的存在——直到搜尋主控台驗證失效、或憑證無法續期。

見DNS 是什麼？常見的記錄類型。

四、內容與結構

換網域或改版時特別重要。

• 完整的網址清單——可從網站地圖或分析工具匯出
• 目前有流量的頁面——這些是最需要保住的
• 有外部連結指向的頁面
• 目前的搜尋表現——曝光、點擊、主要關鍵字

為什麼要記錄現況數據

搬遷後若流量下滑，你需要有基準才能判斷影響程度。

建議在搬遷前把 Search Console 與流量分析的數據匯出保存，並記錄搬遷日期。

見數據判讀的常見誤解。

換網域時的額外準備

這是風險最高的一種，需要額外準備：

1. 建立完整的新舊網址對應表——一對一，不要全部轉首頁
2. 確認新網域的狀態——是否曾被使用過、有無不良紀錄
3. 準備好轉址的實作方式
4. 規劃驗證的方式

對應表是最花時間也最關鍵的一步。 頁面數量多時，建議用工具輔助產生清單再人工核對。

完整流程見網站改版或更換網域，SEO 排名怎麼保住。

換系統或改版時的額外盤點

• 哪些內容要保留、哪些不要——改版是清理的好時機
• 資料的對應方式——舊系統的欄位如何對應到新系統
• 網址結構是否改變——改變就需要轉址
• 素材的授權狀態——來源不明的趁機替換

素材盤點見素材授權的實務管理。

盤點的產出

建議整理成一份文件，包含：

1. 資產與帳號清單——含登記名義與到期日
2. 技術環境規格
3. DNS 記錄的完整備份
4. 網址清單與現況數據
5. 外部串接的清單與設定值
6. 已知的問題與注意事項

這份文件同時是搬遷的依據、驗收的標準、以及日後的資產紀錄。

盤點階段就該問的問題

1. 有沒有東西是拿不回來的？ 例如登記在廠商名下的資產
2. 有沒有東西是沒人知道怎麼運作的？ 例如某個排程或串接
3. 最後一次完整備份是什麼時候？
4. 如果搬遷失敗，能回到原狀嗎？

第四題的答案決定了風險等級，處理方式見搬站的風險控管與回退計畫。

一個實務建議

盤點通常會發現一些「原來如此」的事——某個服務沒人記得為什麼要付費、某個帳號登記在離職員工名下、某個功能其實早就沒在用。

搬遷是清理這些歷史包袱的好時機。 與其原封不動搬過去，不如趁機整理。

各服務商與廠商的作業方式差異很大，本文說明的是盤點與風險控管的原則。實際的交接內容與流程，建議以合約約定為準並逐項確認。

搬站的核心原則：永遠要能回去

再周全的規劃都可能出意外。真正的風險控管不是「保證不出錯」，而是「出錯時能快速回到原狀」。

所以規劃搬遷時，回退計畫應該與執行計畫同時準備。

回退的前提條件

要能回退，必須滿足三件事：

1. 舊環境還在且可運作——不要提前退租或刪除
2. 知道怎麼切回去——並且有人能執行
3. 切換期間的新資料能處理——這是最容易被忽略的

第三項的問題

如果切換後有訂單、會員註冊、表單詢問進到新環境，回退到舊環境時這些資料會消失。

所以回退不是單純的「切回去」，而是要處理這段期間的資料。

舊環境要保留多久

換網域為什麼要保留最久

因為舊網址的轉址必須持續運作。 搜尋引擎需要時間更新索引，外部網站的連結也不會立刻更新。

舊網域若在轉址完成前過期，那些流量就永久失去了。

切換時機的選擇

優先考量

• 流量最低的時段——通常是深夜或假日
• 業務最不繁忙的期間——避開檔期、活動、報稅期
• 有人可以處理的時候——不要在無人待命時切換

避開的時機

• 連續假期前一天——出問題時找不到人處理
• 促銷活動期間
• 負責人休假期間
• 週五下班前——這是很常見的錯誤，出問題就是整個週末

建議選在「還有一整個工作日可以處理」的時間點，例如週二或週三的早上。

切換前的最後檢查

1. 新環境完整測試通過——用修改本機設定的方式先行驗證
2. 憑證已在新環境安裝完成
3. 備份已完成且驗證可還原
4. DNS 的存活時間已提前調低
5. 回退步驟已寫下來
6. 相關人員已通知

第二項最常被漏掉——切換後才發現沒有憑證，訪客會看到明顯的安全警告。

測試方式見主機搬遷的完整流程。

雙軌並存期的資料處理

DNS 擴散期間，部分訪客連到新環境、部分連到舊環境。這代表新資料可能分散在兩邊。

依網站類型的處理方式

唯讀或維護模式的做法

切換前把舊環境設為不接受新資料：

• 顯示維護中的訊息
• 或關閉表單、購物車、註冊功能
• 並提供預計恢復的時間

短暫的維護公告，比事後追查遺失的訂單容易得多。

回退的判斷標準

什麼情況該回退、什麼情況該繼續修？建議事先訂好標準：

應該立即回退

• 核心功能完全無法運作——網站打不開、無法下單
• 資料明顯錯誤或遺失
• 問題原因不明且無法在合理時間內解決
• 持續造成營業損失

可以繼續修正

• 版面小問題
• 次要功能異常
• 原因明確且修正時間可估

訂一個時間上限

建議事先約定：「如果 N 小時內無法解決，就先回退。」

沒有這個標準時，很容易陷入「再試一下就好」的狀態，結果拖了一整天。

回退的執行步驟

1. 把 DNS 改回舊環境
2. 確認舊環境正常運作
3. 處理新環境產生的資料——匯出並補回舊環境
4. 對外說明（若有影響）
5. 記錄問題的原因——這是下次的依據

回退不是失敗，是風險控管的正常結果。 帶著問題硬撐上線，代價通常更高。

切換後的觀察期

當天

• 各項功能再測一次
• 從外部信箱測試表單通知
• 確認憑證正常
• 查看錯誤日誌
• 確認外部串接正常——金流、物流、發票

第一週

• 確認排程工作有正常執行
• 確認備份機制運作中
• 觀察錯誤日誌的趨勢
• 詢問各部門有無異常
• 檢查搜尋引擎的收錄狀況

第一個月

• 比對流量與搬遷前的基準
• 確認沒有大量的錯誤頁面
• 確認轉址都正常運作

五種最常見的搬站災難

一、測試環境的封鎖設定被帶到正式站

最嚴重也最常見。 網站一切正常，但搜尋引擎完全不收錄，可能兩三個月後才發現，那時流量已經歸零。

切換後第一件事就是檢查這個設定。 見搜尋引擎怎麼抓取與收錄網站。

二、排程工作沒有設定

自動備份、資料同步、定時發布全部靜默停止。

三、郵件設定不完整

表單通知信全部進垃圾桶——因為新主機是新的寄信來源，沒有納入寄件驗證。

見郵件的 DNS 設定。

四、外部串接的白名單沒更新

金流或 API 服務商設定了允許的來源位址，換主機後位址改變，串接就失效了。

五、憑證未先安裝

切換後出現安全警告，訪客直接離開。

把搬遷寫成專案

規模較大的搬遷建議明確安排：

• 負責人與各項工作的分工
• 時程與各階段的檢查點
• 驗收標準
• 回退的判斷標準與步驟
• 切換當天的待命人員

把回退計畫寫進文件，而不是「出事再說」。

驗收的原則見網站驗收怎麼做。

各服務商與廠商的作業方式差異很大，本文說明的是盤點與風險控管的原則。實際的交接內容與流程，建議以合約約定為準並逐項確認。

交接的原則：能帶走的才是資產

更換維護廠商時，最重要的問題是：哪些東西是你的，哪些是廠商的？

這個問題如果到要換廠商時才問，通常已經太晚。合作之初就該釐清並寫進合約。

一、網域：最優先確認的一項

• 註冊人應登記為業主公司，不是廠商
• 確認能自行登入註冊商的管理介面
• 確認到期日與續約方式
• 確認聯絡信箱是公司的，不是廠商或離職員工的

為什麼最優先

網域是所有東西的根。 沒有網域的控制權，網站與郵件都受制於人，而且沒有替代方案。

見網域要自己註冊還是交給網頁設計公司。

二、主機與資料庫

• 主機商名稱、方案、控制台網址與帳號
• 檔案傳輸的帳號與路徑
• 資料庫名稱、帳號、版本
• 完整的網站備份——含檔案與資料庫
• 主機的到期日與續約方式

備份要當場驗證

不要只收到一個檔案就簽收。 應確認：

• 能正常解壓縮
• 包含資料庫，不只是檔案
• 資料筆數與正式站相符
• 中文顯示正常

驗證方式見還原演練。

三、程式碼與設計原始檔

標誌的向量檔要特別提

這是最常被遺漏、日後最麻煩的一項。 只有網頁用的小圖檔，日後要印招牌、做名片、放大使用時就無法處理。

見標誌與向量檔案。

開放原始碼系統的說明

若網站基於開放原始碼系統開發，常見的約定是：業主付清價款後保有本案的修改權，核心系統的著作財產權依該開放原始碼的授權規範。

這是合理的安排。權利歸屬見網站的著作權歸誰。

四、素材與授權

• 使用了哪些商業模板或外掛
• 圖庫素材的來源與授權證明
• 字體的授權狀態
• 各項授權登記在誰名下
• 訂閱制授權的到期日

最關鍵的是登記名義

如果模板、外掛、字體是廠商用自己的帳號購買的，換廠商後可能失去更新權利，甚至需要重新購買。

無法更新的外掛是實際的資安風險——發現漏洞時補不了。

見素材授權的實務管理。

五、DNS 與郵件

• DNS 管理在哪裡——註冊商、主機商、還是第三方服務
• 完整的 DNS 記錄清單——建議截圖保存
• 郵件服務的管理帳號
• 信箱清單、轉寄與別名設定

驗證用的 TXT 記錄最容易被漏掉——搜尋主控台、寄件驗證、第三方服務的驗證。

六、行銷與分析工具

廣告帳戶的資產最容易失去

若帳戶在廠商名下，換廠商時會失去：歷史成效資料、再行銷名單、帳戶的學習成果、轉換設定。

這些是多年累積的資產，重建需要時間與預算。見廣告代操的常見問題與判斷。

分析工具不要重建

沿用既有帳號才能保留歷史資料。 重新建立等於過去的數據全部斷掉，無法做年度比較。

見分析工具怎麼安裝與驗證。

七、串接與第三方服務

• 金流的商店代號與設定
• 物流與電子發票的帳號
• 簡訊或通知服務
• 各項 API 的金鑰與到期日
• 接收改版通知的信箱

最後一項很重要——服務商的規格變更通知會寄到申請時留的信箱，若那是廠商的信箱，你就收不到了。

八、營運相關

• 後台管理員帳號——並移除廠商不再需要的帳號
• 各項到期日總表
• 已知問題的清單
• 維護紀錄——做過哪些調整
• 技術支援的聯絡窗口

交接的執行方式

建議的流程

1. 提前告知並約定交接時間
2. 提供交接清單——依上述項目逐一列出
3. 安排交接會議——新舊廠商與業主三方在場最理想
4. 逐項確認並簽收
5. 當場驗證關鍵項目——備份、帳號能否登入
6. 保留一段重疊期——舊廠商可回答問題

重疊期的價值

建議約定一到二週的重疊期，讓新廠商接手後遇到問題時還能詢問。

這對雙方都好——舊廠商能體面地結束，業主能降低風險。

交接後要做的事

1. 更改所有密碼——後台、主機、資料庫、檔案傳輸
2. 移除舊廠商的權限——各系統逐一檢查
3. 確認通知信箱都改為公司的
4. 自行下載一份完整備份
5. 確認各項功能正常運作

第一項與第二項應該在交接完成後立即執行，這不是不信任，而是標準的作業程序。

如果廠商不配合

這是實務上會遇到的情況。可行的做法：

• 依合約主張——若合約有約定交付項目
• 從自己能控制的部分著手——網域若在自己名下，至少能重新指向
• 從前台抓取內容——雖然不完整，但能保留文字與圖片
• 評估重建——有時候比追討更快

這也是為什麼要事先約定

合約中應明確寫出：合作結束時應交付哪些項目、以什麼形式、多久內完成。

見網站設計合約應該包含哪些條款。

從一開始就避免被綁住

與其在換廠商時費力取回，不如在合作之初就安排好：

1. 網域自行註冊，註冊人登記公司
2. 主機帳號用公司名義申請
3. 分析工具與廣告帳戶用公司帳號建立，廠商加為使用者
4. 圖庫與模板授權用公司帳號購買
5. 合約中明定原始碼與素材的交付
6. 定期自行下載備份

這六件事的成本幾乎為零，但它們決定了日後的自由度。

正派的廠商不會反對這樣的安排——如果對方堅持要把資產放在自己名下，那本身就是需要留意的訊號。

各服務商與廠商的作業方式差異很大，本文說明的是盤點與風險控管的原則。實際的交接內容與流程，建議以合約約定為準並逐項確認。