Hatena::ブログ(Diary)

kazuhoのメモ置き場

2010-01-19

2010年代にはLVMスナップショットベースのバックアップとか流行らない (もしくはログ構造化ファイルシステムへの期待)

感想文です。タイトルはテンプレから。

たとえばうちの環境(普段 20-80 IOPS くらいの負荷がかかっている HDD) で、blockdiff (参照: Kazuho@Cybozu Labs: blockdiff を使ったお手軽ホットバックアップ環境の構築 (Linux, MySQL, etc.)) を実行すると、バックアップ速度は 10MB/sec. くらいになる。これはフルバックアップでも増分バックアップでも同じで、ボトルネックHDD のシーケンシャルリード速度。他の I/O があるから、それぐらいの速度になってしまう *1

換言とすると、100GB のボリュームをバックアップするのに約3時間かかる。必要な時間が3時間ならデイリーバックアップで運用できるけど、これが 1TB のボリュームとかになると、ウィークリーバックアップしか選択肢がなくなる。

ただ、

という2点もあるので、TB クラスのストレージだと LVM スナップショットベースのバックアップは苦しいのかなぁ、と思っている。

この問題に対応できるのはログ構造化ファイルシステムで、例えば zfsスナップショットベースの増分バックアップ機能を備えている。ファイルシステムが、前回のバックアップ以降 HDD のどこに変更がかかったか覚えているので、インクリメンタルバックアップの際に発生する読み込み量はストレージのサイズではなく、変更の発生した量に依存することになる。従って、ストレージのサイズに関係なく、高頻度のバックアップが可能*2

Linux のログ構造化ファイルシステムにどういうものがあるかは良く知らないけど、Nilfs には差分バックアップ機能はなさそうだった*3

もうひとつの可能性は、LVM ベースで同様の、差分だけを HDD からバックアップするような仕組みを作れるか、という点。前回のバックアップ時のスナップショットを取っておいて、最新のスナップショットと差分を取るようにすれば、きっとできるはず。ただ、

という2点がある。なので、できれば、高パフォーマンスで安定した、増分バックアップの取れるログ構造化ファイルシステムLinux にもほしいなぁ、なんて思ってる。

*1:逆に、X25-M のような並列アクセスに強い SSD を使っている場合は他の処理が動いていても関係ない感じ

*2:このへん XtraBackup は zfs ぽいやり方してるのかなーとか思ってるけど未確認

*3ML で議論された形跡はある。参考: no title

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/kazuhooku/20100119/1263876978