GlusterFSで管理しているファイル群は、撮影した写真や動画とチューナーによる録画ファイルが中心。録画ファイルはTSファイルとMP4ファイルを録画時に同時生成するので、見終わった録画のTSファイルは手動で削除するみたいな運用を何となく続けていた。しかし、遂にミスオペをしてしまい、誤ってTSファイルだけでなくMP4ファイルまで消してしまった。Linuxのターミナル上で作業していたので、ゴミ箱に移るということもなく、完全に消えてしまったのだ。
こういう手作業をしていたというのは、消えてもそれほど痛くないからだったんだけど、いざ消えてみると意外と悔しく何とかしたくなる。ぐぐって復旧させる方法を調べてみる。ext4であれば幾つかありそうなんだけど、前回のバージョンアップ時にxfsにしてしまったために、その方法も使えない。おのれxfsめ。。。諦めかけたそのとき、8TBにリプレイスする前の3TBディスクがまだ手元に残っていることを思い出す。対象の録画ファイルはかなり古い時点のものだし、もしかしたら、3TBディスクに残っているかも！
3TBディスクに残るデータは当時の容量からすると17分の３くらいしかないので分は悪かったのだが、運良くデータが残っていて復旧できた。これはこれで完結したので終了でもよかったんだけど、このヒヤリハットを生かさない訳にはいかない。GlusterFS側でbackupを取れないかを本気で考え始める。以前からsnapshot機能があることは知っていたので、本気で導入を検討する。この時点でデータ容量は44TBをDistoributed Mirrorしていて実効容量22TB使用量15TB。気軽に導入できるボリュームではないので、さきほどの3TBディスクを使って検証。
現時点ではデバイス上にパーティションすら切らず、xfsのファイルシステムを作成しているが、snapshotを使うにはシンプロビジョニング・ボリュームに切り替える必要がある。このため1度はデバイスをフォーマットする必要があるため、移行が面倒。実際のボリュームは４ディスクx2ノードで構成されているので、検証用ディスク上のvgsに4つのシンプロビジョニングプールを作成し、それぞれにLVを用意する。vgsやプールをデバイス跨ぎにすると、brickがどのデバイスに紐づくかが制御できなくなってしまうので、別々にしておく。
vgcreate vg0 /dev/sdb
lvcreate --thin -L 10G vg0/thin1
lvcreate --thin -L 10G vg0/thin2
lvcreate --thin -L 10G vg0/thin3
lvcreate --thin -L 10G vg0/thin4
lvcreate --thin -V 10G -n data1 vg0/thin1
lvcreate --thin -V 10G -n data2 vg0/thin2
lvcreate --thin -V 10G -n data3 vg0/thin3
lvcreate --thin -V 10G -n data4 vg0/thin4
mkfs.xfs -fL data1 /dev/vg0/data1
mkfs.xfs -fL data2 /dev/vg0/data2
mkfs.xfs -fL data3 /dev/vg0/data3
mkfs.xfs -fL data4 /dev/vg0/data4
mount /dev/vg0/data1 /data1
mount /dev/vg0/data2 /data2
mount /dev/vg0/data3 /data3
mount /dev/vg0/data4 /data4
これで検証用の4つのLVができたので、実際にGlusterFSのボリュームを作成して、snapshotを取得、マウント、データへのアクセス、リストア等を試してみる。検証環境の事情で、同一ホスト内にreplicaを用意するので、createする際はforceオプションが必要となる。尚、ホスト名はgfs1とする。
gluster v create test replica 2 gfs1:/data1/test gfs1:/data2/test gfs1:/data3/test gfs1:/data4/test force
gluster v start test
mkdir /test
mount -t glusterfs gfs1:/test /test
echo 1 > /test/testfile
gluster sn create s1 test no-timestamp
echo 2 >> /test/testfile
gluster sn activate s1
mkdir /s1
mount -t glusterfs gfs:/snaps/s1/test /s1
cat /s1/testfile
umount /s1
umount /test
gluster v stop test
gluster sn restore s1
gluster v start test
mount -t glusterfs gfs1:/test /test
cat /s1/testfile
問題なし。すばらしい。尚、snapshotを取得した直後では、snapshotのLVがマウントされた状態だけど、例えば再起動などした場合は、手動でsnapshotのLVをマウントする必要がある。マウントしていないとactivateすることもできない。helpは見てみたんだけど、多分コマンドではできないよね？ snapshot infoでVolume Nameを確認してから以下のようにマウントする。OriginボリュームとUUIDが重複するので、nouuidオプションを指定するのがポイント。
gluster sn info s1
:
Snapshot : s1
Snap UUID : a58846b9-dace-4677-bc5f-80064ee7cdc4
Created : 2017-09-05 07:05:03
Snap Volumes:
Snap Volume Name : f151169cc5a44b269f24c3e1876cae09
Origin Volume name : test
Snaps taken for test : 1
Snaps available for test : 255
Status : Stopped
mount -o nouuid -t xfs /dev/mapper/vg-f151169cc5a44b269f24c3e1876cae09_0 /run/gluster/snaps/f151169cc5a44b269f24c3e1876cae09/brick1
mount -o nouuid -t xfs /dev/mapper/vg-f151169cc5a44b269f24c3e1876cae09_1 /run/gluster/snaps/f151169cc5a44b269f24c3e1876cae09/brick2
mount -o nouuid -t xfs /dev/mapper/vg-f151169cc5a44b269f24c3e1876cae09_2 /run/gluster/snaps/f151169cc5a44b269f24c3e1876cae09/brick3
mount -o nouuid -t xfs /dev/mapper/vg-f151169cc5a44b269f24c3e1876cae09_3 /run/gluster/snaps/f151169cc5a44b269f24c3e1876cae09/brick4
これで任意のLVをマウントしてやれば再びactivateできるので、snapshotのマウントやリストアが可能になる。また、deactivateした状態であれば、snapshotをdeleteできる。snapshotをdeleteすれば、それに紐づくLVも削除してくれる。snapshotは単純なbackupではないので、ソースと同じだけの容量を消費することもない。数10TB単位のボリュームでどのような運用になるかは未知数の部分もあるが、実用には耐えそうな機能なので本格的に導入を進めていくこととする。