Hi,

I am having a problem with the behavior of --listed-incremental when the tape of a single-volume archive fills up.

To avoid the backups on subsequent days becoming increasingly larger, I want the incremental index to list the files that were actually backed up before the tape was full. However currently, I seem to get an index saying that nothing was backed up on the full tape (its uncompressed LTO-4 = 800Gio per tape).

I am wondering if there is a way to make this happen without too much difficulty.

One thing I have not tried (because it would create a multi-volume archive with the second and later volumes missing) would be to specify "--tape-length 800000000000 --info-script=/bin/false" however given the observed handling of tape full I would suspect that doing this would have the same result as a simple broken output pipe[2].

Hope someone can help with this.

J Bohm, Software Developer.


Additional notes:

1. This is on a Debian 5.0.x(Lenny) system with its corresponding version of GNU tar 1.20, but compiling another tar version to make things work would not be much of a problem.

2. I am piping the output from tar through a double-buffering program similar to the classic "buffer" program in order to reduce shoe-shining in the tape drive caused by the disk being slower than the tape. The buffer is configured to buffer up about 792 MibiOctets of archive at a time, write lots of 100Kio tape blocks continuously in a burst at tape speed, then sleep until the buffer is full again. Thus tape full technically manifests itself as a broken output pipe rather than a real disk full error code in case that makes any difference to tar.

3. This is a production system, I really need the backup to work 5 days a week, 52 weeks/year. As each backup run may take up to 18 hours (2 hours lead time + 1 minute/burst), I cannot do much full scale experimenting.

4. This is all done by a cron job, no human interaction possible.


Reply via email to