Skip to content

MS_WindowsServerBackup

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 1 revision

Windows Server のバックアップ

概要

Windows Server のバックアップについて。

詳細

機能概要

2008 以降の機能概要についてはこちらが参考になる。

変更点

2003（Ntbackup）からの変更点
※ Ntbackup は、NT 3.51 - XP / Server 2003 に同梱される。

  • ボリュームのブロックレベルのバックアップが可能となった。
  • ファイル・レベルのバックアップ機能が復活。
    • ただし、お勧めは、ボリュームバックアップ（速い）。
    • ファイルの種類、パスに基づいた除外機能。
  • バックアップ・スケジュールを指定可能
    （週次等の詳細設定はwbadmin ＋ TaskScheduler を使用）
  • バックアップ・ファイルの形式は *.bkf から *.VHD へ。
  • サポートされるメディア
    • Ntbackup
      • テープ、HDD、ネットワーク共有
    • Windows Server バックアップ
      • HDD、ネットワーク共有、USB、DVD（テープ不可）
        （テープ不可なので、D2D：ディスク to ディスクの後に、D2T：ディスク to テープ）
  • リストアの簡略化（任意の時点への復元）

移行メモ（正誤・体裁）: 原典の以下を修正した。

原典 修正
バックアップシュケジュール バックアップスケジュール
テープ不可ので テープ不可なので
wbaadmin wbadmin（正しいコマンド名。原典は全箇所で a が 1 つ多い）

補足（「ファイル・レベルが復活」の意味）: Windows Server 2008 の
Windows Server バックアップは、当初ボリューム単位のみの対応で、
Ntbackup にあったファイル単位のバックアップができなかった。
これが 2008 R2 で復活した、という経緯である。

本文が「お勧めはボリュームバックアップ（速い）」とするのは、
ブロック レベルで扱えるためである。

方式 単位 速度 適する用途
ボリューム（ブロック レベル） ディスクのブロック 速い（ファイル数の影響を受けにくい） システム復旧、ベア メタル回復
ファイル レベル ファイル ファイル数が多いと遅い 一部のデータのみ退避

特に小さいファイルが大量にある環境では、
ファイル単位はメタデータ処理が支配的になり、極端に遅くなる。

補足（VHD 形式であることの利点）: 出力が *.VHD（現在は *.VHDX）に
変わったことには実務上の意味がある。
専用ツールが無くてもマウントして中身を取り出せる
（ディスクの管理から「VHD の接続」、
または Mount-VHD コマンドレット）。
*.bkf 時代のように、
復元のために同じバックアップ ソフトを用意する必要が無い。

CUI

wbadmin

wbadmin（Windows Server バックアップのコマンド ライン版）

PowerShell

Windows PowerShell コマンドレット

  • 2008R2：Get-Command -Module "Windows.ServerBackup"
  • 2012：Get-Command -Module "WindowsServerBackup"

補足: モジュール名が 2008 R2 と 2012 で異なる
（ドットの有無）点は、スクリプトを両方で動かす際の
実際の落とし穴である。
現行（2012 以降）は WindowsServerBackup に統一されている。

所感

Windows Server バックアップは、

  • 単純な、

    • ファイル・バックアップ
    • イメージ・バックアップ

    だけでなく、

  • VSSバックアップに対応したことで、
    内部が良く見通せなくなってきている
    （また、ドキュメントも十分でない）。

  • また、ICT の多様化・複雑化も重なり、

    特定のアプリケーションのバックアップ用に設計されるということでもあり、
    （例えば Hyper-V のホスト OS からのゲスト OS の VSS バックアップの全体像など、）

    複雑で理解し難いものになる。

  • この場合、個別でのバックアップ設計が困難になり、
    バックアップ ソリューションによるワンストップ対応が必要となってくる。

補足（この所感は現在も的確である）: 「内部が見通せない」という指摘の核心は、
VSS がバックアップを「アプリケーションとの協調作業」にしたことにある。

バックアップ要求
   ↓
① VSS が各アプリ（Writer）に「書き込みを止めろ」と通知
   （SQL Server、Exchange、Hyper-V、AD …）
   ↓
② アプリがデータを整合の取れた状態にして待機（数秒）
   ↓
③ VSS がスナップショットを作成
   ↓
④ アプリに再開を通知

つまり、バックアップの成否が個々のアプリの Writer に依存する。
どれか 1 つの Writer が失敗すれば全体が失敗し、
しかも原因はバックアップ ツール側ではなくアプリ側にある。
後述の KB がまさにその実例である
（.NET のフォルダ数が原因で System Writer が失敗する）。

「ワンストップ対応が必要」という結論も現在の実態と合っており、
対象が Hyper-V・SQL Server・SharePoint・クラウドに跨る現在は、
Azure Backup、System Center DPM、
あるいはサードパーティ製品でまとめて扱うのが一般的である
（Azureの障害復旧、
Hyper-V バックアップ）。

KB

Windows Serverバックアップが失敗する

VSS System Writerが表示されずバックアップに失敗する

https://blogs.technet.microsoft.com/askcorejp/2012/06/27/vss-system-writer/

以下の Hotfix を適用することで対策可能。

  • Windows Server 2008 R2 / 2012 を実行
    しているコンピューターでシステム状態を
    バックアップすることはできません。
    https://support.microsoft.com/ja-jp/kb/2807849

    .NET Framework が実装されている環境において、System Writer は独自のメタデータ情報を準備するために、
    %WinDir%\Microsoft.Net\Framework 配下のサブフォルダを列挙して処理を進める必要があります。
    このフォルダにあるサブフォルダ数が 1,000 個以上存在する場合、システム実装上の制限により
    System Writer がメタデータ情報を正しく準備できず、その結果、"System Writer" が表示されない現象が発生します。

移行メモ（体裁）: 原典の見出しは「Windwos」と誤記されていたため
「Windows」に修正した。

補足（サブフォルダが 1,000 個を超える原因）: この現象は
ASP.NET の一時コンパイル フォルダが肥大した場合に起きやすい。

%WinDir%\Microsoft.NET\Framework(64)\v4.0.30319\Temporary ASP.NET Files\

ASP.NET は動的コンパイルの成果物をここに置くため、
多数のサイトを長期間運用しているサーバでは
サブフォルダが際限なく増える。

応急処置としては、IIS を停止した上でこのフォルダを削除する
（次回アクセス時に再生成される）。
なお、根本的には Hotfix の適用が必要である。

「バックアップの失敗の原因が ASP.NET の一時ファイルにある」という
この事例は、前掲の所感（VSS によって因果が見通しにくくなった）を
端的に示すものと言える。
障害時の分析手法は因果関係の分析例を参照。

Tags: 移行, インフラストラクチャ, Windows, バックアップ, 障害対応

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally