Jump to content

Incorrect speed numbers reported during backup


kaikow

Recommended Posts

I know that I raised this before in some thread, but I have not been able to find the thread.

 

During a backup, retrospect reports the MB/minute processed.

 

During a backup, be it Normal or Recycle, that figure should change smoothly over a short time interval, however, I continue to witness the following behavior.

 

For example, the C drive on my system has about 2.6GB in about 25000 files.

As the files are copied to the USB hard drive, the numbers SHOULD fluctuate to reflect the cumulative files already backed up. Once a significant number of files have been backed up, that number SHOULD only fluctuate in small increments in both directions.

 

However, the behavior I see, say when 13000 files have been backed up is that, within a period of a minute or so, the MB/min figures have been seen to fluctuate between, say, 18 and 125.

 

This can occur ONLY because of a bug in retrospect's calculation of the MB/min.

 

I reported this quite some time ago, why does the problem still occur?

Link to comment
Share on other sites

Hi Howard,

 

I believe the MB/Min is designed to current performance rather than overall performance for the backup. As such the cumulative files are not taken into account. Cumulative stats are availible in the log after the operation completes.

 

You could argue that this is not the way it should be but it does have its benifits:

inagine I backup 100GB of files at 1 GB/ Minute then throughput on the client machine drops to 1MB a minute due to another background process. Cumulative stats would still show the client backing up at a good clip long after the performance dropped.

 

This is true with Retstores too. When a tape is failing the drive will try to read a tape over and over again until it can read the data. This "shoe-shining" puts wear and tear on the tape and the drive. Because of the way stats are measured now you can see very qucikly that data throughput has dropped to zero and stop the operation. You wouldn't be able to catch this as easily if stats were cumulative.

 

Nate

Link to comment
Share on other sites

Quote:

Hi Howard,

 

I believe the MB/Min is designed to current performance rather than overall performance for the backup. As such the cumulative files are not taken into account. Cumulative stats are availible in the log after the operation completes.

 

You could argue that this is not the way it should be but it does have its benifits:

inagine I backup 100GB of files at 1 GB/ Minute then throughput on the client machine drops to 1MB a minute due to another background process. Cumulative stats would still show the client backing up at a good clip long after the performance dropped.

 

This is true with Retstores too. When a tape is failing the drive will try to read a tape over and over again until it can read the data. This "shoe-shining" puts wear and tear on the tape and the drive. Because of the way stats are measured now you can see very qucikly that data throughput has dropped to zero and stop the operation. You wouldn't be able to catch this as easily if stats were cumulative.

 

Nate

 


 

Both statistics can be useful.

However, I do not recall seeing any documentation on how the speed is reported.

 

If reported based on use over the last minute, then say that.

Better would be to report both numbers side-by-side so we can see what's going on. Say:

 

"Total: 100MB/Min, Average of past 2 minutes 23MB/min".

 

Your documentation would also need to explain these numbers.

Link to comment
Share on other sites

Quote:

Hi

 

 

 

The stats are not reported differently based on the media you are using.

 

 

 

Nate

 


 

 

 

Of course, if the fluctuations are alleged to be related to polishing one's shoes, that would not apply to a hard drive, since the only app accessing the USB hard drive would be retrospect.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...