Jump to content

Backupset Properties Summary tab reflects wrong total backup size


GRK

Recommended Posts

ENVIRONMENT: Backup Single PC to LTO-1 external Tape retro 6.5.350 - XP Pro.

Video Editing station. Typical file size 1GB-2GB.

 

PROBLEM: Click Configure->BackupSets-><BackupSet Name>

Windows Displays Summary/Options/Snapshots/Sessions/Members tabs

Click on Summary tab and you see something like:

 

Used 461GB for 23,450 files

Available XXG, assuming media capacity of 101.5GB

Storage: 57 Members in use, 149 session, 3 snapshots

Options: Fast Catalog File Rebuild

Security None

Catalog File: C\documents\blah blah

 

DETAILS: I have 57 100GB tapes native that have appx 40,000 files equaliing appx 5.4TB in total data. Backups are mostly archive data historical. I recently noticed that my Summary Tab on a 5,400GB backup set said in the first line

______________________

USED 1,241GB for 41,XXX files

Available XXG blah blah

Storage 57 members in use, 149 sessions, 3 snapshots

______________________

But this is a 5,400GB backup set I said to myself....

 

So as a test I click Restore/Find Files/ etc and select ALL files in backup

The files it find are 41,XXX files totalling once again 1,241GB???

So even RESTORE is confused about doing the file math, it's got the quantity right - but the total size is wacked.

 

So I think rebuild catalog - no big deal

Using Fast Catalog rebuild - insert tape 57 and let the machine finish and...1,241GB for 41,XXX files.

 

So I think - maybe the "Fast Catalog File Rebuild" header on 57 is corrupt - I'll go back to 56 for safety.

Rebuild catalog from 56 - requests tape 57 - etc - finishes

Final result: 1,241GB for 41,XXX files again.

 

Great now I start the long journey.

I go back to tape 55 but I don't wait for rebuld to finish on this one - I start catalog rebuild which normally reads the Fast catalog header and then starts reading files from that point forward. I just click stop to see if the Fast Catalog File rebuild header is even correct. In short I want to see if my STARTING POINT is even correct. NOPE.

Result: 1,XXXGB for 40,XXX files

 

In short I then begin this progression.....

54 = 9XXGB for 39,XXX files

53 = 8XXGB for 39,XXX files

52 = 7XXGB for 38,XXX files

so forth and so on.....

this naturally progresses back to basically the TWILIGHT ZONE tape 44 where I get the AMAZING result 48GB for 28,XXX files. Can you imagine something this stupid when average file size is 1GB on a 1TB Raid of Video data?

 

So finally I make it back to tape 43

Suddenly - results miraculously jump to

3,982GB for 27,XXX files

 

At this point I'm on the long road of rebuilding catalog from tape 43 all the way to 57 which on 100GB tapes will take days and days. Who knows what I'm in for once I reach tape 57. I'm of course trying to cut short the prospects of a MASSIVE rebuild from tape 1(ONE) which would take oh maybe 2 weeks to finish. no guarantee of course once it finishes I won't end up with 1,241GB for 41,XXX files.

 

How do you convince retrospect NOT to think mathematically impossible things like:

44 x 100GB LTO-1 tapes = 48GB total????

 

Biggest problem? - no error codes. Retrospect is perfectly happy thinking that on tape 43 I have almost 4TB of data in 27,XXX files but suddenly on tape 44 - I have appx the same 27,XXX files but suddenly they only add up to 48GB and it's affecting every stinking tape from there forward.

 

I may have already found the answer but the answer stinks. I wonder if anyone else has experienced anything like this or has any ideas how to prevent it?

 

My biggest concern is - when I start to do a restore and select all files - the same BAD math follows into the restore function. That makes me think this is more than just cosmetic "SUMMARY" tab problem. This program actually thinks when you tally up 27,000 files they add up to 48GB instead of 4,000+GB.

 

So this means the catalog has forgotten how to to basic math addition or

even when I do tape verify and everything as recommended the catalog can just spontaneously lose track of 4TB of information?

 

There really are no good answers here. I've totally lost confidence in this product. But you all are free to type whatever you think might help.

Link to comment
Share on other sites

It gets better.

I backtracked to tape 41 which was 3.9TB.

Upon rebuilding to tape 42 - the 4TB barrier was crossed and it jumped to 29,XXX items and 47GB total.

 

This is POSITIVELY suspicious. why? 4TB on the nose?

Link to comment
Share on other sites

Always fun just talking to myself.

No time to waste.

 

I upgraded on the remote chance something was hosed in 6.5.350.

It was.

Retrospect 7 launched and immediately all this wasted time was for nothing.

The catalog reported the proper size.

 

There's a 4TB single backup limit in 6.5. What a joke. Like a terabyte is a big number or something nowdays.

 

Maybe this will help someone else. thanks dantz for wasting an entire weekend for me and not having ONE siNGLE tech note about this that I could find. Believe me I searched and searched, faq's, knowledgebase, forums, techn notes, google, usenet. nothing about this.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...