zfsをテープにバックアップ？

皆さんはzfsで作ったファイルシステムをどのようにバックアップしていますか？ 最近ではテープというデバイス （単体のテープドライブ、テープ・オートローダ、テープ・ライブラリ）は古くさく、 過去のものという考えを持った人が多くなってきていると思いますが、 私はまだ価値があると思っています。 簡単にオフラインの場所に保管できるとか（例えば遠隔地や耐火金庫に入れるとか）、 保管できるデータの量とそれに要する場所の大きさとかいろいろ利点があります。 また、速度も各世代でディスクに対して結構高速です ( sustained data rate of 120MB./sec for LTO4 / T10000 )。 ソフトウエアは会社において私は（部門のサーバとして） Sun StorageTek Enterprise Backup Software を使っています。 特にバージョン7.3以降はzfsをサポートしており、なかなか快調です。 現在私の書いたちょっとしたスクリプトを使って、 直接使用中のファイルシステムではなくスナップショットからとるように運用しています （これは２年くらい前にやったことで、最新のSun StorageTek Enterprise Backup Software ではもっとスマートにできるようになっているかもしれません）。

このSun StorageTek Enterprise Backup Softwareは実際良くできていて、 使いやすく、かつパワフルです。 しかし、無料ではありませんし、小さな組織における小さなサーバでは大げさすぎるかもしれません。 あるいは、定期的にはとらないけど、なにか特別な理由で１回だけとりたい場合などにも適さないかもしれません。 そういった場合今まではufsdump/ufsrestoreがとても役に立ってくれました。 当然完璧ではありませんが(もっと早くなってほしいですね、特にディレクトリ関連は）、 十分であり、差分のバックアップも効率よくやってくれます。 そうはいってもufsdumpというくらいで、これはufsだけに有効なコマンドで、 zfsには少なくともこれに直接変わるコマンドはありません。 zfsのスナップショット機能はとても強力で、間違えて消してしまったファイルや、古いバージョンの ファイルを復活させるのには大変便利です。 しかし、すべて同じディスクのプール内だけで行われることです。 zfsのsend/recieveはかなり期待が持てそうですが、 ufsdump/ufsrestoreのように複数のテープに書き出す機能がありません (もともと媒体に書き出すために設計しているわけでないので）。 GNUのtar(gtar)には複数のテープを扱う機能があるようですが、どうも、 手動で切り替える場合だけで、オートローダに対応していないようです。

さて、ではどうすればよいのでしょうか？ gtarを改造しますか？ でもそれではtarの書式しかサポートできません。 うーん、Unixのプログラマーらしい発想をしてみたいと思います。 複数のテープをサポートする機能はもっと一般的な機能として実現するべきではないかと思います。 そうですね、古くからもともとテープを扱うために作られたコマンドがありますね、ddです。 ということで、ddをおもしろ半分の気持ちで試しに改造してみました。 ddはOpenSolarisのプロジェクトの一環としてオープンソース化されていますので、 ソースコード は簡単に手に入ります。 まあ、私がCのプログラムを書くなんていうのはかなりしばらくぶりなので、腕はさび付いていますが、 なんとか動く物ができました。

参考までに私のやった変更を ここに 載せておきました。 もし、興味がおありでしたら次のステップで試してみてください。

• まず、OpenSolarisをコンパイルできる環境を これ を参考に作ります。
• 私の作ったパッチをダウンロードします。
• 次のようにしてdd.cに対してパッチを当てます。

  $ cd ${SRC} $ cd usr/src/cmd/dd $ patch dd.c < dd_mtv.patch

  そしてコンパイルします。

パッチされたddの使い方ですが、以下のように二つのオプションを追加しています。

ial[=n]

Input being AutoLoader. 入力が(if)がオートローダであることを指定します。 オプションでオートローダがロードする時間nが指定できますが、 省略すると180秒になります。

oal[=n]

Output being AutoLoader. 出力が(of)がオートローダであることを指定します。 オプションでオートローダがロードする時間nが指定できますが、 省略すると180秒になります。

自動的にテープドライブかどうか判断したりする方法もあるかもしれませんが、 結果が正確でないかもしれませんし、 その結果とんでもないことが起こるかもしれないと思い、 私はオプションで指定するように作りました。 使い方の例です：

# zfs send rpool/export/home@backup | dd oal of=/dev/rmt/0cbn obs=2048b

一応この改造版はSPARCの上で StorEdge L280 with DLT7000 drive (ただし、このオートローダはすでに外して使わなくなったので、最近テストしていません), と StorageTek L20 with LTO2 drive で試しています。

最後に将来の希望をリストすると (:-p):

• ミキサー。 複数のデータストリームをミックスして一つのテープに書き出すようにしたい。 zfsを使っていてもディスクにおけるファイ��システムの読み込みがテープに対して 充分早くないので、複数のファイルシステムをいっぺんに処理したい。
• マルチスレッド。 zfs sendは結構高速ですが、 私が以前に書いた ように、 複数のtar/gtarを同時に走らせた方が早いです。 もっとも、単体のzfs pool上の複数のzfsに対して同時にzfs sendを実行しても良いのかもしれません
• 記録をとる。 何時何を何処に書いたのか。

まあ、これぜんぶちゃんとできるとかなりエンタープライズ級の機能を持ったものに近ずくと思います。 また、Amandaを調べていないのですが、すでに実現されているのかな？

更新

英語の方のエントリでバイナリがほしいというコメントがあったので ここ に載せました。 SPARCとx86、とそれぞれのDEBUG版が入っています。 しかし、手元にテープ・オートローダが繋がっているx86が無いので、 x86版は試験をしていません。 また、当然ですが、これらのバイナリに関して何ら保証などをできるわけではありませんし、 お使いになる方は use it at your own risk でお願いします。 でも、もし使って頂けた場合はその結果をお知らせして頂くとうれしいです。

Tape backup for zfs ?

How do you backup zfs based file system/stroage? Those days tapes (tape drive, tape autoloader, tape libary) are considered legacy by many people, but I still value the tape as backup device. Its can be store offline easily (can place on to fire safe stroage for example), amount of data on given space (such as library) would be greater. And it actually pretty fast ( sustained data rate of 120MB./sec for LTO4 / T10000 ). At work/office, I do use Sun StorageTek Enterprise Backup Software. Version 7.3 and following do support zfs file system, and works fine. I even wrote small script to backup from snapshot instead of live file system (I done this years ago, newer version may support this in more elegant way).

While Sun StorageTek Enterprise Backup Software is nice, easy to use, poweful solution, it does cost and combersome for small operation or adhoc backups. For those cases, ufsdump/ufsrestore did excellent job for me. Its not perfect (I wish it does go even faster, too slow on directory), but adequate and came with incremental backup. But it only for the ufs, and zfs does not have direct replacement (yet?). zfs snapshot does wonderful job for finding lost (unitentinally deleted, or look for older version) files, but within the existing disk storage/pool only. zfs send/receive looks promising., but unlike ufsdump/restore, it does not able to write to multiple tape volume. Well, zfs send/receive did not designed for that purpose. GNU tar (gtar) has ability to handle multiple tapes, but it appear only for manual tape exchange operation (not for autoloader).

What should I do? Modify gtar to support autoloader ? But that only support gtar format. Think like Unix programmer (^ ^;). Handling multiple tape volume should reside on more generic Unix command. I decided to modify dd command for experimentation (or fun :-). Its being open sourced as part of OpenSolaris. Its being while I did actually wrote piece of source code, so, its kind a rusty. But I was able to produce workable version.

For reference I have placed patach/diff of my modification posted. If you are interested to try, prepare the OpenSolaris source code and compiling environment, Down load the patch, and apply patch to the dd.c:

$ cd ${SRC} $ cd usr/src/cmd/dd $ patch dd.c < dd_mtv.patch

then, complie it. For usage, I have added two options.

ial[=n]

Input being AutoLoader. Optional n indicate how many seconds will wait for the autoload to complete, default being 180 second.

oal[=n]

Output being AutoLoader. Optional n indicate how many seconds will wait for the autoload to complete, default being 180 second.

Automagically detect the tape drive and such may not acculate, and may result in undesired behavior, therefore I decided to have above option to contol the behavior. Example on how may use:

# zfs send rpool/export/home@backup | dd oal of=/dev/rmt/0cbn obs=2048b

I have tested this vesion with old tape autoloader StorEdge L280 with DLT7000 drive (but I have take it offline while ago, and have not tested lately), and StorageTek L20 with LTO2 drive.

And finally wish list (:-p):

• Mixer. I wish mutiple stream of data can be combined and wrote to tape autoloader/library. Today, even with zfs, usually, disk/file system are slower than newer tape drive. Its kind of waste (of time) to process each file system sequencially.
• Multithread. zfs send are pretty fast. But my other article (Sorry writtten in Japanese only, but you can see the table) indicated that running multile tar/gtar would be faster than zfs send for single file system. Having multple file system on single zfs pool. and running multple zfs send may make sense.
• Keep the record. When and what file are being written when and which tape.

Well, if we have above, we have pretty good correction of feature from enterprise backup solution (:-). I have not look at Amanda yet.

Update

I have request to provide binary from comment onto this entry. I already reply to the comment to provide binary, but just in case I'll also write here. I did uploaded binary at here. its include both SPARC and x86 binary, as well as DEBUG binary. However, I don't have autoloader connected to x86 server, therefore x86 version are not being tested. As usuall, please use it at your own risk. Also, I would appreciate if you can report back how it works.