>>>>> On Fri, 14 Dec 2018 17:46:08 -0500, mark bergman said:
> Content-ID: <11001.1544827568.1@localhost>
> 
> In the message dated: Wed, 12 Dec 2018 10:50:45 -0500,
> The pithy ruminations from mark.berg...@uphs.upenn.edu on 
> [Re: [Bacula-users] [External] Re: "Full" tapes with zero bytes?] were:
> => In the message dated: Wed, 12 Dec 2018 13:40:04 +0000,
> => The pithy ruminations from Martin Simmons on 
> => [[External] Re: [Bacula-users] "Full" tapes with zero bytes?] were:
> => => >>>>> On Tue, 11 Dec 2018 16:02:19 -0500, mark bergman said:
> => => > 
> => => > I'm running Bacula 9.0.8 under CentOS 6, and I'm seeing something odd 
> with some tapes. Backups were written to the tapes, but a query of the status 
> of volumes in the tape changer shows that the media is
> => => > "Full" with zero GB:
> => => > 
> => => > 
> => => > 
> => => >       Choose a query (1-50): 15
> => => >       
> +---------+------------+-------+---------+------+-------------+-----------+-----------+
> => => >       | mediaid | volumename | gb    | storage | slot | pool        | 
> mediatype | volstatus |
> => => >       
> +---------+------------+-------+---------+------+-------------+-----------+-----------+
> => => >       |     264 | 006273L6   |     0 | neoxl80 |   19 | Full        | 
> LTO6      | Full      |
> => => >       |     220 | 006200L6   |     0 | neoxl80 |   20 | Incremental | 
> LTO6      | Full      |
> => 
> => I'm going to run some diagnostics with "btape" and "bls" to try to 
> determine whether there is actually data on the tapes.
> 
> 
> Hmmm....
> 
> The command "bls -j -v"  is returning things like:
> 
> --------------------------------------------
> Adata             : 0
> Id                : Bacula 1.0 immortal
> VerNo             : 11
> VolName           : 006200L6
> PrevVolName       : 
> VolFile           : 0
> LabelType         : VOL_LABEL
> LabelSize         : 175
> PoolName          : Scratch
> MediaType         : LTO6
> PoolType          : Backup
> HostName          : cbica-infr2
> Date label written: 22-Mar-2017 18:27
> bls: read_records.c:204-0 invalid: rec=2906429 block=0 state=partial,empty
> bls: read_records.c:341-0 The record 3 in block 0 SI=62 ST=1491232501 
> FI=1612241 was marked as invalid
> bls: read_records.c:204-0 invalid: rec=178934 block=0 state=partial,empty
> bls: read_records.c:341-0 The record 11 in block 0 SI=73 ST=1491232501 
> FI=2211606 was marked as invalid
> --------------------------------------------
> 
> 
> and 
> 
> --------------------------------------------
> 
> Volume Label:
> Adata             : 0
> Id                : Bacula 1.0 immortal
> VerNo             : 11
> VolName           : 006273L6
> PrevVolName       : 
> VolFile           : 0
> LabelType         : VOL_LABEL
> LabelSize         : 172
> PoolName          : Scratch
> MediaType         : LTO6
> PoolType          : Backup
> HostName          : cbica-infr2
> Date label written: 17-Apr-2017 20:03
> bls: read_records.c:204-0 invalid: rec=3996803 block=0 state=partial,empty
> bls: read_records.c:341-0 The record 1 in block 0 SI=283 ST=1496263978 
> FI=7154160 was marked as invalid
> 
> End Job Session Record:
> JobId             : 20313
> VerNum            : 11
> PoolName          : Incremental
> PoolType          : Backup
> JobName           : projects-p
> ClientName        : ffff-infr-vbacula
> Job (unique name) : projects-p.2017-06-05_02.45.00_34
> FileSet           : projects-p
> JobType           : B
> JobLevel          : D
> JobFiles          : 7,185,291
> JobBytes          : 2,849,513,857,175
> StartBlock        : 193,084
> EndBlock          : 193,083
> StartFile         : 8
> EndFile           : 8
> JobErrors         : 0
> JobStatus         : T
> Date written      : 06-Jun-2017 22:01
> 
> Begin Job Session Record:
> JobId             : 20435
> VerNum            : 11
> PoolName          : Incremental
> PoolType          : Backup
> JobName           : pppp-full
> ClientName        : pppp-fd
> Job (unique name) : pppp-full.2017-06-07_01.45.00_39
> FileSet           : Full Set
> JobType           : B
> JobLevel          : I
> Date written      : 07-Jun-2017 02:07
> -------------------------------------------------------
> 
> With many (hundreds) of jobs listed.
> 
> Any thoughts -- corrupt tape? Corrupt database catalog?

I'm not sure what was corrupt first, but these tapes definitely look corrupt
now.  Did the output really go directly from the "Date label written:" line to
the "bls: read_records.c:204-0" line with nothing in between?

Firstly, the bls output of the volume label of 006273L6 doesn't match the
labeldate in the llist output that you posted earlier:

> *llist volume=006273L6 
> Automatically selected Catalog: MyCatalog
> Using Catalog "MyCatalog"
>           mediaid: 264
>        volumename: 006273L6
>              slot: 19
>            poolid: 2
>         mediatype: LTO6
>       mediatypeid: 0
>      firstwritten: 2017-12-22 03:45:03
>       lastwritten: 2018-11-17 01:50:55
>         labeldate: 2017-06-05 02:45:04

Are these values for firstwritten, lastwritten and labeldate what you expect?

Other unusual thing is that you have "endblock: 0" in the catalog for these
tapes.  I don't know if that is wrong as such, but I have no volumes like that
with real data on them.

In addition, bls is finding jobs with Level=Differential and Level=Incremental
from dates before the firstwritten date in the catalog.  Possibly this tape
was originally used in a different pool?

Have you looked at the bacula logs to see what was reported when these tapes
were used?

__Martin


_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to