QNAPボリューム再構築2015年10月14日 11:17

バックアップは無事に終了。バックアップ中にディスクの状態が悪化しなかったのは幸い。念のため、異常とされたディスク4をスキャンし、修復を試みる。

念のためリビルドの確認

ディスクのスキャンは無事終了。SMART情報を見ると、代替セクタの処理がつつがなく終了し、異常から警告に状態は改善。RAID5のリビルドもできる。

RAID5のリビルド後、ディスク4を予備に交換して済ませるのでもよいが、せっかくの機会なので、ボリューム構成を見直す。使用中のNASは省電力の代わり、CPU能力は低め。性能はCPUネックになりがち。RAID5はCPU使用量が多いので、RAID1に変えてみる。併せてボリュームを2つにする。音楽ファイルとVMのイメージファイルなどを分けることで、音飛びを改善できないか。

RAID5ボリュームの削除

RAID5のリビルドを中断して、ボリュームを削除。

RAID5ボリュームの削除

単一ドライブが4つの状態に戻る。

QTS4.2に更新

おもむろにペンディング中だったQTSのバージョンアップを実行。4.2になる。省電力機種では、新機能が増えても使わないのだけど。QNAPは多機能だけど、それらを目的とするなら、CPU能力の高い機種が必要。省電力機種では、最低限の機能に絞り込むのが快適。

RAID1を2セットに交換

ディスク3とディスク4を4TBのものに交換。これで容量は、ほとんど変わらない。

RAID1の同期

フォーマットをした後、同期を開始。同期中にもアクセスはできるが、アクセスは重いし、同期時間も延びる。2TBの同期で約1日。4TBの同期は約2日の見込み。これで最後の連休を消化した上、次の日もリカバリはつづく。

S3への複製の設定は消えない

ボリュームを作り直すことで、共有フォルダの再設定は必要。ネットワークやユーザの設定など、それ以外の設定は、勝手に消えない。一番面倒な、AWSのS3へのリモートバックアップの設定は無事残ってくれた。これは助かる。

コメント

コメントをどうぞ

※メールアドレスとURLの入力は必須ではありません。 入力されたメールアドレスは記事に反映されず、ブログの管理者のみが参照できます。

※なお、送られたコメントはブログの管理者が確認するまで公開されません。

名前:
メールアドレス:
URL:
コメント:

トラックバック

このエントリのトラックバックURL: http://c5d5e5.asablo.jp/blog/2015/10/14/7840154/tb

※なお、送られたトラックバックはブログの管理者が確認するまで公開されません。