Microsoft SQL Server 2016 実践シリーズ （HTML 版）
「SQL Server 2016 への移行とアップグレードの実践」

3.16　アップグレード前に実行しておくべき作業（バックアップ）

繰り返しになりますが、このケースでは、アップグレード後に、旧システム環境が利用できなくなってしまう（以前のバージョンの SQL Server が完全に利用できなくなってしまう）ことになるので、万が一のアップグレードの失敗に備えて、アップグレード前にはバックアップをしておくことが重要です。SQL Server に関しては、サービス マスター キーと全データベースのオフライン バックアップ（ユーザー データベースに関してはオンライン バックアップでも可）を取得しておくことがお勧めになります。

◆ サービス マスター キーのバックアップ

サービス マスター キーは、SQL Server の各種の暗号化における最も重要なキーとなるものです。これについては、オンライン ブックの以下のトピックを一読しておくことをお勧めします。

暗号化階層
http://msdn.microsoft.com/ja-jp/library/ms189586.aspx

サービス マスター キーは、リンク サーバーのセキュリティ設定（リモート ログインのパスワードなど）や、データベース メールでのメール サーバーへのログイン パスワード、TDE（透過的なデータ暗号化）で利用するデータベース マスター キーなどで利用され、（内部的なデータを含めた）各種のデータを暗号化するための最も重要なキーになります。

サービス マスター キーをバックアップするには、次のように BACKUP SERVICE MASTER KEY ステートメントを実行します。

TO FILE で指定するファイル名は、皆さんの環境に合わせて変更してください。また、ENCRYPTION BY PASSWORD で指定するパスワードは、複雑なパスワード（大文字と小文字、@などの特殊文字を含むなど）にする必要があり、復元時に必要となるパスワードです（復元は、RESTORE SERVICE MASTER KEY ステートメントで行うことができます）。

ただし、バックアップしたサービス マスター キーを復元できるのは、SQL Server サービスのサービス アカウントが同じ場合のみになるので、OS を入れ替えたりした場合を考慮すると、サービス アカウントを Active Directory のドメインのユーザーにしておく必要があります（∵OS を入れ替えると、Windows のローカル ユーザーには、異なる Security ID が割り当てられてしまうため、ローカル ユーザーをサービス アカウントにしていると、OS 入れ替え時にサービス マスター キーを復元できなくなってしまいます）。

もし、サービス マスター キーを復元できない場合は、このキーを利用して暗号化された機能が次のように利用できなくなります。

これは、SQL Server 2008 でリンク サーバーを利用しているときのエラーですが、「暗号化解除中にエラーが発生しました」と表示されます。

データベース メール機能を利用していて、メールサーバーへのログイン情報を設定している場合には、これと同じエラーで、利用できなくなります。

TDE（透過的なデータ暗号化）を利用している場合は、データベース マスター キーが、サービス マスター キーに依存しているので、TDE が利用できなくなります。

こうした状況を回避するための方法（どうしてもサービス マスター キーを復元できない状況への対処方法）として、サービス マスター キーを作成し直す（REGENERATE する）ということもできます。これは、次のように ALTER SERVICE MASTER KEY ステートメントを実行します。

暗号化が関連する機能や、パスワードの設定を含むような機能の動作で、エラーになる場合は、サービス マスター キーをぜひ確認してみてください。「暗号化解除中にエラー」がキーワードです。

もし、上記のステートメントがエラーになる場合は、次のように FORCE オプションを付けて、強制的に作成し直すことも検討してみてください。

ただし、このように、FORCE を利用した場合は、暗号設定が失われる可能性があるので、暗号化が関連する機能（リンク サーバーのセキュリティ設定やデータベース メールでのメールサーバーへのログイン情報など）の再設定が必要になる場合があります。データベース マスター キーや証明書を利用している場合には、それらも旧マスターでバックアップしておくことをお勧めします。

◆ 全データベースのオフライン バックアップを取得しておく

アップグレード前には、全データベースのオフライン バックアップ（ユーザー データベースに関してはオンライン バックアップでも可）を取得しておくことがお勧めになります。master や msdb などのシステム データベースのオフライン バックアップは、次のように行います。

まず、オフライン バックアップを取得するために SQL Server サービスと SQL Server Agent サービスを停止します（フルテキスト検索機能を利用している場合は、SQL Full-text Filter Daemon Launcher サービスも停止します）。

SQL Server サービスの停止が完了したら、すべてのデータベースのデータ ファイル（.mdf）とトランザクション ログ ファイル（.ldf）を、ファイル コピーで取得します。

SQL Server 2008 の場合は、既定ではシステム データベースは、次のフォルダーに格納されています。

C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA

SQL Server 2008 R2／2012／2014 の場合は、既定では次のフォルダーになります。

SQL Server 2008 R2 の場合C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA

SQL Server 2012 の場合C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA

SQL Server 2014 の場合C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA

システム データベースを含めた、ユーザー データベースが格納されているフォルダーは、次のように sysdatabases 互換ビューの filename 列を参照することで確認することができます。

ここにリストされるデータベースのファイル（.mdf）とそれに対応したログ ファイル（.ldf）をすべてコピーするようにします。このビューでは、.ldf ファイルの場所が分からないので、これを確認したい場合には、次のように sys.database_files システム ビューの physical_name 列を参照するようにします。

以上で、アップグレード前のバックアップ作業が完了です。

万が一の際に、システム データベースをオフライン バックアップから復元する際には、現在と全く同じ構成の OS／SQL Server であることが重要です。OS の場合は、参加するドメイン、マシン名、ドライブ／フォルダー構成、NTFS アクセス許可、共有フォルダー構成、SQL Server の場合は、インストール先のパスや照合順序、サービス アカウントを同じ構成にしておくこと、同じ修正プログラム（Service Pack や CU）をインストールしておくことが重要になります。

フォルダー構成やインストール先のパスが変わってしまうと、オフライン バックアップを元に戻しても、SQL Server が正しく起動しなくなってしまうので注意してください。このあたりの OS を入れ替えた場合の注意点は、次の章で説明するハードウェア リプレース時の丸ごと複製の作業と全く同じ考え方、対処方法になるので、次の章もぜひご覧いただければと思います。

もし、サービス アカウントに Windows のローカル ユーザーを設定している場合は、OS を入れ替えることによって、同じ名前のユーザーを作成しても、異なる Security ID（SID）が割り当てられてしまうので、（内部的には）別のユーザーとして見なされてしまいます。こうなると、サービス マスター キーでエラーが出ることになるので、こういった場合には、前述の ALTER SERVICE MASTER KEY を利用してサービス マスター キーを強制的に作成し直す（REGENERATE する）といったことも必要になってきます。

また、Windows のローカル ユーザーを利用している場合には、特にセキュリティ関連の設定で影響が出てくるところがいくつかあるので、これらについては、次の章もぜひご覧いただければと思います。

なお、OS の再インストールが発生するような事態を避けるには、サードパーティ製のイメージ バックアップ ツール（ストレージ レベルで丸ごとバックアップ可能なソフト）を利用したり、仮想マシン環境であれば仮想マシンを丸ごとバックアップしておいたりするのも １つの方法です。これであれば、同じ構成の OS／SQL Server を簡単に戻せます。

いずれにしても、同一マシンでアップグレードを行う場合は、万が一の失敗時における、ロールバックにかかる時間も考慮して、アップグレード時間を見積もっておくことが重要になります。