Ubuntu18.04LTSをHDD→サイズが小さいSSDに移行する

10年以上前のものとはいえ、自分でお金貯めて買ったものを捨てるのがなんだかもったいなくてUbuntu18.04LTSをインストールして遊んでいたんだけど、今となってはお察しレベルのスペックでもWebやらメールやら何だかんだで使えちゃえるものだったりなので、この際SSDに移行して可能な限り早くしてみることにした。

材料

• ターゲットPC）富士通 FMV-BIBLO MG70W(2007年発売、Ubuntu18.04LTSインストール済)
• SSD）GREENHOUSE社製120GB SSD(GH-SSDR2SA120：税込2,750円)
• ソフト）EaseUS社 Todo Backup Home(作業時点12.8)
• 作業用PC(Windows10)
• USB接続可能な2.5inchHDDケース
• DVD-R 1枚

(当初想定の)手順

1. 作業用PCにTodo Backup Homeをインストール
2. Todo Backupで「Linuxブータブルディスク」をDVD-Rに作成(MG70WはUSBブートできないため)
3. 買ってきたSSDをケースに入れ、ターゲットPCにUSBで接続
4. ターゲットPCに2で作った「Todo Backupのブートディスク」を入れてDVDから起動
5. 起動したTodo Backupの「Clone」で、内蔵ディスク(disk0)からUSB接続ディスク(disk1)へのクローンを実行
6. クローンできたら電源を落とし、HDDをSSDに換装してPC起動

躓いた

Todo Backupを用いてLinuxクローンを作る場合はセクタバイセクタを指定しないとうまくいかないとの記事が２、３見られたのでそのようにしたのだが、クローンを実行しようとすると何やらエラーダイアログが出て進めない。

この時ちゃんとメッセージを読めばよかったのだが、そういえばSSDは何もしてないやってことで一旦PCから外してフォーマットしたりあれやこれやしたのだが、やっぱり同じダイアログが出たので、改めてメッセージを読んでみた(英語)

(意訳)移行先のディスク容量が足りねーよ

調べたところ、セクタバイセクタ指定の場合は**「移行先(SSD)は移行元(HDD)よりもディスクサイズが同等以上」**でないと動作しないとのこと(当たり前と言えば当たり前)。今回、移行元のHDDは160GBで、移行先のSSDは120GB・・・そりゃあ「足りねーよ」って言われるわけですわorz

だったらHDDのパーティションのサイズを縮めればいいんじゃね？となるけれど、ここでわざわざddコマンドだ、fdiskだとかコマンドを打ちたくなかったので、どうにか出来る限りGUIだけで行ける方法を模索して、以下の手順に改めた。

(改めた)手順

1. 作業用PCに**「EaseUS Todo Backup Home」**をインストール
2. Todo Backupで**「Linuxブータブルディスク」**をDVD-Rに作成
3. 買ってきたSSDをケースに入れ、ターゲットPCにUSBで接続
4. ターゲットPCに**「Ubuntuをインストールした時のDVD」**を入れてDVDから起動
5. 起動したら**「GParted」**アプリを起動し、HDDのパーティションをSSDのパーティションよりちょっとだけ少なく指定して適用(SSD-1GBぐらいにした)
6. パーティションサイズを変更できたらターゲットPCを一旦OFFし、改めて2で作った**「Todo Backupのブートディスク」**を入れてDVDから起動
7. 起動したTodo Backupの**「Clone」**を選び、内蔵ディスク(disk0)からUSB接続ディスク(disk1)へのクローンを「Optimize SSD」「Sector by Sector」の両方にチェックを入れて実行
8. クローンできたら電源を落とし、HDDをSSDに換装してPC起動

今度はHDD＜SSDだったのでエラーにならず、クローンが動き始めた(^^)
１時間２４分でクローン終了。

結果

クローンが終わったSSDに付け替えていざ起動・・・う、動いたっ！
おかげで起動めっちゃ早くなった！

ということで半日かからずにSSDに移行できましたとさ(^^)

(追記)SSDを長持ちさせるための設定

無事、動くようになったのでアレやコレや試していた最中、ふとリソースモニターを見たら

ぎゃー、スワップ使ってるぅー！(＞＿＜)

古いとはいえメモリ4GBあるし、大したことさせてないからと高を括っていたら、あっさりスワップ領域ができていやがりました。いや、もう4GBで安心していい時代じゃないんでしょうね。

スワップ無効化

スワップといえば/etc/fstabで設定して〜ってイメージだったんですが、ubuntu18.04だとコマンドでの実行も必要のよう。とはいえ/etc/fstabの編集も必要なので、fstabファイルを開き、typeが「swap」となっている行をコメントアウト。

$ sudo nano /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=fe275a41-3782-4249-9109-3eb171e4eb2e /               ext4    errors=remount-ro 0       1
# /swapfile                                 none            swap    sw              0       0　　←この行ですな

次にコマンドでswapの無効化。パラメータにはスワップファイル名を指定する。

$ sudo swapoff /swapfile

最後に200MBだか2GBだかのでっかいファイルが出来ていたので削除。

$ sudo rm -r /swapfile

GNOMEのシステムモニターで「スワップ：利用できません」と表示されているし、swapon -sでも何も表示されなかったので、スワップは無効化できたと判断。

TRIMの設定

スワップだけでなく、そもそもSSDの場合にはやっておくべき設定があったよう。

当然ながら、SSDはHDDとはデータの書き込みや消去も違う仕組みになっているので、「TRIM」って機能がSSDの性能や長持ちさせるためにも大事らしい(よくわかってない)。

PCは古いけどOSもSSDも新しいものなので対応している・・・と思うが、まずは確認する。

$ sudo hdparm -I /dev/sda1 | grep -i trim
	   *	Data Set Management TRIM supported (limit 8 blocks)

「Supported」なのでTRIM機能に対応したSSDであることがわかった。

TRIMを実行させるには「fstrim」というコマンドがあるようだが、これを手で打つのではなくOS側に定期的に実行してもらうようにする。

まずは、状態確認。

$ sudo systemctl status fstrim
● fstrim.service - Discard unused blocks
   Loaded: loaded (/lib/systemd/system/fstrim.service; static; vendor preset: en
   Active: inactive (dead)

うーん、よくわかんないけど、fstrimってのが表示されるということは何かしら設定されているってことだろう。ってことでfstrimを定期的実行させるtimerを有効にする。

$ sudo systemctl enable fstrim.timer

timerがちゃんと登録されているか確認する。

$ sudo systemctl list-timers --all

NEXT                         LEFT          LAST                         PASSED        UNIT                         ACTIVATES
Wed 2020-11-04 10:04:42 JST  47min left    Wed 2020-11-04 09:03:19 JST  14min ago     anacron.timer                anacron.service
Wed 2020-11-04 15:02:57 JST  5h 45min left Wed 2020-11-04 08:54:50 JST  22min ago     motd-news.timer              motd-news.service
Thu 2020-11-05 03:41:03 JST  18h left      Wed 2020-11-04 08:53:14 JST  24min ago     apt-daily.timer              apt-daily.service
Thu 2020-11-05 06:26:46 JST  21h left      Wed 2020-11-04 08:53:14 JST  24min ago     apt-daily-upgrade.timer      apt-daily-upgrade.s
Thu 2020-11-05 09:08:14 JST  23h left      Wed 2020-11-04 09:08:14 JST  9min ago      systemd-tmpfiles-clean.timer systemd-tmpfiles-cl
Mon 2020-11-09 00:00:00 JST  4 days left   Mon 2020-11-02 14:03:51 JST  1 day 19h ago fstrim.timer                 fstrim.service
n/a                          n/a           n/a                          n/a           snapd.snap-repair.timer      snapd.snap-repair.s
n/a                          n/a           Wed 2020-11-04 08:54:10 JST  23min ago     ureadahead-stop.timer        ureadahead-stop.ser

LASTが11/2ってことは動いたってことだし、fstrim.timerが出てきたからきっと動くだろう。

もひとつ、マウント時に連続TRIMする設定がある模様。この設定をしておけばTRIMをたくさんしてくれるかわりに性能が落ちてしまうようなので確認した(discardというみたい)

$ sudo findmnt -O discard
$

実行したもののマウントポイントが表示されなかったのでdiscard設定されていないと判断。手動でfstrimも実行できるが、ここではやめといた。

あと、Webでは「mount時のnoatime指定」の話が見られたが、たまに動かなくなる場合があるというのでやめた。なお、マウントの状態を見たら↓になっていたので、relatime指定されている＆discard指定されていないと判断。

$ cat /proc/mounts
:
/dev/sda1 / ext4 rw,relatime,errors=remount-ro 0 0
:

その他

mlocateというのが大きなファイル書き込みをするらしいが、無効化するのも気が引けたので、mlocateを/etc/cron.dailyから/etc/weekly配下に移動しといた。

cronの実行ログは「sudo journalctl -f -u cron」で確認できるそうなので見てみたが、mlocateが動いた形跡はなさそうなので良いと思うことにした。

一通り終わって思い返しながら書いているので抜けがあるかもだが、SSDに移行したら必ずやっておいたほうがいいことなので追記した。

参考

EaseUS Todo Backup Free
https://jp.easeus.com/backup-software/free.html