清水理史の「イニシャルB」
実運用中のSynology DS1512+をext4からbtrfsに変更 結果的にはやはりバックアップから復元がおすすめ
2017年3月21日 06:00
SynologyのNAS向けに提供が開始された「DSM 6.1」。btrfsの対応機種が拡大されたことで、筆者宅で運用中のDS1512+でもbtrfsを利用することが可能となった。ext4で運用中の実機をbtrfsへと変更してみた。
結局のところ……
結論から先に言えば、やはり確実なのは、現在のデータをバックアップしてから、ext4のボリュームをいったん削除し、btrfsでボリュームを作り直した後に、バックアップから復元するという方法だ。
2ベイモデル、もしくは4ベイモデル以上でもデータ量が少なく（1本のHDDにデータをすべて一時的に保管できる）、かつSHR（もしくはRAID5）で運用する場合にも後述する方法での移行が不可能ではないが、一部のデータをバックアップから復元せざるを得なかったり、二度手間をかけてSHR-2に移行しなければならないケースがある。
ファイルシステムの変更なんて、やらずに済むなら、そのまま運用するに限るが、本コラムで前回の記事で紹介した通り、DSM 6.1ではbtrfs前提の新機能が多く搭載されている。
そこで、意を決して、子供の写真やビデオ、仕事のテキスト、確定申告などのデータなどが詰まっているDS1512+の移行にチャレンジしたわけだが、結果的にはバックアップから戻すはめになった。
その経緯を今回は紹介する。
海外フォーラムの情報をもとに
ext4からbtrfsへの移行は、昨年からSynologyのユーザーフォーラムでさかんに議論が交わされていた。
当初は、バックアップから復元一択の流れだったが、途中から、冒険者が結構現れ、その成功例も見えるようになってきた。
その方法は、環境によって若干異なるが、おおむねこんな感じだ。
1.稼働中のシステムからHDDを1台外す（当然ボリュームは劣化する）
2.外したベイに新HDDを新たに装着
3.新HDDをSHRのbtrfsボリュームとして構成
4.既存のボリュームから共有フォルダーを移動（コンパネで簡単に可能）
5.既存のボリュームを削除
6.既存HDDを使って新HDDのSHRボリュームを拡張
もちろん、冗長性を失うことになるので、バックアップを取得することが前提での話ではあるが、確かにこの方法なら、一時的にしろ、データが完全に消えることなくボリュームを移行することができそうだ。
ボリューム削除が鬼門
というわけで、実践あるのみというわけだが、さすがに本番環境でやるのは怖いので、取りあえずテスト用に確保してあった2ベイモデルのDS716+で試してみた。
1.HDDを1台取り外す
警告のビープ音をコントロールパネルから停止して、ストレージマネージャを確認すると「劣化」と表示されるが、データもアプリもそのまま利用できる。ここまでは想定内だ。
2.取り外したHDDをそのまま再装着する
一瞬でも抜いたHDDは元のHDDとして認識されないので、新規ボリュームとして利用する。前述した手順と同じように、このHDDでSHRの新しいディスクグループを作成し、btrfsでフォーマットする。
これで、旧ext4のボリュームと新しいbtrfsのボリュームの2つが共存することになる。
3.共有フォルダーを移動する
コントロールパネルの「共有フォルダ」で各フォルダーの設定を表示し、「場所」を新しく作成したボリューム２（btrfs）へと移動する。
なお、移動するフォルダーがアプリによって利用されている場合は、アプリを停止しておく必要がある。例えば、VideoやPhotoなどは、Video StationやPhoto Stationで使われているので、事前にアプリの停止が必須となる。
この点にさえ注意すれば、特に問題なく共有フォルダーを移動できるが、データ容量によってはこれに数時間かかることがあるので、複数の共有フォルダーが存在する場合は、移動完了を待って次という繰り返しになる。この時点で、この方法は非効率的と言える。
4.ボリュームを削除する
さて、この操作がこの方法の鬼門で、これ以降は引き返せないし、場合によっては重要なデータが失われることになるので注意が必要だ。
btrfsのボリュームの拡張先として、既存のext4ボリュームを使いたいので、このボリュームを削除する。
共有フォルダーは移行済みなので安心していたが、ここにはアプリのデータが存在することを意識していなかった。例えば、Note StationやOfficeアプリで作成したデータが存在する。
これらのデータをエクスポートせずにボリュームを削除すると、当然のことながらアプリ内のデータは失われる。もちろんエクスポートすればいいのだが、そのためにはアプリごとに操作が必要になるので効率的とは言えない。
Video StationやPhoto Stationなど、共有フォルダーそのものがデータである場合は問題ないが、それ以外のアプリは、この操作で壊滅的なダメージを受けるのでくれぐれも注意が必要だ。
5.ボリュームを拡張
というわけで、すでにこの方法は破綻しているが、途中でやめるわけにはいかないので、当初の予定通り、ボリュームを拡張する。
btrfsのボリュームが含まれるディスクグループに、削除した旧ext4のHDDを追加すると、自動的にbtrfsボリュームの2台目として利用可能になる。2ベイモデルの場合、容量が拡張されるわけではないので、単純にSHRの冗長性が確保されるイメージだ。
バックアップから戻す
このように、あまりおすすめはしないが、バックアップから戻すという方法以外でもext4からbtrfsに移行することは不可能ではない。不可能ではないが、かえって時間も手間もかかるうえ、データが失われる可能性もあるので、やはりバックアップから戻す方が確実と言えそうだ。
なお、4ベイモデル以上の機器の場合、共有フォルダー移行時にデータ容量が1台のHDDに収まらない可能性があるため、そもそも上記方法が使えない場合がある。また、SHR-2（2台の冗長）で運用したい場合、ボリューム作成時に3台以上のHDDを装着する必要がある。このため、btrfsボリューム作成時にSHRしか選べなくなり、その後の運用がSHRに限定されてしまう点にも注意が必要だ。
そこで、本番環境のDS1512+は、バックアップから復元することした。
ちなみに、筆者宅の状況は、DS1512+に4TBのHDDを5台装着したRAID6構成で、トータル容量は10TB、使用済みのデータ容量は6TB（主に写真とビデオとクライアントのバックアップ）という状況であった。
1.バックアップ
まずは、Hyper Backupを利用してデータ、システム、アプリのすべてのデータをバックアップした。
バックアップ前のディスク使用量は6TBほどであったが、バックアップ後のデータを見ると1.6TBほど。念のため6TBのボリュームを用意したが、Hyper-Backupではデータ圧縮が可能なこともあり、3TBのHDD1本でも十分だった。
ただし、バックアップには長い時間が必要で、筆者宅の場合は完了までに約12時間かかった。
2.ボリューム削除
バックアップが完了したら、既存のボリュームを削除する。バックアップがあるとは言え、この瞬間は怖いが、ためらわずに実行する。
なお、この際、先の方法と同様にアプリが使用している共有フォルダーが存在するため、ボリュームを削除する前にアプリを削除する必要がある（停止ではNG）。NoteStationやOfficeなど、警告が表示されたアプリを事前に削除しておく必要がある。
3.btrfsボリューム作成
新しいディスクグループを作成し、すべてのHDDを選択。SHR-2による2台までの保護を設定し、btrfsでフォーマットする。
4.バックアップから復元
最後に、Hyper Backupで取得しておいた全データを復元した。
リストアにかかった時間は14時間ほど。バックアップよりも長い時間がかかったが、放置しておけばいいので手間はかからなかった。リストア完了後、一通り設定を確認してみたが、ユーザーやアクセス権なども元通り戻っていた。
ただ、アプリに関しては完全には復元できない。バックアップされたアプリ（Note StationやOfficeなど）に関しては、アプリもデータも問題なく復元されたが、以前に使っていたアプリのうち失われたものもいくつかある。
具体的には、環境によるため、バックアップの際に対象となるアプリを事前に確認しておいてほしいが、例えばDockerなどバックアップできないものもある（バックアップが1.6TBで済んだのはDockerのイメージがバックアップされなかったことも影響している）。
このため、一部のアプリは再インストールが必要になる。筆者宅の環境の場合、Audio Station、Photo Station、Video Station、Cloud Station Server、Cloud Share Sync、Media Server、Docker、iTunes Server、Chatなどが失われたため、再インストールすることになった。
テスト目的でインストールしていたアプリが多いため、失われても実害はなかったが、実際に利用しているアプリがある場合は、データのエクスポートなど、バックアップとは別にデータを保存しておく必要があるだろう。
また、Cloud Station Driveを利用してクライアントとNASのデータを同期している場合は、クライアント側のアプリで接続の再設定が必要になる。元通りの環境に戻そうとすると、こまごまと手間がかかる。
変換はおすすめしない
というわけで、冒頭で触れた通り、バックアップを使うのが一番手間がかからないと言えそうだが、それでもアプリに注意しないと失われるデータが発生する可能性が高い。btrfsを使える環境は魅力だが、リスクは相当にあることは覚悟が必要だ。
筆者はネタにもなるので、思い切って実行したが、それでも途中で何度もやめればよかったと後悔した。くれぐれも勢いで実行したりしないように注意したい。
清水 理史
製品レビューなど幅広く執筆しているが、実際に大手企業でネットワーク管理者をしていたこともあり、Windowsのネットワーク全般が得意ジャンル。最新刊「できる Windows 10 活用編」ほか多数の著書がある。