I Had the same problem. the problem was drive. I use lto6. When error, tape change status FULL (1 or 2 TB) and take the next tape append.
Log: 22-Feb 03:13 srv-backup-sd JobId 19675: Error: block.c:260 Write error at 215:322 on device "Drive-LTO6-2" (/dev/nst1). ERR=Input/output error. 22-Feb 03:13 srv-backup-sd JobId 19675: Error: Error writing final EOF to tape. This Volume may not be readable. tape_dev.c:946 ioctl MTWEOF error on "Drive-LTO6-2" (/dev/nst1). ERR=Input/output error. 22-Feb 03:13 srv-backup-sd JobId 19675: End of medium on Volume "ES0502L6" Bytes=200,613,482,496 Blocks=3,109,707 at 22-Feb-2019 03:13. 22-Feb 03:13 srv-backup-sd JobId 19675: 3307 Issuing autochanger "unload slot 14, drive 0" command for vol ES0502L6. 22-Feb 03:14 srv-backup-sd JobId 19675: 3304 Issuing autochanger "load slot 15, drive 0" command for vol ES0515L6. 22-Feb 03:15 srv-backup-sd JobId 19675: 3305 Autochanger "load slot 15, drive 0", status is OK for vol ES0515L6. 22-Feb 03:15 srv-backup-sd JobId 19675: Wrote label to prelabeled Volume "ES0515L6" on tape device "Drive-LTO6-2" (/dev/nst1) 22-Feb 03:15 srv-backup-sd JobId 19675: New volume "ES0515L6" mounted on device "Drive-LTO6-2" (/dev/nst1) at 22-Feb-2019 03:15. Disable drive /dev/nst1. only work /dev/nst0. my tape FULL now 5 or 6 TB. all good. PD: the tape FULL with 2TB, i change status full to append. he wrote without problems the problem principal: Error: Error writing final EOF to tape. This Volume may not be readable. tape_dev.c:946 ioctl MTWEOF error on "Drive-LTO6-2" (/dev/nst1). ERR=Input/output error. On Wed, Mar 13, 2019 at 6:42 PM Phil Stracchino <ph...@caerllewys.net> wrote: > On 3/13/19 5:26 PM, William Muriithi wrote: > > Hello, > > > > I have 4 dozen of tapes that have the same product number, are labelled > 6.25 TB capacity and hence should all be holding about 6 TB. However, I > have noticed no consistency in their capacity at all. Sometime, they fill > up with as little as 2 TB and oddly can sometime handle 9TB, which is above > the tape capacity. > > > > Why is there such inconsistency? Is it a configuration issue or is this > something that is expected with bacula backups? > > > There are two principal factors: > > 1. Varying levels of compression achieved on the data > > The marketed 6.25TB capacity assumes roughly a 2:1 compression ratio > achieved. If you get no significant compression in a data set, or it is > already maximally compressed, you'll only get about 3TB on the tape. If > it compresses really well and you average 4:1 compression across the > dataset, you may see as much as 12TB. > > 2. Tape errors > > If Bacula encounters unrecoverable block errors writing a tape, it will > not attempt to write any further data to that tape, but will put an EOT > mark before the failed block and mark the tape full, even if not at the > physical end of tape. > > > -- > Phil Stracchino > Babylon Communications > ph...@caerllewys.net > p...@co.ordinate.org > Landline: +1.603.293.8485 > Mobile: +1.603.998.6958 > > > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > -- ############################# # Sistema Operativo: Debian # # Caracas, Venezuela # #############################
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
