まず、背景を少し説明しましょう。 Linuxシステムでは、すべてのファイルを1つのハードドライブから別のハードドライブに移すことができ、ブートローダーを修正する限り、まったく同じ起動可能な完全な状態のままになるという事実に頻繁に依存しています。機能システム。バックアップと復元でも同じことが機能します(特別なシステム状態のバックアップは必要ありません。ファイルだけです)... MySQLもリカバリ可能ときどきバックアップ時にフリーズしていなかった場合でも
Windowsでは、ファイルレベルでシステムを複製してシステムを複製することはできませんでした。私はいつもVMWare Converter、Ghost、diXMLなどのツールが必要です。それらはドライブ全体のイメージを取得することに基づいています。最初は、これは主にWindowsがレジストリを実行する特別な/不思議な方法によるものであると想定し、質問しませんでした(動作しました)。今日まで。この種の考え方は馬鹿げていること、そして実際にはWindowsも単なるファイルのコレクションにすぎないことに気付きました。テストとして、オフラインのWindows 2003サーバードライブを使用して、ファイルを空のハードドライブにコピーし、ドライブをアクティブにして、完全に機能しました。
それともしましたか? Ghostで期待していたような逐語的クローンではないために失敗するという不合理な恐れがあるのはなぜですか?怖いの?なぜそんなに簡単だったのですか? ADサーバーには違いがありますか?この方法が失敗するケースはありますか?
ファイルごとのコピーが適切な方法である場合、VSSで同じことを実行しようとしたときに(シャドウコピーされたC:ドライブをS:ドライブとして公開)、同じアプローチが失敗したのはなぜですか?より具体的には、ログイン画面までブートシステムを取得しました。それは私のパスワードも受け入れましたが、GUIでエラーなしにユーザーをすぐにログオフしました。コピーする前に、止められないサービスを除いてすべて停止してみたところ、同じ結果になりました。
ちなみに、これらすべてのコピー操作にrobocopy /E /SEC
を使用しています
これらの方法を使用して問題を探しているだけですか?ゴーストなどが証明されていることは知っていますが、なぜホイールを再発明するのですか? ...私はすべてを手に入れました...しかし、私は専門家として、物事が彼らのように機能する理由を知りたいです。これが私がこれを理解することが重要である理由です。 (システム状態のバックアップがなかったシステムでベアメタルリストアを実行する必要があるというまれな可能性は言うまでもありません)
ADサーバーは異なります。ドメインコントローラには、C:\ Windows\SYSVOL\domainディレクトリを指すC:\ Windows\SYSVOL\sysvolディレクトリに ディレクトリジャンクション があります。
Directory of C:\Windows\SYSVOL\sysvol
04/13/2011 01:22 PM <DIR> .
04/13/2011 01:22 PM <DIR> ..
04/13/2011 01:22 PM <JUNCTION> domainName.acme.com [C:\Windows\SYSVOL\domain]
ほとんどすべてのタイプの手動コピー操作では、ジャンクションが壊れているためにSYSVOLがオンラインになりません。これは正確ですが、通常の復元シナリオで発生する可能性があるため、必要に応じてSYSVOLジャンクションを確認して再作成することを常にお勧めします。
リンクといえば、どのWindows 2008/Vista/Windows 7システムでも、バイナリの%SYSTEMROOT%\ System32フォルダーに何千ものリンクがある場合があります。これらのリンクターゲットは、実際には%SYSTEMROOT%\ Winsxsフォルダにあります。
私はこれを確認していませんが、Robocopyはリンクの代わりにターゲットをコピーする場合があります。これは、スイッチ/ SL ::「ターゲットに対するコピーシンボリックリンク」を説明します。
システムは正しく機能しているように見える可能性がありますが、システムの更新アクティビティを実行するときに、リンクターゲットが通常存在するファイルを維持する必要がある場合はどうなりますか?多分それはそれらを再作成しますが、それはテストする価値があるものでしょう。
これらのリンクがコピーされたディスクにどのように転送されるかに興味がある場合は、スナップショットの前と後のスナップショットを取り、WindiffまたはNotepad ++を使用してファイルを比較できます。
次のコマンドを使用して、ドライブのジャンクションポイントの出力を取得できます。
dir C:\ /aL /s >> junctions.txt
ファイル内の次のスクリプトを使用して、場所(たとえば、systemroot)のリンクの出力を取得できます。
for /r %systemroot% %%i in (*.exe,*.dll) do (
echo Checking file: %%i >> file.txt
fsutil.exe hardlink list "%%i" >> file.txt 2>&1
echo . >> file.txt
)
Windows 2000およびWindows XPのファイルレベルのクローンを作成しました(Linux NTFSツールntfsclone
ユーティリティを使用)。 Windows Vista以降のバージョンでntfsclone
を試したことはありませんが、問題が発生することはないと思います。私はMicrosoftのファイルレベルのクローン作成ツールImageX
をWindows XPおよびWindows 7で定期的に使用しており、問題もありません。通常、サーバーコンピューターのクローンは作成しません。しかし、私はImageX
がサーバーOSで正常に動作することを期待します。
稼働中のファイルシステムをコピーすることは常に困難なことです。ボリュームシャドウコピーは、静止ファイルシステムを公開するために想定されていますが、まだチャンスを利用していると思います。 (VSSで複製されたボリュームで何が起こってログオンできなかったのかはわかりません。失敗したクローンを確認できないと、診断するのが本当に難しくなります)。可能であれば、オフラインのシステムのクローンを作成することを常にお勧めします。
完全に静止したファイルシステムをコピーしていて、すべてのファイルを取得できるとすれば、懸念事項は次のとおりです。
Microsoftの bootsect.exe
を使用して、古いNTLDRベースのバージョンのWindows NT(NT 3.5からWindows Server 2003)およびBOOTMGRベースのバージョン(Windows Vista以降)用の適切なMBRおよびPBRを書き込むことができます。 。 Windows 2003のクローンは、NT 5.2形式のPBRを備えたディスクにある必要があります(起動したため)。
NTLDRブートローダーはファイルレベルのコピーでコピーされます。これにより、Windows 2003のコピーが問題なく機能した理由が説明されます。 BOOTMGRブートローダーは、bcdboot.exe
ユーティリティ(BOOTMGRベースのWindowsセットアップメディアに含まれています)を使用してインストールできます。
この方法では、Active Directoryドメインコントローラー(DC)コンピューターを複製しません。元のDCと同じネットワークでDCのクローンをブートするのは、これが完全にサポートされておらず、おそらく計画外であるためです。シナリオ用。
編集(今、実際のコンピューターで数分を過ごしています):
上記のツールImageX
とntfsclone
は、ファイルシステムレベルのクローンツールです(ローセクターモードで実行されていない場合のGhostと同様)。セクターごとにコピーするのではなく、NTFSファイルシステムを解釈します。これらのツールはどちらも、ROBOCOPY
(/SL
引数なし)やXCOPY
(引数あり)のようなジャンクションポイントやハードリンクに問題はありません。
一般に、Microsoftは、システムのファイルレベルのコピーベースのクローン作成を計画していません。ええ、あなたはそれを行うことができますが、それが壊れた場合、あなたはピースを保つようになります。
ライブファイルシステムをVSS
からコピーする場合の問題は、既存のWindowsインスタンスに、レジストリ内に既に存在する新しいディスクの署名があることです。コピーを起動すると、起動元のパーティションのシグネチャがレジストリと照合され、D:
ではなくE:
またはC:
としてマウントされます。
これは、レジストリファイルをマウントしてHKLM\SYSTEM\MountedDevices
を更新することで整理できます。これは、コピー後、再起動する前に実行してください。 \DosDevices\C:
エントリを削除して、新しいドライブのエントリをC:
に変更するだけです。