incorrect transfer rate value during restore

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

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?

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

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

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

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

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