Is there a file size limit on the tapes?

[Laarkie]

Hi Mark,

I have done several backups and restores with DPM 2010 and mhvtl.
My tests first indicated that "small" restores (less than 20gb) worked fine.
Today I made a few 15gb tapes to force the 27gb file that I have problem with restoring to be split.
It worked!

I'm using:
mhvtl 1.2-1
Spectra Python Library and STK T10000B tape drives. (from the default config)

Could it be a driver issue (W2k8R2) or is it possible that mhvtl can be updated to work with bigger files?

Best regards,
Laarkie

ps.
It works fine to restore big files from the disk backup so it's not a Microsoft "feature".

[Mark Harvey]

Laarkie wrote

I have done several backups and restores with DPM 2010 and mhvtl.
My tests first indicated that "small" restores (less than 20gb) worked fine.
Today I made a few 15gb tapes to force the 27gb file that I have problem with restoring to be split.
It worked!

what sort of error do you get ?

Do you have the syslog (/var/log/messagles typically) available for analysis ?

Cheers
Mark

[Laarkie]

Hi,

On Friday I turned on logging and verbosity 3.
Spent the better part of the day going through different restores and Tape sizes.
Both working restores and failed ones seem the same... When looking in the logs.
Fridays tape-backups have all failed. Restoring from disk work perfectly. The tapes are created from disk.
Seems like smaller tape sizes doesn't fix my problem. Tried both T10KA and T10KB media with 15000mb size.

Looking at thursdays log (which was less informative) It looked the same as the failed ones. :(

This is the error message DPM provides.
"DPM encountered a critical error while trying to parse the contents of the tape WRKM-EXCH-00000022 (G03014TA). This may be because the data on this tape is corrupt."
Since I've not seen any success stories(besides my successful restores :) ) with DPM 2010 and mhvtl. I assume I'm the first to test.
If anyone have been more successful with testing this combination please share.

Best Regards,
Laarkie

[Laarkie]

I have "played" around with different product revision levels for the tape drives and also with compression levels and on or off.

With my latest config I've been successfull with both a 23GB BMR and a 41GB BMR.
Created 2 of each.

Spectra Python library with no product revision line at all.
And STK T10000B drives with
Product revision level: 1.42
Compression is lzo and level 1. (Does lzo have a level 5?)

Does drivers behave differently to different Production revision levels? Or is this just a coincidence?

The media is 64GB so the subject of this thread is a bit misleading now.
My problem has nothing to do with files being to big. :)
I will do new tests tomorrow as the files backed up for BMR are created in the evening.

Wish me luck! :)

[Laarkie]

Everything is working great now!

I can restore everything I put on the tapes.
I will create a new mhvtl machine from scratch just to make sure I'm not just having a lucky streak.

Have a great weekend everyone! :)

[Mark Harvey]

Looks like you are keeping us guessing...

What changed so you can now state "Everything is working great now" ?

Was it some configuration on the mhvtl, the SCSI Target or Windows side ?

Some sort of summary of what the problem was and the solution (as simple as 'fat fingered xyz config file' or 'tweeked this setting', thru to 'upgraded subsystem abc') will be helpful for others who may face a similar challenge in the future.

Cheers
Mark

[w_bufffet]

could you please post the configrations of SCST & mhvtl so i can try to replicate?