このページでは、私が行っている Windowsドライブの「普通でない」が「完全」なフルバックアップ方法を紹介します。
Micorsoft Windows98を使っています。これにはバックアップユーティリティのようなものが付いています。昔一回だけ使ってみたことがあるのですが、圧縮もしないままQICテープに何やら書き込んでいき、あっという間に溢れてしまい、うまく使いこなせませんでした。別の「オフィシャルな」方法というと、商用ソフトということになるようです。
基本的に、私は、Linuxでやるように完全なバックアップを取りたいだけなのです。全体をTAR ballにして、restore時にフォーマットしたHDD上に一気に書いて終り、という具合にしたい。cygwin上でtar.exeしてみたり、Linuxからtarしてみたりして幾度も失敗しました。失敗の原因は、半角カナファイル名だったり、固定位置ファイル(IO.SYS等)だったり、open中でロック(?)されていて読めないファイルだったりと色々だったのですが、ディスククラッシュの後になって初めて、バックアップファイルが使えないことが解るのはショックが大きいことです。
また、Windowsの場合、ディスクの増設や、領域不足で、ドライブ間やパーティション間の移動をしたいときも、仲々困ります。C:ドライブの選択規則や位置固定ファイルのためです。例えばC:を移すときは、sys.exeしてから、残りのファイルをコピーすれば良いと思いますが、移動先ドライブが C: にされてしまうときはどうしたら良いのでしょうか？
このため、今はドライブ(パーティション)ごと、ファイルシステムを通さないでバックアップ、あるいはコピーしています。これは手軽で安全です。この方法を紹介します。
結論から言いますと、適当な方法で立ち上げたLinux上から以下のようにします。
dd if=/dev/hda1 | gzip -c | split -b 2000m - hda1img-041217_gz.
要するに、raw deviceとして読み出したディスクイメージを圧縮してバックアップファイルとして保存します。この場合、hda1img-041217_gz.aa、hda1img-041217_gz.ab… のようなファイル群ができます。上のコマンド中の"/dev/hda1"はバックアップするドライブ(パーティション)に、"hda1img-041217_gz."の名前は都合の良いものにして下さい。また、"2000m" ( = 2000 MB)にしてあるのは、FAT32やsambaでファイルのサイズ制限が2GB ( = 2048 MB)なため、それを超えないようにしているだけですので、保存環境に合わせて変えて下さい。
リストアするときには、以下のようにします。
cat hda1img-041217_gz.* | gzip -dc | dd of=/dev/hda1
この方法の良い点は、
簡単に解説しておきますと、dd は、raw device として、byte 毎に読み書きするコマンドです。バックアップするドライブ(パーティションを if= で指定します)。Linuxでは、最初のドライブが hda、2番目は hdb になります。hdaの最初のパーティションが hda1、2番目が hda2。Windowsのfdiskで確保しているなら、hda1 が C: ドライブ、hda2 が拡張ドライブ、hda3 が D:ドライブでしょうか。
gzip は圧縮コマンド、splitはファイルを分割するコマンド。これによって、hda1img-041217_gz.xxのファイルがいくつかできます。このフィイルを置くのに、空きに余裕があるファイルシステムを用意しておいて下さい。(私は20GBほどのパーティションを作業用に余分に確保しています)。これらのファイルをバックアップメディアに書き込みます。
リストアのほうは、cat は、ファイルを読み出すコマンドで Windowsの typeに当たります。splitでバラしたファイルを順に読み、gzip で伸長してから、dd で書き出します。of=で書き込みパーティションを指定します。
これは、HDDを変更/増設するときにも使えます。
何しろWindowsでないので、どこのドライブにも、どこのパーティションにも自由に書き込むことが可能です。注意点としては、基本的に書き込み先のパーティションは同じサイズにしないとなりません。増設時には、新しい巨大なディスクに巨大なパーティションを作って移すぜ、という場合が多いかと思いますが、この場合は一旦コピーした後で、 FIPS や ntfsresize でサイズを変えることで実現できます。
サイズを合わせるとは？
通常LBAモードで、例えば以下のようになっていると思います。
255 heads, 63 sectors/track, 3737 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
この場合、新しいパーティションとして cylinder数(LinuxのfdiskではBlock数)を合わせてやれば、そのままコピーできます。ラフに言って、サイズが等しい必要があります。通常LBAモードでは皆、論理的に1 cylinderが 512B * 255 head * 63 sect になっているはずです。なので、コピー元とコピー先のシリンダ数を合わせれば、同じサイズになります。(LBAを使わないときにはhead数 x sector数 x cylinder数が等しくなるようにコピー先のBlock数を合わせてやる必要があるでしょう。しかし、OSからのアクセスはHSCは関係ないのでLBAにしておくのが吉です)。
実際には、コピー先のパーティションを大きく取ってしまっても問題ないようです。使われない領域が出るだけで、実害はないとのこと。
ここまでの内容は単純なのですが、このままでは効率が良くならない場合があるかもしれません。実際、上記をやってみると解りますが、バックアップファイルはしばしば、予期したよりも大きくなります。これは、圧縮があまり効かないためです。実体のファイルをZIPしたりしたのよりも遥かに大きくては効率が悪いですし、殆どパーティションサイズの大きさになったりして扱いが大変になります。
通常のファイルシステムでは、ディスクにはデータがそのまま書き込まれているわけですから、データ部分は同じくらいに圧縮できてしかるべきです。ということは、データがない領域が圧縮できていないと思われます。空きブロックには以前のデータの残骸が残っており、これが乱数に近いので圧縮が効かないということが考えられます。
最近は圧縮ファイル(画像JPGや音声MP3)を持っていたりしますよね。各々のメディアに合わせた圧縮アルゴリズムの他、一般的なハフマン圧縮などもしていますので、汎用の圧縮ツールでは小さくなりません。一旦書き込んだファイルを消して空きブロックになってもデータ領域は残っており、次にデータが書き込まれるまで上書きされません。
ということで、空きブロックをできる限り0で埋めてやりましょう。あまり危ないことはしたくありませんので、今度はファイルシステム経由でやります。つまり、0で埋めたファイルをファイルシステム一杯に書き込んでやります。例えば、
zeros.exe 100m c:\dummy.img
こうしてから、もう一回「方法の実際」のようにやってみると、遥かに小さくなるはずです。
御問い合わせはこちらまで