朝6:00から「ギャリギャリギャリ」という爆音で目覚める。自宅サーバの物理ディスクが壊れたようだ。ヤレヤレ。
自宅サーバ パーティショニング/ディスク構成プラン
いったん自宅サーバの構成をここでメモる。
考え
mdadmでミラーリングしたり、クラスタリングしたりをするといいんだろうが、ぶっちゃけ、全然便利じゃない！特にこのmdadmしてしまうと、物理ドライブと論理ドライブが見えたりして全然シンプルじゃない。
などなどの経験からいって以下の構成としている。何かあったときのダウンタイムは1日ぐらいを想定している。
実装
- OSディスクはmdadm、ドライバレイヤを用いたRaidは作らない
- めんどいから、復旧がだるいから、クラスタ中の1台が死んだごときでいろいろうるさいから
-
/home/だけは、大容量の別ディスクにマウント(/xfs/disk01/とする) して用いる -
/xfs/disk01/は/xfs/disk02に毎晩 rsync する- 時差があったほうがファイルを取り戻せる確立が高い(1日前のものを取得できる)
- このログは
git commit&pushするようにしておく
- 各ユーザーには
/home/<user>を与えておき、OSX TimeMachineとかの先にしておく
今回壊れたのはここの /xfs/disk02/ が壊れた。
手順
- 壊れたディスクを特定、切り離し
- Diskの増設
- フォーマット
- Diskのマウントとテスト
- バックアップの実行
壊れたディスクの特定
物理サーバなのでディスプレイをつなげたらすぐわかった。/dev/sdc らしい。
それがどの UUID に割り付けられていたのかを確認しておく
[pharaohkj@CentOSServer ~]$ ls -l /dev/disk/by-uuid/
これでわかる。
Diskの増設
vi /etc/fstab で起動時のマウントを削除する。fstabの内容がディスクエラーなどで正しくマウントできず、readonlyになっている場合には rw で再マウントする。
(Repair filesystem) 3 # mount -o remount ,rw /
前の手順で調べた UUID のディスクを起動時にマウントしないようにする。(対象のUUIDの行をコメントアウトしておく)
電源を切り、壊れたディスクを入れ替える。
フォーマット
再起動後、この時点において、新ディスクにはUUIDは与えられていない。なのでまずフォーマットする。
gptを用いるので fdisk は用いず、 parted を用いる。
というかそもそも、どういうドライブ構成だっけ？？？というのを確認したい場合 lsblk という便利なコマンドがあるらしい。
[root@CentOSServer ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 0 232.9G 0 disk
├─sdb1 8:17 0 500M 0 part /boot
└─sdb2 8:18 0 232.4G 0 part
├─vg_centosserver-lv_root (dm-0) 253:0 0 50G 0 lvm /
├─vg_centosserver-lv_swap (dm-1) 253:1 0 3.7G 0 lvm [SWAP]
└─vg_centosserver-lv_home (dm-2) 253:2 0 178.7G 0 lvm /home
sdc 8:32 0 2.7T 0 disk
sdd 8:48 0 2.7T 0 disk
└─sdd1 8:49 0 2.7T 0 part /xfs/disk01
sda 8:0 0 298.1G 0 disk
└─sda1 8:1 0 298.1G 0 part
これで /dev/sdc はパーティションが存在しないことがわかる。以下は入力していった内容。
新しいディスクラベル？と聞かれたら gpt と答えないといけないようだ。 ボリュームラベルとは違うのか？
parted /dev/sdc
(parted) mklabel
新しいディスクラベル? gpt
(parted) mkpart
パーティションの名前? []?
ファイルシステムの種類? [ext2]? xfs
開始?
開始? 1
終了?
終了? -0
(parted) quit
-0 (マイナスゼロ)は最大を表すらしい。
これでsdc1ができる
sdc 8:32 0 2.7T 0 disk
└─sdc1 8:33 0 2.7T 0 part
ので、フォーマットする
[root@CentOSServer ~]# mkfs.xfs /dev/sdc1
UUIDが与えられているので確認する。
[root@CentOSServer ~]# ls -l /dev/disk/by-uuid/
lrwxrwxrwx 1 root root 10 12月 31 00:13 2015 12f17eff-37f1-40ee-8a21-49041110fc81 -> ../../sdc1
Diskのマウントとテスト
新しいDiskのUUIDが得られたので、 /etc/fstab のコメントアウトした行をこのUUIDに入れ替える。この設定でちゃんとマウントできるかを mount -a で確認しておく。
バックアップの実行
/xfs/disk01 の内容を /xfs/dis02 に rsync しておく。普通に超時間かかるので バックアップ cron がまわってきてしまわないか注意すること。
課題
クラウドにいきたい
今回のディスクは3Tで12k円ぐらいだった。1年持てば、1,000円/月だが、はやくクラウドディスクが物理ディスクより安い日がきてほしい。それができれば、全部そこにおけるんだが・・・。
2020-04-25現在、まだ動いているので3年半は動いているので286円/月。電気代は考えない。
どうしてクラウドにいきたいのか
落雷で全てをロストした経験から言って、もはや 同じ家の中にある電源につながっているということは信頼できない。
サージ対策電源 → ACアダプタの外付けUSBディスクに逃がすぐらいができるだろう最低限だけど、まだお遊びレベルだろうな。
落雷どころか停電、火事、地震どれを考えても Amazon Glacier には叶わぬ。しかしまだ1T 1000円/月 ぐらいなので、がんばってほしい。
その後
2021-03-09
MacbookProが1Tになったということもあって、3Tのディスク4発ごときじゃ足りなくなってきたので、8Tのディスクを追加する作業を行った。( Seagate BarraCuda 3.5" 8TB ST8000DM004 ￥13,434-
disk1とdisk3のバックアップをdisk2にとるという運用だったので、disk2をとりあえずでかくした。
/xfs/disk01/
/xfs/disk02/ → disk03へ
/xfs/disk03/ → 引退して8Tへ交換 && disk02とする
コピーを実施
[pharaohkj@CentOSServer disk04]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/vg_centosserver-lv_root
51475068 3440688 45412940 8% /
tmpfs 961128 0 961128 0% /dev/shm
/dev/sda1 487652 148095 313957 33% /boot
/dev/mapper/vg_centosserver-lv_home
184315972 174848036 98544 100% /home
/dev/sdc1 2928834296 2384709068 544125228 82% /xfs/disk01
/dev/sdb1 2928834296 2928751008 83288 100% /xfs/disk02
/dev/sdd1 7811938304 2928098380 4883839924 38% /xfs/disk04
3T ( df で表示されるサイズ 2928098380 = 2.8T ) の分のコピー時間はだいたい 28.73時間 でした。100G/1H が目安なのかな？
[root@CentOSServer disk02]# date && cp -pR backup_disk03 /xfs/disk04 && date && cp -pR backup_disk01 /xfs/disk04 && date
2021年 3月 11日 木曜日 07:25:24 JST
2021年 3月 11日 木曜日 10:11:21 JST
2021年 3月 12日 金曜日 12:00:56 JST
2021-03-20
disk01が不良セクタがあるぽくていろいろエラーが表示されていたので、 WD30EZRZ から Seagate BarraCuda 3.5" 8TB ST8000DM004 ￥13,427- に交換。WD30EZRZは4年ちょっとぐらいの稼働。寿命か。
現状
| disk | date | disk |
|---|---|---|
/xfs/disk01 |
2021-03-20 | ST8000DM004 |
/xfs/disk02 |
2021-03-09 | ST8000DM004 |
/xfs/disk03 |
2016-10-?? | WD30EZRZ |