incorrect transfer rate value during restore

[AndreaBolongaro]

Hi all,

during a ~10TB file system restore job, I have an unexpected value as transfer rate. I have a negative value in admin Java interface and an atypical value in win admin gui. Pls, have screenshots attached. Job is still on going: 3TB are already restored,  I had a correct value until more than 1 TB (i do not check it continously) last night, but this morning I see those abnormal values. This is an unusual restore, during ordinary restore jobs I have correct value. Did someone else have similar issue? I exceeded NB limit over which restore transfer rate results are unreliable?

thanks in advance,

Andrea

Master/Media server NBU 7.1.02 on Linux RHEL, Client W2k3 NB 6.5.4

[mph999]

I think in this case I would recommend logging a call with Symantec - I would image that you are seeing a bug in the Java GUI.

Martin

[Mark_Solutions]

I agree - raise a case as the bug may be for both - unless you have a fantastic system as the Windows one shows an incredible rate

Especially as the estimated number of files to restore is 0 and it has currently restored 0 files!

So far it actually indicates that it is just reading a backup image and has yet to find the first file to restore - that could explain the speed.

What fragment size do you use for your Storage Unit that holds this backup?

[mph999]

hmm, maybe we could make this a feature ...

+ve transfer speeds for backups ...

-ve transfer speeds for restores ...

... you have to admit, that would at least be 'logical ' ....

;o)

Martin

[AndreaBolongaro]

Thank you for your suggestions.

I submitted a case. As usual they asking for logs etc.

I'm using a hcart LTO5 stu with default value as fragment size (1048575 Mbytes).

I suppose problem depends on the algorithm NBU uses to count the transfer rate. During restores it seems to me that usually not the "grand total" average transfer rate is shown but a "short time" average speed.

Other issues are incorrect numbers in estimated KB and current files written: both 0. Luckily they are wrong, as now 3.9TB are already restored. Real transfer speed is ~48MB. Storage unit field is also blank on GUI.

Bye,

Andrea

[Mark_Solutions]

The default fragment size is pretty big - i would recommend reducing it to 5000MB.

Imagine having to restore a 30kb file that is almost at the end of the backup - it would have to read through almost 1TB of tape (and by the way this would show as the kb read in the status window) before it got to the file needed - so would take quite a while.

If using a smaller fragment size it would skim the tape to the nearest file marker and then start reading the tape from that position to find the file - so would have to read no more than 5GB of tape - way faster!

This could even have an effect on all of the figures you are seeing as it reports what it has read (even if it is not relevant to the file(s) you are restoring

Hope this helps

[mph999]

Not quite ...  - well, depending on the tape tech used.

In nutshell, most 'modern' drives use 'Fast block positioning'.  For example, LTO hold information on the internal chip inside the media cartridge, to index the data on the tape, allowing for fast positioning for restores.

For this reason, the reduction in fragment size is no longer required.

Martin

[Marianne]

Seems Mark and I are still 'old school'.
I have also been recommending reduction in fragment size for 13 years!