Question #143229 on sbackup changed:
https://answers.launchpad.net/sbackup/+question/143229
Jeremiah Corbin posted a new comment:
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.
--
You received this question notification because you are a member of
Simple Backup Maintainers, which is an answer contact for sbackup.
_______________________________________________
Mailing list: https://launchpad.net/~nssbackup-team
Post to : nssbackup-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~nssbackup-team
More help : https://help.launchpad.net/ListHelp
