課程名稱： 資料庫系統

8. 線上備份 (Online Backup)

Properties3
description—
tagsmssql
date2026-06-28

閲覽人數 -- 次

線上備份的核心價值與策略概覽

在現代企業營運中，資料庫的持續可用性是維持業務不中斷的基石。SQL Server 線上備份 (Online Backup) 正是為此而生的關鍵技術，其核心優勢在於，備份作業進行的當下，使用者與應用程式服務無須中斷，可維持線上運作，從而最大化系統的正常運行時間 (Uptime)。

本文的目標是為資料庫管理員 (DBA)、系統架構師及 IT 專業人員，提供一套清晰、完整且可依循實作的 SQL Server 線上備份與還原操作指南。我們將從策略層面的決策，深入到具體的操作實踐，確保讀者能全面掌握這項核心技能。

實現線上備份的方式可歸納為三類
1. 手動備份與還原
2. 透過維護計畫建立「備份資料庫工作」
3. 透過維護計畫建立「TSQL 工作」

本文將聚焦於第一種方式——「手動備份與還原」。精通手動操作是理解並驗證所有自動化備份工作的基础。更重要的是，手動備份對於處理非標準情境至關重要，例如資料庫遷移、建立供開發或測試使用的拋棄式複本，以及在重大變更前建立即時還原點，這些任務往往落在排程維護計畫的範疇之外。

在深入操作細節之前，首要任務是理解並選擇最適合自身業務需求的備份策略。這是制定任何成功備份計畫的第一步，我們將在下一章節深入探討。

關鍵決策：解析資料庫備份類型與策略

  1. 備份策略選擇
    選擇一套合適的備份策略，是一項需要在復原時間目標 (RTO)、儲存成本與系統效能之間取得精妙平衡的關鍵決策。不同的策略組合將直接影響到資料的可回復性與災難發生時的應對效率。以下，我們將分析三種常見的備份方案。

  1. 方案分析與比較
    資料庫備份類型有分

    • 完整備份
    • 差異備份

    方案 1 (每日完整備份)
    優點： 此策略的還原流程最為簡單直觀。當災難發生時，只需使用離事發時間點最近的一份完整備份檔案即可完成還原，因此復原速度最快。

    缺點： 顯而易見，每日執行完整備份會消耗大量的儲存空間，且備份過程對系統 I/O 的負擔最重、耗時最長，可能影響線上服務的效能。

    方案 2 (週期性完整備份 + 差異備份)
    優點： 此混合策略在備份效率與儲存成本之間取得了良好平衡。相較於方案 1，它顯著減少了每日的備份檔案大小與備份所需時間。

    還原流程： 還原時需要兩份備份檔案。此流程至關重要，必須正確執行：首先還原在目標差異備份之前、離它最近的一份完整備份，接著再還原該份差異備份。例如，若系統在星期六發生故障，則需使用星期五的完整備份，加上星期六的差異備份來進行還原，而非使用星期一的完整備份。

    方案 3 (單次完整備份 + 每日差異備份)
    優點： 此策略最大化地節省了儲存空間，因為每週僅產生一份體積龐大的完整備份檔。

    缺點與風險： 此策略的「備份鏈 (backup chain)」較長，風險也相對較高。整週的復原能力完全依賴於星期一那份單一的完整備份。一旦該檔案損毀，其後所有的差異備份都將失效，導致整週的資料無法復原。因此，對這份基礎完整備份的定期完整性檢查（例如使用 RESTORE VERIFYONLY 命令）變得格外關鍵。其還原路徑為一個兩步驟流程：首先，還原星期一的基礎完整備份，接著，套用離事發時間點最近的一份差異備份（例如星期三的備份）。

    方案 3 的還原路徑，顯示必須先還原完整備份，再還原差異備份

    在理解了不同備份策略的權衡之後，接下來讓我們進入手動執行備份的實作環節，將理論付諸實踐。

實戰演練 (一)：手動執行資料庫備份

  1. 前言
    手動備份是每位 DBA 都必須熟練掌握的基本技能。它不僅是自動化備份的基礎，更在執行重大系統變更、應用程式升級前的防護，或是在緊急情況下建立即時復原點時，扮演著至關重要的角色。本節將以 demodb 資料庫為例，逐步拆解手動執行完整備份的操作流程。

  2. 啟動備份程序
    先建立預備份用的資料夾 D:\dbbackup。

    • 在 SSMS 物件總管中,展開 「資料庫」 節點。
    • 在要備份的資料庫上(例如: demodb)按下右鍵。
    • 依序選擇「工作」(Tasks) ->「備份」 (Backup...)。

  3. 設定備份基本選項
    在「備份資料庫」視窗的「一般」頁面中，進行以下核心設定：

    • 資料庫(Database):確認為目標資料庫 demodb。
    • 備份類型(Backup type):選擇「完整」(Full)。這是建立還原基準點的標準做法。
    • 備份元件(Backup component):選擇「資料庫」(Database)。

    重要操作
    在「目的地」(Destination)區塊,建議先「移除」(Remove)所有預設的備份路徑,以確保備份至您指定的全新檔案中,避免混淆。

  4. 指定備份目的地與檔案

    1. 點擊「加入」(Add)以開啟案選擇

    2. 選取的路徑(Path):導覽至您指定的備份資料夾(例如: C:\dbbackup)

    3. 檔案名稱(File name): 提供一個具描述性的檔名,建議包含資料庫名稱與時間戳記(例如: demodb_20260515_1000000.bak) 。


    4. 點擊「確定」(OK)完成設定。

    跟離線備份不同，只有一個檔案 .bak，所以只能還原，不可以作附加。

  5. 指定備份目的地與檔案名稱
    至此，一個手動的完整備份便設定完成。點擊「確定」後即可開始執行。然而，成功的備份僅完成了資料保護工作的一半，驗證備份有效性的唯一方法是成功地將其還原。接下來，我們將進入還原操作的演練。

實戰演練 (二)：手動還原資料庫

  1. 實戰說明
    資料庫還原是災難復原計畫的核心，其重要性不言而喻。無論是硬體故障、資料損毀還是人為誤操作，一份經過驗證可用的備份檔案，都是企業迅速恢復營運的生命線。本節將演示如何使用上一章節建立的備份檔，將 demodb 資料庫還原。

  2. 啟動還原程序
    還原是備份的逆向操作,同樣從 SSMS 開始。

    • Step1 : 在物件總管中,於「資料庫」節點上demodc 按一下滑鼠右鍵。
    • Step2: 依序選擇「工作(T)」>「還原(R)」>「資料庫(D)…」。

    Pro-Tip: 你也可以在目標資料庫上按右鍵選擇還原,但從「資料庫」節點啟動可以避免選錯目標。

  3. 選取備份來源
    還原前置作業: 指定備份來源
    在「還原資料庫」視窗中,我們需要手動指向備份檔案的位置。




    • 在目前的還原資料庫視窗中，點選左側選單的 「選項」 (Options) 頁籤。
    • 勾選 「關閉至目標資料庫的現有連線」 (Close existing connections to destination database)。
    • 同時建議勾選 「覆寫現有資料庫 (WITH REPLACE)」 (Overwrite the existing database)。
    • 點擊下方的 「確定」 重新執行還原即可。

    與備份不同，還原後還需檢查還原位置是否正確(還原時可能會還原失敗)，打開 檔案 檢查

    • 原始檔案名稱: 當初備份時資訊
    • 還原為: 現在要還原資訊
      因備份檔可能從其他電腦獲取，所以與現在位置可能不同，會嘗試還原與當初一樣的資料夾與檔案，但若找不到當除資料夾，系統就會隨便為你找個資料夾。
    1. 指令說明:首先,在「來源」區塊,我們將遇原資料庫份案的位置,我們需要手動向的檔案的置。
    2. 装置: 選擇「装置(Device)」 選項。
    3. ... : 點擊旁邊的 「..」 按鈕,開啟「選取備份装置」视窗。
    4. 備份媒體類型:確認類型為「檔案(File)」。
    5. 加入:點擊「加入(Add)」,准備尋您的 .bak 備份檔。

  4. 確認還原路徑及檔名
    安全檢查:確認還原檔案路徑
    在還原前,務必檢查資料庫檔案(.mdf)與記錄檔(.ldf)的最終存放位置。

    • 導覽: 在左側頁面選單中,點選「檔案(Files)」。
    • 驗證:在「還原為(Restore As)」欄位中,仔細檢查檔案路徑。確保此路徑正確,且不會覆寫到任何現存的重要資料庫檔案。

  5. 配置關鍵還原選項

    關鍵決策:
    覆寫與復原狀態
    在左側選單點選「選項(Options),這裡有兩個決定還原成敗的關鍵設定。

    • 覆寫現有的資料庫(WITH REPLACE)
    • 用途:當目標資料庫已存在時,必須勾選此項才能強制以備份檔覆寫。
    • 動作:勾選。
  • 復原狀態(Recovery state)
    • 用途: RESTORE WITH RECOVERY 是還原序列的最後一個步驟。它會將資料庫回復至可供線上使用的狀態。
    • 動作: 確認已選取 RESTORE WITH RECOVERY
  • 伺服器連接
    勾選 「關閉至目標資料庫的現有連線」 (Close existing connections to destination database)。
![[assets/8. 線上備份 (Online Backup)/MSSQL_BACKUP_65_6.png]]

完成上述設定後，點擊「確定」即可執行還原。然而，在實際工作中，您可能會遇到一個常見的挑戰：如果資料庫正在被使用者存取，標準還原將會因為資料庫被鎖定而失敗。下一章節將為您展示如何優雅地處理這個進階情境。

進階情境：處理線上使用者存取下的資料庫還原

  1. 情境說明
    單人模式資料庫的復原
    使用者可能隨時在使用資料庫的情形下,又無法踢除使用者, 這種情形下是無法還原資料庫的,
    因此可以設定資料庫的 屬性/選項/限制存取, 設定成 SINGLE_USER,即可完成還原的動作。

    把網路版資料庫變成單機版，就可進行還原。

    情境模擬:

    • 開啟資料庫作任一操作，表示有人在使用中
      demodb資料庫 > 資料表 > 新增 > 資料表


    • 然後操作還原
      demodb 資料庫 > 工作 > 還原 > 資料庫

    • 一般:

      • 裝置: D:\dbbackup\demodb_20260707_130840.bak

    • 檔案:

    • 選項:

    • 開始還原

    兂資料庫有人使用中，所以還原不會成功。

  2. 問題識別
    還原操作失敗的典型原因，是目標資料庫存在一個或多個有效的使用者連線，導致 SQL Server 無法取得執行還原所需的獨佔鎖定。

  3. 變更資料庫屬性

  4. 啟用單一使用者模式
    選項 > 限制存取 > SINGLE_USER

  5. 設定變更

  6. 執行還原
    在此模式下，除了您當前的 SSMS 連線外，所有其他使用者連線都將被強制中斷。現在，您可以順利地執行上一章節所述的還原程序，而不會再受到連線干擾。

    重點提示
    當還原操作成功完成後，SQL Server 會自動將資料庫的存取模式恢復為預設的 MULTI_USER 模式。您無須手動將其改回，資料庫會立即準備好接受所有使用者的連線。

結論與最佳實踐

本文系統性地闡述了 SQL Server 線上備份與還原的核心程序。我們從高層次的策略選擇（如完整備份與差異備份的組合）開始，逐步深入到手動備份與標準還原的具體操作步驟，最後探討了如何利用「單一使用者模式」技巧，處理生產環境中常見的使用者連線挑戰。掌握這些知識，是確保資料庫安全與業務連續性的基礎。

三項核心的最佳實踐建議

  • 定期驗證備份  僅僅擁有備份檔案是遠遠不夠的。建立備份的最終目的是為了成功還原。必須將定期的還原演練納入維運流程，在隔離的測試環境中驗證備份檔案的完整性與可用性，確保在真正需要時萬無一失。
  • 策略因地制宜  不存在放之四海而皆準的完美備份策略。您應根據業務的實際需求、資料的重要性、可接受的停機時間 (Recovery Time Objective, RTO) 與資料遺失量 (Recovery Point Objective, RPO)，以及儲存成本預算，動態選擇最適合的備份方案（如完整備份、差異備份與交易記錄備份的組合）。
  • 文件化程序  將您環境中的備份與還原標準作業程序 (SOP) 詳細地文件化。這份文件應包含備份排程、備份檔案位置、還原步驟、緊急聯絡人等關鍵資訊。在壓力巨大的緊急情況下，一份清晰的文件能引導任何人迅速、準確地執行復原操作，最大程度地減少人為錯誤。

關係圖譜