Google サイト（Google Sites）をバックアップする方法

　Google サイトを使っていらっしゃる方は、サイトのバックアップをどうするか悩むところかと思います。

google-sites-liberation で公開されているツールは動かない

 　ツールの最新版は、2011/04/27 で google-sites-liberation-1.0.4.jar  の公開が終わっています。

google-sites-liberation で公開されているツールの一覧

　　しかしながら、google-sites-liberation-1.0.4.jar　を実行すると、以下の認証エラーが出ます。

google-sites-liberation-1.0.4.jar を実行すると表示される認証エラー

GitHub からツールの最新版をダウンロードしてバックアップする

 　google-sites-liberation - issue #107 （ソースは英語）を確認すると、https://github.com/sih4sing5hong5/google-sites-liberation　の方で開発が続行しているので、そちらを確認します。


　操作手順は次のとおりです。

　1. Google Sites Import/Export Tool のセクションからツールをダウンロードします。
　最新バージョンは 1.0.6 です（2017/01/23 現在）。

Google Sites Import/Export Tool のダウンロード

　2. google-sites-liberation-1.0.6-jar-with-dependencies.jar　がダウンロードされますので、ダブルクリックで実行します。
　実行にあたっては事前に Java をインストールしておく必要があります。

 

Google Sites Import/Exportツール

　3. 必要事項を入力してから、“Get a token from browser” をクリックします。
　すると、google がユーザ許可を求めるページが表示されますので、“許可”ボタンをクリックします。
　※事前に Google アカウントにログインしておく必要があります。

google-sites-liberation のアクセスを許可する

　4. トークンが発行されますので、クリップボードにコピーします。

表示されたトークンをクリップボードにコピー

　5. コピーしたトークンをツールに貼りつけてから、“Export from Sites”　をクリックすると、バックアップが始まります。

　※当然のことながら、トークンには有効期限があります。トークンが無効になった場合は、“Get a token from brower”をクリックすることによって、トークンを取得しなおしてください。

　6. Export　Complete が表示されたらバックアップ完了です。

　その他のバックアップツールとして、弊社では WinHTTTrack を使用していますが、このツールの使い方については、また機会をあらためてご紹介したいと思います。

仮想マシン復旧メモ ― 次にやらかしたときのために

またやらかしてしまった...orz
最近退役したQNAPのiSCSI上にある仮想マシンに故あってアクセスしようとしたところアクセスできず、ping は返れどもブラウザからアクセスできない状態。　そこで、QNAP本体の正面にあるボタン（SELECT ― ENTER）を何気に数回押したところ、RAIDを再構成してしまった模様　ヽ(`Д´)ﾉ　
何たる不覚...

　ということで、バックアップから他のHypervisor上に回復することに。この機会（＝やらかした機会）に回復時のオプションを確認してみることにした。　以下、そのメモです。

Windows Server バックアップを進めると、以下の画面が表示される。



ここで、上図のように［Hyper-V］を選択して“次へ”をクリックすると、下図となる。



すべての仮想マシンを回復するには［Hyper-V］を選択すればいいのだが、特定の仮想マシンのみを復旧しようとすると、ご覧のごとくトホホな状態。回復が完了すると、回復先のフォルダの名称も同じくトホホな名称となるが、このトホホフォルダ内のVHD名（が適切に指定されていれば）からマシン名が特定できる。

ただ、そんなことをやっている暇はないので、「回復種類の選択」画面（冒頭の図）に戻り、［ボリューム］を選択し、“次へ”を押すと下図となる。



ご覧のように、オリジナルのボリュームに1対1で対応するように回復先のボリュームを用意しなければならない。　今回は、一つのボリュームに仮想マシンのC/E/Fドライブをまとめてしまうつもりなので、このオプションは見送る。

注：このオプションは、回復先のボリュームを初期化してしまうので、要注意。


で、結局、冒頭の画面に戻り、［ファイルおよびフォルダー］を選択し、“次へ”を押すと以下の画面。




仮想マシンを選んで、“回復”。　
元の仮想マシンはC/E/Fに分かれているのだが、このウィザードでは1回に1つのボリュームしか復旧できない（1つのボリューム内であれば、複数のファイル/フォルダ選択可）。


以下、回復操作を3回繰り返し、目的の仮想マシンのC/E/Fを回復、他のHypervisor上で仮想マシンを再構築し、無事起動することができた。

また、無駄な仕事をしてまった (ノД`)ハァ


（土屋）

参考サイト：
Windows Server 2012 R2 Hyper-V バックアップ／リストア設計・導入・運用ガイド

富士通の技術ドキュメントは何気に凄い。いつもお世話になってますm(,_,)m 

iSCSI を利用したFileMaker Server の冗長構成を考える

　先日の記事で、FileMaker Server 14 オリジナルのスタンバイサーバ機能のテスト環境構築方法についてご紹介しましたが、このスタンバイサーバ機能には、以下のような問題点があります。

1. プライマリからスタンバイサーバへの切り替えはコマンドライン入力が必要で面倒で、誤操作が発生する可能性がある
2. 前回保存以降（0～99分間）のデータが失われる

　そこで今回は、上記のスタンバイサーバ機能の代わりに、プライマリ/スタンバイサーバでiSCSIディスクを共有するように設定し、障害時にはサーバ切替を行う冗長構成を考えてみました。

尚、本稿でもプライマリサーバの代替機という意味でスタンバイサーバという言葉を使用しています。 前稿のFileMaker Server 14 オリジナルのスタンバイサーバ機能と混乱しないようにご注意ください。

注意点：

　本記事でご紹介する操作は、動作を保証するものではありません。
　実運用前に社内で入念な動作検証を行い、お客様の責任で導入をお願いします。

　前回構築した仮想マシン二台を流用した iSCSI ドライブ共有モデルがこちらになります。

iSCSI ドライブの共有によるデータベース公開モデル
平常時はスタンバイサーバはiSCSIドライブには接続せず、プライマリサーバがダウンした時にのみ接続する

iSCSI ターゲットに配置されたデータベースファイルを FileMaker Server で公開することによって、緊急時にはスタンバイサーバから同じデータベースファイルにアクセスできるようにします。
　※スタンバイサーバ側は、初回導入時にプライマリサーバと同様に iSCSI ドライブ内のデータベースを公開できるように設定します。設定後に iSCSI ドライブを切断するため、上図では接続状態を黄色の矢印で示してあります。

プライマリサーバの設定：

　iSCSIターゲット上でデータベース専用ドライブを作成し、プライマリサーバ上にマウントします（下図のEドライブ）。

　このとき、FileMaker Server 14 アプリケーションはCドライブにインストールし、データベースファイルはすべて iSCSI ドライブ（Eドライブ）に配置します。

　たとえば、下図のように iSCSI ドライブを E: ドライブとしてマウント。その中に FmData フォルダを作成して、この中に FileMaker データベースファイル群を配置します。

次に FileMaker Server Admin Console を使用し、上記で作成したデータフォルダが公開されるようにそのフォルダのパスを指定します。

　下図では、filewin:/E:/FmData/ が公開されるように設定しています。
　また、データベースファイル破損時に備えて、バックアップはローカルディスク上に取っておきます。




スタンバイサーバーの設定：

　プライマリサーバで iSCSI を切断し、FileMaker Server を停止させます。
　プライマリサーバの設定内容と同様にスタンバイサーバの設定を行います。

　※ プライマリサーバの FileMaker Server の動作競合や、iSCSI ディスクへの書き込みエラーを防止するために、スタンバイサーバの設定が終わったら FileMaker Server を停止させて iSCSI 接続を切断しておきます。
　iSCSI の切断後は、スタンバイサーバをシャットダウンします。

正常時の操作

　普段はプライマリサーバのみ稼働させておきます。

プライマリサーバ稼働時の iSCSI 接続状態

緊急時の操作

　プライマリサーバのメンテナンスが必要になったり、プライマリサーバに障害が発生したりした場合は、FileMaker Server を停止させて iSCSI ドライブへの接続を切断します。

　そして、スタンバイサーバから iSCSI ドライブへ接続後に、FileMaker Server を起動します。

スタンバイサーバ稼働時の iSCSI 接続状態

ポイント：
　― FileMaker Server 14 のサーバ切替コマンド操作が不要な分、サーバのダウンタイムは短縮できますが、プライマリサーバの iSCSI 切断、スタンバイサーバの iSCSI 接続と FileMaker Server 起動までの操作は手動作業になります。

　― スタンバイサーバはプライマリで運用していたファイルを直接引き続くため復旧時にデータロスは発生しませんが、iSCSIターゲット（ディバイス）の堅牢性が要求されます。RAID6やRAID10などの採用を検討してください。

　― FileMaker Server 14 以前の FileMaker Server にも応用できます。

とっても重要：

　フルバックアップ及びプログレッシブバックアップにより作成されるバックアップファイルは iSCSI ディスク上ではなく、ローカルディスク及び外部メディアに取ることをおすすめします。

　これにより、iSCSI ターゲット自体が故障した場合に、ローカルディスクにあるバックアップから復旧作業を行えます。
　また、ローカルディスクも同時に損傷しまった場合にも、外部メディアから復旧する手段が残ることになります。

FileMaker バックアップ関連記事：

Hyper-V VMを使用しFileMakerスタンバイサーバーのテスト環境を構築する
データベースのバックアップ方法
FileMaker Server のプログレッシブバックアップ機能の考え方と使い方

以上

Hyper-V 関連記事：

Hyper-V の仮想マシンの移行方法（エクスポート＆インポート）
Hyper-V の仮想マシンのエクスポート時の注意点
物理マシンを Hyper-V 仮想マシンに移行する（P2V）
Hyper-V のゲスト OS を起動しようとすると、「一般のアクセスが拒否されました」というメッセージが表示される
計画停電対策(1) --- ノートPCサーバとHyper-Vで乗り切る

【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者：中級、5時間×1日)

（亀）

Hyper-V VMを使用しFileMakerスタンバイサーバーのテスト環境を構築する

　FileMaker Server 14 でスタンバイサーバーが導入されたことにより、システムメンテナンス時や障害時にもすみやかに FileMaker データベース作業を再開できるようになりました。


　スタンバイサーバー - 概要


　プログレッシブバックアップを利用した現用系（プライマリ）と予備系（スタンバイ）のサーバ切替が可能になった分、突然のデータロスの可能性を低減できることは大きいと思います。

　しかしながら、切替制御が自動でないため、人為作業がどうしても発生してしまう点や、緊急時に FileMaker Server 管理者が対応不能の場合に作業が一時中断してしまう点などの問題は残りますので、緊急時の作業規則をあらかじめ社内で決めておくことが大切です。

　今回は、Windows OS で FileMaker Server 14 のスタンバイサーバー機能の動作検証を行いたい方のために、スタンバイサーバーのテスト環境を Hyper-V の仮想マシンを使って手っ取り早く構築する方法をご紹介します。

Hyper-V 上の仮想マシン（VM）のイメージ ― 1台のホストOS上で複数のVMを運用する

準備するもの

1. Hyper-V サービスがインストールされたコンピュータ 1 台
　今回は Windows Server 12 を使用しています。

2. FileMaker Server 14 が動作する Windows Server ライセンス 2 つ
　今回は Windows Server 2008 R2 を使用しています。

3. FileMaker Server 14 ライセンス 1 つ
　スタンバイサーバーを構成する場合、必要な FileMaker Server 14 のライセンスは1つのみです。

Hyper-V 環境の構築方法

1. 一台めの仮想マシンを作成してから仮想ハードディスクを接続します。
　その後、Windows Server OS と　FileMaker Server 14 をインストールし、必要なデータベースファイルを Data/Databases ディレクトリの中に入れておきます。

新規仮想マシンと Windows Server OS および FileMaker Server 14 のインストール

ポイント：
　― Windows Server の IP アドレスを正しく設定し、Windows 認証を済ませておきます。
　― FileMaker Server 14 をインストールしたら、すぐにプログレッシブバックアップ設定をしておきます。



　このとき、プログレッシブバックアップ先のパス名の指定を忘れないようにしてください。
　上図では便宜的に filewin:/C/FMSProgBkup/ を指定してあります。

2. 一台めの仮想マシンをシャットダウンします。
そして、仮想マシンから仮想ハードディスクを削除（切断）します。

仮想マシンから仮想ハードディスクを切り離す

3. 仮想ハードディスク1 (VHD1) を複製して仮想ハードディスク2(VHD2=スタンバイサーバー用VHD）を作成します。
 Windows Server OS と FileMaker Server 14 がインストールされた状態の仮想ハードディスクを複製するため、インストール作業の二度手間を大幅に省くことができます。

仮想ハードディスクを複製する

4. 一台めの仮想マシンに仮想ハードディスク1(VHD1)を再接続し、無事に起動してきたら、二台めの仮想マシンを新規作成し、仮想ハードディスク2(VHD2)を接続し、同様に起動します。

仮想マシンを新規作成して、二台の仮想マシンを稼働させる

ポイント：
　― Active Directory に参加しているサーバを複製した場合は、二台めのサーバはドメインに参加できなくなります。
　このため、一旦ローカルログインし、IP アドレスの変更、コンピュータ名の変更、ワークグループへの切り替えを行ったあとで仮想マシンを再起動し、再度 ActiveDirectory に参加するようにする必要があります。

参考記事：ドメインにログインできなくなって泣かされる

　― Windows OS は新たに仮想ハードディスクを接続すると、Windows 認証作業が必要になります。
　　ボリュームライセンス利用者の場合は、「自動ライセンス認証が始まるまで XX　日です。今すぐ行う場合はここをクリックしてください」をクリックし、指示どおりに操作します。



　シングルライセンス利用者の場合は、「プロダクトキーの変更」をクリックして、二台めの Windows ライセンスを入力します。

　― FileMaker Server 14 のプログレッシブバックアップの設定はプライマリサーバと共通になるので作業は不要です。FileMaker Server に付ける名前だけ変更すれば OK です。

FileMaker Server 14 スタンバイサーバーの設定方法

1. プライマリサーバの公開済データベースを全部閉じます。

　コマンドプロンプトから以下のコマンドを入力します。

fmsadmin standby connect スタンバイサーバーの名前または IP アドレス

　接続およびログインに成功すると、8桁のセットアップコードが表示され、待ち状態となります。
　このセットアップコードをメモしておきます。


2. スタンバイサーバー側でコマンドプロンプトを開き、以下のようにセットアップコードを入力します。

fmsadmin standby accept XXXXXXXX

ログイン成功後、スタンバイサーバー切替のメッセージが出るので y を選択後、ログインします。

3. プライマリサーバに戻り、待ち状態のコマンドプロンプトで Enter キーを押すとスタンバイサーバーへの接続が完了します。

ポイント：
　― スタンバイサーバーでセットアップコードを入力して受理されたものの、セットアップコードが不正だった場合は Enter キーを押すとエラー終了になります。この場合は、手順 1. のコマンド入力からやり直してください。

4. プライマリサーバのコマンドプロンプトで、以下のコマンドを入力します。

fmsadmin standby update

　ログイン成功後、プライマリサーバのデータベースがスタンバイサーバーの公開データベース環境にコピーされます。

5. プライマリサーバのデータベースを再度公開します。

　すると、プライマリサーバとスタンバイサーバーのデータベース同期が行われるようになります。

　このとき、スタンバイサーバーの FileMaker Server Admin Console を開こうとすると、以下のように待機状態であることが確認できます。

　スタンバイサーバーのさらに詳しい設定方法および、スタンバイサーバーの動作確認方法（メンテナンス時、障害発生時のサーバ切替）は、FileMaker 社の公式動画がおすすめですので、ご覧になってみてください。

おまけ： FileMaker Server 14 プライマリサーバとスタンバイサーバの同期関係を解除する方法

　これまで、FileMaker Server 14 でプライマリサーバとスタンバイサーバーで同期が取れるように設定しましたが、逆に同期を解除したいという要望も出てくることでしょう。

　そのようなときは、プライマリサーバ側でコマンドプロンプトより以下のように切断コマンドを入力します。

fmsadmin standby disconnect

　本当にスタンバイサーバーを切断してよいかと聞いてきますので、y を選択し、ログインすると、スタンバイサーバーとの接続が切断されます。

　これにより、今までスタンバイサーバーだった FileMaker Server 14 はスタンドアロンサーバとして動作するようになります。

以上

（亀）

FileMaker バックアップ関連記事：

データベースのバックアップ方法
FileMaker Server のプログレッシブバックアップ機能の考え方と使い方


Hyper-V 関連記事：

Hyper-V の仮想マシンの移行方法（エクスポート＆インポート）
Hyper-V の仮想マシンのエクスポート時の注意点
物理マシンを Hyper-V 仮想マシンに移行する（P2V）
Hyper-V のゲスト OS を起動しようとすると、「一般のアクセスが拒否されました」というメッセージが表示される
計画停電対策(1) --- ノートPCサーバとHyper-Vで乗り切る

【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者：中級、5時間×1日)

FileMaker Server のプログレッシブバックアップ機能の考え方と使い方

通常バックアップとプログレッシブバックアップの違い

　FileMaker Server の通常バックアップ機能のしくみは、以下のとおりです。

　この場合は 8 時間おき、つまり一日 3 回、データベース全体がバックアップされます。
　この全体のバックアップを取ることをフルバックアップと呼びます。

　上記のように定期的にフルバックアップを取っておけば、たとえばバックアップ 1 を取り終えたあとに重大なデータベース障害が発生したとしても、データベースをバックアップ 1 の状態に戻せば業務を再開できます。

　ただし、この場合、バックアップは最長約 8 時間前の状態に戻ってしまいます。
　このうな場合はその約 8 時間分のデータベース作業を丸ごとやり直さなければならないことになります。

　一日の更新データ量が膨大になる業務の場合、この復旧作業は大変な労力と時間を費やすことになりますし、そもそもデータがもと通りになる保証はありません。
　かと言って、フルバックアップを1時間とか数分に1度実行するように設定すれば、パフォーマンスが低下することは明らかです。

　このような欠陥を補うため、FileMaker Server 12/13 にはプログレッシブバックアップ（Progressive Backup）という機能が搭載されています。

　プログレッシブバックアップを図解すると、次のようになります。

　　プログレッシブバックアップでは、データベース全体ではなく更新分のみをバックアップします。これにより、短い時間でバックアップを終了するので、システムのパフォーマンス低下を短い時間に抑えます。上図の例では通常バックアップとは別に60 分おきにプログレッシブバックアップを行っています。


　データベースが損傷しデータベースがダウンした場合、プログレッシブバックアップにより最大 60 分前の状態に戻ってデータベース業務を再開できるようになります。

　ちなみに、プログレッシブバックアップの間隔は 1 分～99分の間で設定できます。


　それでは、プログレッシブバックアップの設定方法と動作確認、データベースの復旧方法について見ていくことにします。


　通常バックアップのスケジュールの考え方と設定方法については、以下の記事をご覧ください。
　前回の記事： データベースのバックアップ方法

本記事の内容は、当方の動作検証結果にもとづくものになっております。
プログレッシブバックアップ機能を検討されている場合は、事前に動作テストを十分に行い、お客様の自己責任で導入していただけますよう、お願いいたします。

プログレッシブ・バックアップの設定方法

　今回は、FileMaker Server 13 を使ったプログレッシブバックアップ機能をご紹介します。
　FileMaker Server 12 でも基本機能は同じですので、設定画面の情報を読み替えてご利用いただけると思います。

　FileMaker 社で公開されているプログレッシブバックアップの日本語ヘルプには誤訳が含まれているため、英語ヘルプをもとに解説していきます。

1. 　FileMaker Server Admin Console にログインし、左ペインの「データベースサーバー」をクリックして「フォルダ」タブを選択します。

　そして、画面下部の「プログレッシブバックアップを有効にする」チェックボックスにチェックを付けると、次のようなメッセージが表示されます。

2. 「保存間隔」と、バックアップフォルダへの「パス」を指定します。

　社内の業務方針に応じて妥当な保存間隔を決定する必要がありますが、とりあえず今回は 60 分を設定しておきます。

　プログレッシブバックアップフォルダは、ここでは G: ドライブのバックアップ用フォルダへのパスを設定してみることにします。

　以下が、これらの条件を設定しおわったところです。

データベース運用中のディスクドライブと、プログレッシブバックアップ用のディスクドライブを分散させることにより、FileMaker Server のパフォーマンスが向上します。

3. “保存”ボタンをクリックした直後は、プログレッシブバックアップ用のフォルダには、以下の 3 つのフォルダが自動生成されます。

• Changes_FMS ― 変更点が記述された .flx 形式のファイル
• Copies_FMS ― 前回のプログレッシブバックアップ実行時点のデータベースのコピー
• InProgress_FMS ― 蓄積された更新点が反映されるまで使用される暫定的なデータベースのコピー

重要：これらの 3 つのフォルダは、ユーザには直接無関係のフォルダとなりますので、中身を変更したり、消去したりしないようにしてください。

　設定後しばらくの間は、公開中のすべてのデータベースがこのプログレッシブバックアップ用フォルダの中にバックアップされますので、公開データベースの数や容量によっては、準備が整うまで時間がかかることがあります。


　InProgress_FMS フォルダは、初回のプログレッシブバックアップに成功すると消去され、その代わりに、タイムスタンプ付きの二種類のフォルダが生成されます。

FileMaker Server のプログレッシブバックアップでは、これらの二種類のバックアップコピーが生成されますので、必要に応じてどちらかの状態に復旧させることができます。

　上記では、スクリーンショットを撮る目的でバックアップの間隔を 1分に変更してフォルダを作成したために、05-15-14-37 と 05-15-14-38 という 1 分間の開きがあるフォルダが作成されていますが、間隔を 60 分にすれば、一時間の開きのあるフォルダが作成されることになります。

プログレッシブ・バックアップからのデータベース復旧方法

1. FileMaker Server Admin Console を使って、復旧させたいデータべ―スを閉じます。
　データベースの閉じ方は、以下の画像をご覧ください。

2. 1. で閉じたデータベースを消去します。

3. 前述の「プログレッシブバックアップの設定方法」の手順 3. で作成された、タイムスタンプ付きのフォルダのうち、復旧させたい時点のフォルダを開き、その中から対象となるデータベースファイルを特定して、FileMaker Server の公開データベースフォルダにコピーします。

　上記は、タイムスタンプが 2014-05-15-1511 のフォルダから、FMServer_Sample.fmp12 ファイルを特定したところです。

このフォルダは、定期的に FileMaker Server からアクセスされる性質のものですので、ファイルを特定したら、そのファイルをすぐにデータベースサーバの方にコピーしてください。

IncrementalBackup フォルダの中では、絶対に直接ファイルを開かないようにしてください。

4. 3. でデータベース公開用フォルダに配置したファイルを開きます。

　復旧操作は以上です。
　これによって、データベースファイルの状態が、2014-05-15-1511 時点でのプログレッシブバックアップ状態に戻りました。


【参照データのみ保存しているオブジェクトフィールドのデータはどうなるのか】

　英語版のヘルプによると、オブジェクトフィールドのデータ格納オプションより、「ファイルの参照データのみ保存」で参照先のみを保存している場合は、その実データは、タイムスタンプ付のフォルダの中に生成される RC_Data_FMS というサブフォルダの中にバックアップされるそうですが、当方の実験ではバックアップされていないようです。

　この点については、日を改めて検証したいと思います。


以上

（亀）



関連記事：
データベースのバックアップ方法


参考記事：
プログレッシブバックアップの設定とバックアップからの復元
Setting up, and restoring from, progressive backup (英語)



【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者：中級、5時間×1日)

NAS のディスクが壊れて大慌て

　サーバデータのバックアップを I-O データ製の NAS HDL-GT R-Series 2.0 に取るタスクが先日から失敗していたのでおかしいと思っていたところ、Status ランプが明滅した状態になっていました。
　そこでログを調べてみると、以下のようなエラーが発生していました。



上図のとおり、ディスク 2 (上から二番目のディスク)に障害が発生し、修復できなかったためディスク交換が必要な状態となっていました。

　このような状態になると、たいていの場合はディスク横のランプが赤色になるらしいのですが、弊社の場合は青色のままだったため、ディスク障害に気付きませんでした。
　ハードウェアは故障するのを前提に使うものですが、やはりこういう現象が発生すると焦りますね。


　以下のサポートページに従ってディスク交換ができます。

ハードディスク（カートリッジ）が故障した場合の交換方法について教えてください。


　以下の手順で操作すると良いでしょう。

1. NAS の電源を落とす。
2. 破損したディスクを取り外す。
3. NAS の電源を入れ、残ったディスクが正常に動作していることをログとシステム状態で確認する(下図参照）。

4. NAS の電源が入ったままで新しいディスクを実装する。すると、自動的に RAID の再構築が行われるので、再構築が始まっていることを確認（下図参照）。

5. 再構築が終われば利用可能。

操作に当たっては、事前にデータのバックアップを取ることをお忘れなく。

Hyper-V のゲスト OS として bkf アーカイブを復元してみる(2/2)

　さて、前回の ASR バックアップセットによる自動復旧の失敗を踏まえ、今回は Hyper-V のゲスト OS 環境に Windows Server 2003 をインストールした後で、手動でシステム情報を復旧する方法について記述します。

【操作方法】
1. ゲスト OS に Windows Server 2003 をインストールする。
　Hyper-V の仮想マシン設定については割愛します。
　Windows Server 2003 の仮想マシンへのインストールについては、過去記事（Hyper-V にゲスト OS をインストール（覚え書き））で紹介しているとおり、SP2 以降のインストールディスクを使用しなければブルースクリーンが出てクラッシュするので注意が必要です。

2. 1. でインストールした Windows Server 2003 をネットワークに参加させる。
　既存ドメインや既存ワークグループへ参加させるようにゲスト OS の Windows Server 2003 の設定を変更して、ネットワーク経由でバックアップアーカイブ(.bkf) にアクセスできるようにしておきます。

3. バックアップツールを起動し、復旧コマンドでシステム状態を復旧する。
　ゲスト OS より「スタート」→「すべてのプログラム」→「アクセサリ」→「システムツール」→「バックアップ」の順に選択してバックアップツールを起動し、「復元ウィザード（詳細）(R)」をクリックします。



　すると復元ウィザードが表示されますので、2. のネットワーク上に配置されているバックアップアーカイブを指定し、左ペインの[System State]項目にチェックを付けます。
（バックアップアーカイブは DVD-R に焼いたものをゲスト OS に認識させても構いません。）



　“次へ”をクリックすると、以下のような警告メッセージが出ますので、本当にシステム状態がバックアップのもので上書きされても良ければ“OK”をクリックして復元を実行します。



【システム状態復元によって発生する不具合】
　前述の操作によってシステム状態を復元すると、旧環境のシステム状態が引き継がれた形となりますので、次のような問題が起こります。

1) コンピュータ名の重複
　同一ネットワーク上に同じコンピュータ名のマシンが複数台存在すると、警告メッセージがデスクトップに表示されます。
　新環境の方のコンピュータ名を適切なものに変更するか、旧環境のコンピュータをネットワークから切り外してください。

2) IP アドレスの重複
　コンピュータ名と同様に、同一ネットワーク上に複数の同一 IP アドレスを割り当てることはできませんので、新環境または旧環境の IP アドレスを適切なものに変更してください。

3) Windows のライセンス認証の不具合（特に注意）
　上記 1)、2) を行う前に、Windows ライセンス認証を促すメッセージが表示された場合、その時点で仮想ネットワークカードが動作停止状態となるため、インターネット経由でのライセンス認証はできなくなります。
　このため、認証手続きはライセンス認証ウィザードの電話認証の手続きを選択し、音声ガイダンスに従って認証を行う必要があります。

4) アンチウィルスソフトを始めとする、システム関連ソフトウェアの再インストール
　システム状態復旧ではソフトウェアまでは復旧されないため、Windows Server 2003 起動時にソフトウェアがインストールされていないという旨のエラーメッセージが表示されることがあります。必要に応じてインストールし直してください。

5) 旧環境で発生していたイベントエラー
　旧環境のシステム状態を復旧した場合、旧環境で発生していたイベントエラーの一部がそのまま継承されることがあります。
　イベントビューアで発生しているエラーを調べ、必要に応じて修正する必要があります。

　その他の不具合や問題点などは見つけ次第こちらに記述していく予定です。

　今後の課題としては以下のものがありますが、また機会ができたときに対応したいと思います。

1. 複数ボリュームを持つ BKF の Hyper-V ゲスト OS への復旧
2. VHD の復旧

Hyper-V のゲスト OS として bkf アーカイブを復元してみる(1/2)

　既存の Windows Server 2003 サーバ機の環境を Hyper-V のゲスト OS にごっそり移行してみようということになり、試してみたのですが Hyper-V では自動システム回復 (ASR) セットからの復旧はやはり無理があることがわかりました。

　今回は失敗談を踏まえて、手動によるシステム状態の復旧までをまとめることにします。

　操作にあたり、以下のMicrosoft 社の技術情報ページを参考にしました。
　ハード的に独立したマシンを準備して、ページの記載どおりに操作すれば復旧はそれほど難しくないのではないかと思います。
Windows Server 2003 のデータをバックアップおよび復元する

　今回は Hyper-V のゲスト OS 環境で復旧作業をするということで、以下の問題がネックとなりました。

A. フロッピーディスクをどうやってゲスト OS に認識させるか。
　自動システム回復 (ASR) を行う場合は、元環境のパーティション情報はフロッピーディスクに記録されているため、フロッピーディスクを読み込ませる仕組みが必要となります。
　しかし Hyper-V のゲスト OS 環境では、物理的なフロッピーディスクを認識できないため、フロッピーディスクのイメージファイルを仮想フロッピーディスクファイル（.vfd）として保存し、それを読み込ませる必要があります。

　.vfd ファイル（イメージファイル）を作成するツールは Microsoft 社では提供されていないため、適当なツールをどこからか調達する必要があります。

　今回は K.Takata さんが公開している Read/Write FD というツールを使いました。
　 Read/Write FD の仕様およびダウンロードページはこちら

　使い方は仕様のページに書かれているとおりですが、フロッピードライブを丸ごとイメージファイル化するには次のように指定します（.vfd 拡張子前のファイル名は任意です）。

　rwfd a: c:\fdimageW2003.vfd

　この操作で作成した .vfd ファイルをゲスト OS に認識させるための設定を行います。
　この .vfd ファイルは Hyper-V のホスト OS の適当な場所に保存しておきます（今回は f:\に入れることにします）。
　Hyper-V マネージャを開き、Windows 2003 用の仮想ハードディスクを割り当てた後で、設定を開き、以下の図のように仮想フロッピーディスクを割り当てて適用させます。
　


　この操作を行うことによって、ゲスト OS からフロッピーディスクを仮想的に読み込ませることが可能となります。

B. バックアップアーカイブ（.bkf）をどうやってゲスト OS に認識させるか。

　ASR による自動システム回復を行うにあたり、途中で .bkf の指定を求められるわけですが、Windows 2003 のインストーラでは、このファイルの配置場所として物理的に接続されている HDD デバイスを想定しているようで、ここで躓いてしまいました。
　この時点で自動システム復旧操作は断念せざるを得なかったわけですが、操作としてはなかなか面白いものでしたので、掲載することにします。

【操作手順】
1. ASR バックアップセットを作成する。
「スタート」→「すべてのプログラム」→「アクセサリ」→「システムツール」→「バックアップ」の順に選択すると、次のような画面が表示されるので、[常にウィザードモードで開始する]のチェックボックスを外して一度“キャンセル”をクリックしてプログラムを終了させます。



　もう一度バックアップツールを開くと、今度はバックアップウィザードが開きますので、画面一番下の「自動システム回復ウィザード(A)」を選択します。



　すると自動システム回復の準備ウィザードが開きますので、図のようにバックアップアーカイブ名を指定します（.bkf 前のファイル名は任意です）。
　“次へ”をクリックすると、バックアップが始まります。



注意：この操作を行うにあたり、パーティション情報がフロッピーディスクに書き込まれます（前述の仮想フロッピーの記述参照）。このため、フォーマット済のフロッピーディスクをフロッピーディスクドライブに入れておいてください。

　フロッピーディスクを作り忘れてしまった場合は、手動でも作成できます。
　フォーマット済のフロッピーディスクを用意し、C:\WINDOWS\repair\ 配下の asr.sif および asrpnp.sif をこのフロッピーディスクにコピーしてください。

2. Hyper-V 環境を準備する。
　Hyper-V 環境にゲスト OS 用の領域を割り当てておきます。
　このとき、システムドライブとなる vhd の容量は移行元のシステムドライブの容量と同じか、それ以上になるように設定します。
　この時点で前述にあったとおり、仮想フロッピーの設定も行います。

3. Windows Server 2003 インストーラーディスクを入れてゲスト OS を起動し、途中で ASR による復旧モードに入る。

　インストーラーディスクを入れてゲスト OS を起動するとインストールが始まります。
　程なくして Press F2 to run Automated System Recovery (ASR) というメッセージが画面下に表示されますので、ここで F2 キーを押すと、次の画面に切り替わります。



　フロッピーディスクを入れてくださいというメッセージですが、すでに仮想フロッピーディスクを設定してありますので、任意のキーを押すことによって、次のような画面が表示されます。



　C キーを押してパーティションの削除、修復を行うと、システムが一旦インストールされます。

　ある程度までインストールが進むと、インストーラがシステム状態のバックアップアーカイブを読み込もうとして以下のエラーが発生します。



　ローカル環境にバックアップアーカイブが無いのでこのようなエラーが発生するのは当然と言えば当然ですが、上記 1. の手順で作成した .bkf ファイルを DVD-R に焼いて読み込ませようとしても、この段階では Windows Server 2003 のインストーラが DVD ドライブの認識を行っていないようで、このバックアップアーカイブを読み込ませることができなかったため、この時点で自動復旧操作は断念しました。

　もし、同じような方法で ASR 操作がうまく行った方がいらっしゃったら、情報をいただけると幸いです。

　次回は手動システム復旧と、復旧後の注意事項についてまとめます。