Mount tape drive error

Hi Jeff,

thanks for answering this question. You're absolutely right. Currently only disks and remote shares are supported. However, sbackup uses TAR internally which is able to write to tape drives directly. Unfortunately, I've no knowledge of using tape drives with TAR nor a drive available for some tests. I guess it should be sufficient to adapt some of TAR's commandline options (generated by sbackup; sbackup is more or less a wrapper script around TAR) to get tape support into sbackup. Any help in this regard, e.g. a shell script which shows basic steps to get TAR working with a tape drive, would be highly appreciated.

> :todo: Think about a plugins system that will be used to export on TAPE, on DVD and so on.
There are a bunch of more important things to do before a DVD export plugin should/could be implemented. Moreover, I think it's not that important to be able to burn disc directly from sbackup. Proper archive splitting should do it. A 'tape export' shouldn't be necessary since TAR is able to handle tape drives though we'd need help to implement it.

Best regards.
jean-peer (maintainer/developer).

Thanks Jeff Lane, that solved my question.

Hello, there doesn't appear to be much movement on this as far as enhancing sbackup to write to tape. I am in need of such a function. I'm definitely a novice when it comes to linux, but I'd like to help if I can.

I'm not sure if this part of the Ubuntu documentation would help: https://help.ubuntu.com/10.04/serverguide/backups-shellscripts-rotation.html

Jean-Peer, tar writing to tape is indeed trivial, in stead of
tar zcvf /var/local/backup/today/files.tgz
you would do
tar zcvf /dev/rmt/0n

This needs one or two changes to sbackup's behaviour, depending in what behaviour and features you want.
One option would be to let sbackup create all the other 'housekeeping' files in the backup directory on disk, and only redirect the archive to tape; that would allow one to find backups and browse files without reading from tape (I think; if not that would be a nice feature to add at some point). A config option to set the backup device name would be needed, which should be passed to sbackup's routines that start the 'tar' command.
The other would be to set the existing backup dir config option to the device name, test whether it is directory or device when a backup is about to be started and then if it is a device forget about all the 'housekeeping' files and write only the archive directly to the device.

( If you want to get fancy, you'd like to include support for tape robots as well ;-) )

As for DVD, why would anyone want them as backup medium? imho, they are too small, too expensive, too slow and not quite as reliable as one might think (I get about 10% failure when I burn a batch of DVDs!).

Anton et al,
After weeks of experimenting, that's nearly the procedure that I've been following: Allowing sbackup to write it's files as normal and then using tar to send the whole directory to LTO2 tape. I've really only run into two issues with that:

1) If I delete the files.tar from the directory to save hard drive space, sbackup marks the backup as corrupt. It makes restores back to the directory so that sbackup will use them difficult. Allowing sbackup to housekeep correctly might help with that.
2) tar has a very small buffer (10k, I believe) and I've been forced to use mbuffer in conjunction with tar to prevent shoe-shining.

For example, as root: tar cvf - ./ | mbuffer -R 40M -s 64k > '/dev/st0'

In that example I'm handing the output from tar over to mbuffer to allow mbuffer to use it's default 2MB cache (no switch needed), a consistent 40MB output stream ('-R'), and a block size of 64k ('-s') to prevent shoe-shining, then sending that output to the drive. Using tar alone (with the default buffer and variable blocks) I could only get 8MB/s throughput to the drive, which caused even sending my 90GB backup of my /home to take 3 hours. Using mbuffer in the way I described I was able to get that time down to 90 minutes since I could write to the drive at 16MB/s with minimal shoe-shining. (note: I'm still getting shoe-shining, but I think my old HBA is the bottleneck at this point since the theoretical limit of the LTO2 is 40MB/s). Writing a backup of my RAID takes even longer without mbuffer.

Using the compression option in sbackup makes the backup to disk take a very long time, so I try t avoid it for weekly backups.
Using the "z" option with tar when sending the files to tape didn't increase the throughput, but did decrease the amount of time required for the backup since the file size was smaller, but it was a very modest decrease.

At this point, if sbackup could make it's backup files to disk, send them to tape afterwards, and then use a housekeeping "place holder" for the files.tar afterwards on the hard disk in order to not make sbackup mad it would be a great solution for me. I just don't know how reasonable it is to ask that to be added... I'm not a programmer. Even the ability to write to tape without the use of mbuffer would be a valuable step in the right direction for tape users.

DVD is a complete waste of time for me: 4GB at a time when you're a photographer using 16GB sd cards is counter-productive. I create more files than I can possibly store the RAW files for in one session alone, not to mention any exported jpegs. The jpegs alone would fit nicely on a DVD (or CD for that matter), but I'm the creator of the content and not the client. DVD simply isn't efficient enough, nor cost-effective.

Would it work if you made the files.tar file in the backup dir a symlink to the tape device? That would make the default tar cmdline that sbackup creates work straight away, and may later be recognized as a valid backup because there is actually a (device) file present.
If that doesn't work, you'd have to change the logic by which sbcakup decides on 'invalid' backups. You may want to do that anyway, so sbackup would be aware that the archive file (literally) points to tape, and instruct the user to insert the tape.

(By the way, aren't there other solutions available for tape backups, that for example also keep a catalogue for easy searching?)