Please refer to the screenshot attached.
The left 1/3 shows the backup sets from 2 tapes, clearly maked is the file job's D:\ drive on both tapes with the same size.
The middle and right 2/3 show the backup set's content containing the same data.
This was a month-end run and there are a few hundred more GBs to send to tape, but both tapes show as full and the jobs will not run. The drive is a single drive in a library with 2 slots partitioned for the EOM job.
What I think happened here is the backup set for file\D didn't fit on the first tape, so it continued onto the 2nd tape. However, the size of the partial job on each tape wasn't recorded correctly.
What are my options here, other than erasing and starting all over?
If I understand correctly, your screenshots don't show the tapes, they show backup sets.
What happened to the job that filled up the second tape? did you cancel it? it is requesting that you import media into the library so the job can continue?
The odds of a job ending EXACTLY as a tape was getting marked "full" are pretty low. So I would assume that BE is or was trying to span to a third tape.
Not exactly, they show the backup sets ON THE TAPE.
In 2012, go to storage > partition details > slots > slot details > backup sets (first screen grab) > snapshot details > contents > expand to folder (2nd/3rd screengrabs)
Yes it wanted a 3rd tape. It SHOULD FIT on 2 tapes with room to spare.
I never assumed the job would finish at the end of the tape, didn't mention that at all.
I canceled the job, yes. I attached another screenshot of the history. Don't bother looking at it, because that's not the point of my post here.
If I may call your attention to the size of the backup sets on each 1.4GB tape.
The tapes are also BOTH reporting compression ratios of 1.0. The top set is reporting more data that can possibly be on that tape. There shold be another 3-400 GB of space left.
How do I proceed, other than erasing the tape and starting from scratch, if I can at all?
Not sure if this is affecting the stats you are looking at
However even if it is not exactly that I would suggest you do update to BE 15 FP3 as we have clearly made changes to the way stats are reported
It might be a compression issue. You wouldn't know if from any stats in this program, though. The D drive snapshot was only 2GB bigger than last month. One of the mail DBs is actually 140GB SMALLER this month! Yet still I had this issue. See attached for last month's first tape that fit so much more data on it.
And referring to the link, reporting of sizes seems very ambiguous in all versions of BE. Would it be too much to ask for the "size" stats to indicate compressed or not?