2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

自宅サーバのディスク構成と復旧

Last updated at Posted at 2015-12-30

朝6:00から「ギャリギャリギャリ」という爆音で目覚める。自宅サーバの物理ディスクが壊れたようだ。ヤレヤレ。

自宅サーバ パーティショニング/ディスク構成プラン

いったん自宅サーバの構成をここでメモる。

考え

mdadmでミラーリングしたり、クラスタリングしたりをするといいんだろうが、ぶっちゃけ、全然便利じゃない!特にこのmdadmしてしまうと、物理ドライブと論理ドライブが見えたりして全然シンプルじゃない。

などなどの経験からいって以下の構成としている。何かあったときのダウンタイムは1日ぐらいを想定している。

実装

  1. OSディスクはmdadm、ドライバレイヤを用いたRaidは作らない
    • めんどいから、復旧がだるいから、クラスタ中の1台が死んだごときでいろいろうるさいから
  2. /home/ だけは、大容量の別ディスクにマウント(/xfs/disk01/とする) して用いる
  3. /xfs/disk01//xfs/disk02 に毎晩 rsync する
    • 時差があったほうがファイルを取り戻せる確立が高い(1日前のものを取得できる)
    • このログは git commit & push するようにしておく
  4. 各ユーザーには /home/<user> を与えておき、OSX TimeMachineとかの先にしておく

今回壊れたのはここの /xfs/disk02/ が壊れた。

手順

  1. 壊れたディスクを特定、切り離し
  2. Diskの増設
  3. フォーマット
  4. Diskのマウントとテスト
  5. バックアップの実行

壊れたディスクの特定

物理サーバなのでディスプレイをつなげたらすぐわかった。/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/dis02rsync しておく。普通に超時間かかるので バックアップ 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
2
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?