スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

【同じタグを付けた記事の一覧】

Win7 はファイルのコピーでバックアップできるのか?

2012年04月17日(火)00時43分

目的は VHD ファイルの省サイズ化

今回は、タイトルはずいぶん違いますが、内容的には前回「Win7 のブート VHD ファイルのダイエット」の続きとなります。
まず最初に、「表題の内容が VHD ファイルの省サイズ化にどう関係するのか?」について書いていきたいと思います。

アロケーション ユニット サイズ

Windows で、ハードディスクやメモリカードをフォーマットする際、「アロケーション ユニット サイズ」という項目を設定することができます。
Windows を含む多くの OS では、ファイル管理を効率的に行うため、ハードディスクなどを一定のサイズごとに分割し、そのブロック単位で読み書きをします。
この「アロケーション ユニット サイズ」というのは、そのブロックのサイズのことで、「クラスタサイズ」などと呼ばれることもあります。
そして NTFS においては、この「アロケーション ユニット サイズ」の値が標準で 4KB(= 4096 バイト)となっており、自分が Win7 のブート用に作った VHD ファイルも、(特に変更はしていないため)4096 バイトでフォーマットされています。

クラスタギャップ

前述のとおり、読み書きは指定したブロック単位で行われます。
そのため、例えばブロックのサイズが 4096 バイトのハードディスクに、4097 バイトのファイルを作ると、一ブロックに収まりきらないたった1バイトだけのためにもう一ブロック必要になり、「4096 × 2 = 8192」バイトを消費してしまうことになります。
この、余分に消費してしまった 4095 バイトの無駄な領域は「クラスタギャップ」等と呼ばれ、クラスタサイズが大きければ大きいほど、クラスタギャップも大きくなります。
例えば上記 4097 バイトのファイルを、クラスタサイズが 512 バイトのハードディスクに作った場合、格納のために必要なブロック数は9個、つまり「512 × 9 = 4608」バイトしか消費しませんので、クラスタギャップは「4608 ? 4097 = 511」バイトで済むことになるわけです。

最適なクラスタサイズ

では「クラスタサイズは小さいほどいいのか?」、あるいは「大きなクラスタサイズは何のために存在するのか?」という話になりますが、まず、小さすぎるとファイルを細かく分割することになりますので、分断化が起きやすくなります。
つまり、ファイル読み書きのパフォーマンスが落ちます。
また、例えばクラスタサイズ 4096 バイトのハードディスクでは、4096 バイトまでのファイルであれば「ここのブロックにあります」という情報だけで済みますが、クラスタサイズ 512 バイトの場合「ここと、ここと、ここと、ここと…、のブロックにあります」となり、つまり管理のために必要な領域が増えます。
さらに、管理できるブロックの数には上限があるため、クラスタサイズを小さくしすぎると、大容量のハードディスクに対応できなくなってしまいます。
これは、例えば簡単のために上限が10個と仮定しますと、4096 バイトで区切れば「4kB × 10」で計 40KB までのハードディスクを管理できますが、512 バイトですと 5KB までのハードディスクしかフォーマットできないということです。
ということで、「小さければ良い」というわけではなく、一般的には「細かいファイルが多い場合は小さく、大きいファイルが多い場合には大きくとるのが良い」とされています。

クラスタサイズの変更

で、ここまで来てやっと本題なのですが、OS のシステムが格納されている領域などは、比較的細かいファイルが多くなっています。
つまり、「ブート VHD ファイルのクラスタサイズを小さくすれば、クラスタギャップが解消され、VHD ファイルのサイズを減らせるのではないか?」と考えたわけです。
しかし、少し調べてみた限りでは、「すでにあるデータをそのままにクラスタサイズを変更する」というのは、一部有料ソフトぐらいでしか実現できないようでした。
さすがにそれだけのために購入するというのは避けたいと思うわけですが、そうなると考えられる手段としては、「もう一度 Win7 のインストールをやり直す」ということになり、これも面倒だな、と。
そこで、どうにか楽に、かつ安上がりにできないものかと思案してみました。

WinXP 丸ごとコピー

また少し話はそれますが、WinXP は全ファイルをコピーすることで、システムを丸ごとバックアップ(複製)することが可能です。
ただし、WinXP 起動中には、いくつかの重要なファイルがロックされていてコピーできないため、何らかの方法でそれを回避してコピーする必要があります(具体的には別の OS から WinXP に必要なフォルダ群をコピーすることになります)。
また、ルートに存在する「ntldr」というファイルが起動に必要な特殊なもので、これと「boot.ini」「bootfont.bin」「NTDETECT.COM」を併せた計4ファイルは、ハードディスク先頭領域に配置する必要があります。
そのため、「ntldr」はハードディスクのフォーマット直後にコピーし、その後「boot.ini」「bootfont.bin」「NTDETECT.COM」の3ファイルをコピー、それ以降はこの4ファイルの配置場所が変化する可能性のある操作をしないよう気を付けなければいけません。
ということで、例えば今より大容量のハードディスクを買ってきてそれと入れ替えたい場合、OS が WinXP であれば、特殊な専用のソフトを使わずとも、以下のような手順で「丸ごとコピー」が可能です。

  1. WinXP に新ハードディスクを繋ぎフォーマット。
  2. フォーマットした新ハードディスクに「ntldr」をコピー。
  3. 続いて「boot.ini」「bootfont.bin」「NTDETECT.COM」の3ファイルをコピー。
  4. 別のシステム(BartPE や WinPE など)で起動し上記4ファイル以外の全ファイルをコピー。
  5. 旧ハードディスクと新ハードディスクを入れ替え。

Win7 は丸ごとコピーできるのか

ということで表題につながるのですが、つまり、Win7 も同様にファイルコピーで複製できるのであれば、お金も手間もかけずにクラスタサイズを変更できるはず、というわけです。
ただ Win7 は、WinXP 以前のシステムとの互換性や、あるいは x86 用のアプリケーションを実行するために、ジャンクションと呼ばれるリンクが張り巡らされていますので、コピーしただけでは複製できないかもしれません。
しかしまあ、たとえ単なるコピーでは起動しなかったとしても、「クラスタサイズを 512 バイトにした場合、どの程度の削減が見込めるか?」の確認にはなるはずです。
ですので、実際に再インストールするかどうかは、それを見てから決めてもいいだろうと、とりあえず「全ファイルのコピー」を試すことにしました。

FastCopy

ファイルのコピー処理には「FastCopy」というツールを使いました。
この手の、ファイルのコピーや同期を行うものとしては、今回使用した「FastCopy」と、もう一つ「Fire File Copy」というツールが有名です。
自分は過去にこの両者を比較検討した結果「FastCopy」を選択し、それ以来ずっと、データのバックアップやフォルダの同期処理にはこれを使ってきました。
ただ、「FastCopy」を選んだのは、確か何らかの理由があったはずなのですが、それがなんだったのかは忘れてしまいました(少なくとも「デザインが~」みたいなものではなかったと思うのですが)。
なお、この「FastCopy」も、前回「Win7 のブート VHD ファイルのダイエット」で使用した「Ultra Defrag」と同様に、「コマンドラインモード」があり、「日本語対応(というより標準が日本語なのですが)」で、「ポータブル運用可」と、非常に「自分好み」な作りとなっています。
そしてその性能に関しては、前述のジャンクションやシンボリックリンクに対応し、ハードリンクを追跡して再現する機能があり、UNICODE 実装により非常に長いパス名であっても問題なくコピーできる、と、もうこれでコピーできないものならあきらめる他ないだろうと言える充実ぶりです。

【手順1】コピー元(セクタサイズ 4096 バイト)をEドライブに準備

ということで、複製作業に入ります。
稼働中の Win7 をそのままコピーしても(おそらく)うまくいかないと予想されますので、まず、デュアル・ブートで残してある WinXP で起動し、Win7 のブート VHD ファイルの複製を作りました(これを「Win7_4096.vhd」とします)。
そして Win7 で起動しなおし、Win7_4096.vhd をマウントします。
前回にも書きましたが、複製した VHD ファイルをマウントすると、初期状態が「オフライン」になりますので、右クリックで「オンライン」にして「Eドライブ」に割り当てます。

VHDオンライン

この時点での Win7_4096.vhd のサイズは 14.3GB でした。

【手順2】コピー先(セクタサイズ 512 バイト)をFドライブに準備

次に、「コマンド プロンプト」を管理者として実行し、以下コマンドを入力してDドライブの「VHD」フォルダに「セクタサイズ 512 バイト」で「NTFS 圧縮が有効」な、容量 40GB 可変の VHD ファイル「Win7_0512.vhd」を生成します(生成後は exit コマンド二回で「コマンド プロンプト」を終了できます)。

diskpart
create vdisk file="D:\VHD\Win7_0512.vhd" maximum=40960 type=expandable
select vdisk file="D:\VHD\Win7_0512.vhd"
attach vdisk
create partition primary
format fs=ntfs unit=512 quick compress

そしてその Win7_0512.vhd をマウントし、Fドライブに割り当てます。
この時点での Win7_0512.vhd のサイズは 76.6MB でした。

【手順3】FastCopy による全ファイルのコピー

両者がそろったところで、FastCopy を使い「Eドライブ → Fドライブ」の丸ごとコピーを実行します。
具体的には、管理者として実行した「コマンド プロンプト」で、以下のオプションを指定して起動しました。

fastcopy.exe /cmd=sync /force_close /open_window /bufsize=1024 /disk_mode=same /speed=full /acl /stream /reparse /linkdest "E:\" /to="F:\"

指定したスイッチを説明しますと、まず、Win7 のシステムフォルダにはジャンクションやハードリンクが張り巡らされいるため、「/reparse」や「/linkdest」を指定し、また、「/acl」や「/stream」ででアクセス権限と副次ストリームもコピーすることで、できる限り元の構造を保持するように努めています。
それから、論理的には別のハードディスクですが、実体は両方とも同一ドライブ上にありますので、念のため「/disk_mode=same」として「同一 HDD モード」を強制しておきました。
また、「/bufsize=1024」の部分で、バッファサイズとして 1GB を指定していますが、これは搭載メモリによってはエラーが出るかもしれません。

クラスタギャップは解消

コピー後に、ドライブのプロパティから両者の使用状況を比較しました。
まず、コピー元であるEドライブの使用容量は 15,403,565,056 バイト(14.3GB)でした。

コピー元

これがコピー後のFドライブでは 13,549,190,144 バイト(12.6GB)となり、2GB 近く減っています。

コピー先

ということで、クラスタギャップは確実に解消されています。
ただし、この時点での Win7_0512.vhd のサイズは 16.6GB と、元の 14.3GB より 2GB 以上増えています。
原因として、「管理に必要な領域が増えたため」という可能性が考えられますが、もう一つ、今回「ただコピーしただけ」ではあるものの、NTFS 圧縮をしているためか、以下の通り激しく断片化していますので、この辺りも関わっているかもしれません。

コピー先断片化

いずれにしても、前回「Win7 のブート VHD ファイルのダイエット」で確認した通り、「最適化 → 事前圧縮処理 → compact コマンド」処理を経ればまた変わってくるだろうと考え、とりあえず起動できるかの確認を行いました。

起動も可能

ということで、また WinXP で起動しなおし、現在使用中のブート VHD ファイルと、Win7_0512.vhd を入れ替えて再起動してみたところ、あっさりと起動できました。
いくつかアプリケーションを起動してみたりしましたが、特に問題もなく動作しましたので、一見したところでは、とりあえず「ファイルの丸ごとコピー」でも「複製は可能」といった感じです。
もっとも、こういったことは「長く使って初めてわかる不具合」というものもありますから、一度や二度「起動できました」という程度で断定はできないと思いますが。

VHD ファイルのサイズ削減には逆効果

で、VHD ファイルのサイズ削減のため、まず Ultra Defrag で最適化を開始したのですが、12 時間 PC をつけっぱなしにしておいても、0.1% しか進んでいませんでした。
この調子では、終了までに数日どころか数週間はかかる(それでも済まないかもしれない)、ということで、単なる「デフラグ」に変更してみたものの、進み具合に大差はありません。
ということで、仕方なく方針を転換し、とりあえず新規 VHD ファイル作成からやり直し、「事前圧縮処理 → compact コマンド」のみをやってみました。
が、Win7_0512.vhd のサイズは 16.6GB と、まったく変化はありませんでした。

クラスタサイズ 512 バイト時での処理時間増大問題

クラスタサイズを 512 バイトにすると、とにかく何をするにもすごく時間がかかるようになりました。
デフラグもそうですし、事前圧縮処理(precompact.exe)も 4096 バイトよりかなり処理時間が長くなっています。
また、起動に要する時間も伸びていて、4096 バイトでは「最初のハードディスクへのアクセスから起動音が鳴るまで」の時間が1分05秒だったのですが、512 バイトでは1分45秒と、倍とまでは言いませんが、それに近い程度は必要です。
理屈で考えれば、例えば 4096 バイトまでのファイルであれば「このブロックにあります」で済んだものが、「ここと、ここと、ここと…のブロックにあります」と、最大8倍の処理が必要になりますので、処理時間が増大するのは必然とは言えるのですが、それにしてもデフラグにかかる時間は、とても8倍どころでは収まりません。
あるいは、VHD ファイル内部では 512 バイトでも、その VHD ファイル自体は 4096 バイトのクラスタ上に存在するわけで、その矛盾が何かしらの影響を与えていたりするのかもしれません。

さすがにあきらめることに

もしかしたら、「最適化 → 事前圧縮処理 → compact コマンド」と手順を踏むことで、クラスタギャップ分の効果は出るのかもしれませんが、アプリケーションのインストールや Windows Update のたびに、数週間もかけて VHD ファイルのメンテナンスをする、というのはちょっと現実的ではありません。
ということで、さすがにクラスタサイズ変更による VHD ファイルのダイエットはあきらめることにしました。
その結果、表題の件についても、「とりあえず起動は可能」というところまでで、「継続使用で問題が出ないか」の検証については、残念ながら「やらずじまい」ということになりました。

関連記事

【同じタグを付けた記事の一覧】
バックアップ ポータブル Windows

スポンサーサイト

コメントの投稿

非公開コメント

最新記事
最新コメント
Amazonおまかせリンク
カテゴリ
タグクラウド
Amazonお買い得ウィジェット
カレンダー
03 | 2017/04 | 05
- - - - - - 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 - - - - - -
月別アーカイブ
プロフィール

電脳太助

Author:電脳太助
Website:電脳スピーチ web

RSSリンクの表示
メールフォーム

名前:
メール:
件名:
本文:

サイト内検索
Ads by Google
FC2アクセスランキング
Ads by Google
FC2拍手ランキング
ユーザータグ

音楽管理(65)
ポータブル(57)
ソフト紹介(44)
プログラミング(42)
音声技術(41)
自作ソフト(34)
サイト運営(32)
FC2(31)
ブログ(30)
iTunes(26)
Windows(25)
LISMO(24)
音声合成(23)
音声認識(22)
x-アプリ(22)
電子ブック(22)
eラーニング(20)
バックアップ(19)
語学学習(19)
foobar2000(18)
ソースコード(17)
画像管理(15)
WindowsLiveWriter(15)
C++(14)
アフィリエイト(10)
DnspTools(10)
ウォークマン(9)
fi-6130(9)
FLAC(9)
Gracenote(8)
英語音読学習計画(8)
Prolog(8)
JavaScript(8)
ベクター(8)
雑記(8)
CodeBlocks(7)
SyntaxHighlighter(7)
TraConv(7)
wxWidgets(7)
spcbght(7)
DCP-J552N(6)
W63CA(6)
MP3Gain(6)
WinRT(6)
iGoinLM(6)
VirtualBox(6)
WindowsLiveMesh(6)
英語発音矯正実験(6)
ExactAudioCopy(6)
楽器演奏(5)
Mery(5)
LAME(5)
音楽技術(5)
GalateaProject(4)
LLVM(4)
nLite(4)
MIDI(4)
ホームページ(4)
WindowsLiveSkyDrive(4)
GalateaTalk(4)
PC-98(3)
カウンター(3)
AACGain(3)
iTCDini(3)
OverCutChecker(3)
拍手(3)
PK-513L(3)
UniversalExtractor(3)
アクセスランキング(3)
ImageCompositeEditor(2)
アクセス解析(2)
OCR(2)
qtaacenc(2)
資格試験(1)
AquesTalk(1)
AquesCmdDl(1)

FC2アクセスランキング
最新トラックバック
アクセスランキング
[ジャンルランキング]
コンピュータ
112位
アクセスランキングを見る>>

[サブジャンルランキング]
ソフトウェア
11位
アクセスランキングを見る>>
FC2カウンター
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。