Windows Vista以降はBCD等に変更が入ったため、以下の方法は原則適用できません。
Acronis True Imageがおすすめです。Windows Vista以降でも使えるようです。SSD alignmentもできます。 Western Digital製のHDDを持っている場合は、 OEMバージョンを使用できます。 このツールでSSD alignmentを適用するには、まずMBRのみを移行してからWindowsパーティションを移動するとよいようです。
起動することを考えなければ、ディスクのどのセクタからパーティションが始まっていようが、「データパーティション」としては使えます。 従って、ddでコピーするだけで移動はできます。ただし、パーティションブートセクタにはディスク上のMFTの絶対値等が「直値」で 書き込まれているので、パーティションの開始位置が変わった場合、起動はできなくなります。また、CHKDSKを通すと一部の情報が矛盾 してるので直されることがあります。ddを使うときは、bs=1M等にして、SSDのブロックサイズ以上にしないと、 パフォーマンスが出ませんし、場合によっては寿命に影響することもあります。
AFTと同様、4k以上のalignmentに合わせないと、パフォーマンスが出ません。
基本的には、パーティションを確保する場合、開始位置は、Windows2003まで63セクタ目、Windows Vista以降で2048セクタ目 (1Mbyte)になっていますが、どのOSでも(WindowsNTであっても)プライマリパーティションは基本的にどこからはじまっても大丈夫です。 特に63の縛りがあるわけではありません。CHSからLBAになった時点で、基本、その制約はなくなりました。 なお、BIOS等での容量制限は別問題です。一番楽なのは、Linux等のfdiskで確保する方法でしょうか。 旧バージョンの場合、BIOSで取得できるCHSと異なる値が使われてしまうことがあるので、一度、GRUB等を起動し、geometryでBIOSでの CHSを確認し、fdiskにオプションとしてHやSを指定したほうがよいでしょう。特に、Thinkpadでは、head 240 sector 63、 Dellではhead 255 sector 63に決め打ちされてしまうようなので、パーティション確保前に必ずチェックしたほうが良いでしょう。 MBRのパーティションテーブルのCHS情報がBIOSと矛盾していると、起動できないことがあるようです。また、パーティションのboot flagは 忘れずに立てておきましょう。Typeは0x7 NTFS/HPFSです。
ddだと、データディスクとしての移動は完了ですが、上記の通り、PBRが異常になるので、修復する必要があります。 この段階で、フロッピー等で起動してTestDiskを使ってWindowsで直すこともできます。フロッピーをWindows XPで通常フォーマットし、 NTLDR、boot.ini、ntdetect.com等をコピーする方法で作れる起動ディスクでパーティションから起動します。 修復は、本当は、Windows インストールディスクの修復からfixbootを使うと直るはずですが、ディスクが変わったりすると 修復できなくなることがあります。 その場合、TestDiskを使って直せます。 他にも方法があるようですが、面倒なので割愛します。 [Intel][Advanced](Partition選択)[Rebuild BS]で、MFTの位置を解析し、[Write]すると修復できます。 心配なら、同じTestDiskでMBRも書き込んでもいいでしょう。 NT signatureも初期化してもいいと思いますが、どうしても起動しないときに試してもいいかもしれません。
WindowsでNTFSフォーマットすると、NTLDRをロードするPBRを書き込んでくれるので、最悪上記で確保したNTFS パーティションを Windowsでフォーマットし、ファイルコピーするだけで起動するようにはなるはずです。あるいは、別のハードディスクに 同じパーティションテーブルで作成し、フォーマットし、PBRだけ(512)バイト分、パーティションの一番最初と 一番最後(バックアップ)だけddすることでもリカバリできます。
あと、SSD特有の設定をしておきましょう。(Windows XP)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters]
"EnablePrefetcher"=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfrg\BootOptimizeFunction]
"Enable"="N"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsCurrentVersion\OptimalLayout]
"EnableAutoLayout"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"NtfsDisableLastAccessUpdate"=dword:00000001
SSDではデフラグは原則必要ありませんが、どうしてもという場合は、ディスクイメージごとハードディスクに一旦コピーし、オフラインで デフラグしてから書き戻すと、SSDの寿命は比較的保たれますし、早く済みます。
NTFS Boot Sector BIOS parameterの詳細な説明。
手動でPBRを書き換える方法が載っている。以下抜粋。
$ sudo dd if=/dev/sda1 of=10GB.img bs=512 count=20971520
※ntfscloneなんかを使うと、もっと安全かつ効率的にダンプできるらしい
※最初のパーティションがWindows XP
$ sudo sfdisk -d /dev/sda > diskconfig.txt
$ cat diskconfig.txt
# /dev/sda のパーティションテーブル
unit: sectors
/dev/sda1 : start= 63, size= 60002712, Id= 7, bootable
/dev/sda2 : start= 60002775, size= 1558305, Id=82
/dev/sda3 : start= 61561080, size= 57319920, Id=83
/dev/sda4 : start=118881000, size= 6313545, Id= c
$ cp diskconfig.txt newconfig.txt
$ nano newconfig.txt
$ cat newconfig.txt
# /dev/sda のパーティションテーブル
unit: sectors
/dev/sda1 : start= 64, size= 60002711, Id= 7, bootable
/dev/sda2 : start= 60002775, size= 1558305, Id=82
/dev/sda3 : start= 61561080, size= 57319920, Id=83
/dev/sda4 : start=118881000, size= 6313545, Id= c
$ sudo sfdisk --no-reread -N1 /dev/sda < newconfig.txt
$ sudo reboot
$ sudo dd if=10GB.img of=/dev/sda1 bs=10M
ディスクの先頭に特別なセクタ=MBRがあるように、Windowsパーティションの先頭にはPartition Boot Sectorがあります。 勝手にパーティションを移した場合、ここのいくつかの値を書き換えて整合をとる必要があります。バイナリエディタでごりごりと修正。 参考
$ dd if=10GB.img of=pbs.dat bs=512 count=1
$ bvi pbs.dat
パーティションを短くしたので、ここもあわせて修正。
offset: 0x28, size: 8byte
現状値 : 97 91 93 03 00 00 00 00 (= 60002711)
変更値 : 96 91 93 03 00 00 00 00 (= 60002710)
先頭からのオフセット。
offset: 0x1C, size: 4byte
現状値 : 3F 00 00 00 (= 63)
変更値 : 40 00 00 00 (= 64)
今回もっともはまったのがこのパラメータ。だって、MicrosoftのNTFSの解説には「Not used or checked by NTFS.」 って書いてあったのに！放っておいたらブートしなかった。。。
$ dd if=pbs.dat of=/dev/sda1 bs=512 count=1
Last week Kent Beck made a claim that you don't really need bug tracking
databases when you're doing Extreme Programming, because the combination of
pair programming (with persistent code review) and test driven development
(guaranteeing 100% code coverage of the automated tests) means you hardly ever
have bugs.
Lo and behold, I discovered that very few of the bugs in there would have been
discovered with pair programming or test driven development. Many of our
"bugs" are really what XP calls stories -- basically, just feature requests.
A lot of the other bugs were only discovered after much use in the field. The
Polish keyboard thing. There's no way pair programming was going to find that.
And logical mistakes that never occurred to us in the way that different
features work together. The larger and more complex a program, the more
interactions between the features that you don't think about. A particular
unlikely sequence of characters ({${?, if you must know) that confuses the
lexer. Some ftp servers produce an error when you delete a file that doesn't
exist (our ftp server does not complain so this never occurred to us.)
I carefully studied every bug. Out of 106 bugs we fixed for the service pack
release of CityDesk, exactly 5 of them could have been prevented through pair
programming or test driven design. We actually had more bugs that we knew
about and thought weren't important (only to be corrected by our customers!)
than bugs that could have been caught by XP methods.
But Kent is right, for other types of development. For most corporate
development applications, none of these things would be considered a bug.
Program crashes on invalid input? Run it again, and this time watch your
{${?'s! And we only have One Kind of FTP server and nobody in the whole
company uses Polish Windows.
-- Joel Spolsky
-- "Five Worlds" ( http://www.joelonsoftware.com/articles/FiveWorlds.html )