We mostly rely on AMANDA, but for a simple, compressed, encrypted, tape-spanning alternative backup (intended for disaster recovery) we use:
tar cf - <files> | lzf (quick compression utility) | ssl (to encrypt) | mbuffer (which writes to tape and looks after tape changes) Recovery is exactly the opposite, i.e: mbuffer | ssl | lzf | tar xf - The mbuffer utility (http://www.maier-komor.de/mbuffer.html) has the ability to call a script to change tapes, so if you have the mtx utility you're in business. Mbuffer's other great advantage is that it buffers reads and/or writes, so you can make sure that your tape is writing in decent sized chunks (i.e. isn't shoe-shining) even if your system can't keep up with your shiny new LTO-4 drive :-) We did have a problem with mbuffer not automatically detecting EOT on our drives, but since we're compressing as part of the pipeline rather than in the drive itself we just told mbuffer to swap tapes at ~98% of the physical tape size. Since mbuffer doesn't care where your data stream comes from, I would think that you could easily do something like: zfs send | mbuffer (writes to tape and looks after tape changes) and mbuffer (reads from tape and looks after tape changes) | zfs receive This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
