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.