Jump to content

Backup Speed - What to expect?


Recommended Posts

Quote:

Hi

 

Retrospect runs as fast as the hardware will allow it to. How fast is your SCSI card? How fast is the tape drive meant to be according to the manufacturer?

 

Thanks

Nate

 


 

I do not believe that.

 

Retrospect's speed seems more affected by the number/size/type of files.

And, even when doing a Recyle backup, the backup set gets very fragmented, implying that Retrospect may not be sending large blocks to the file system.

 

Also, I do not see Retrospect reporting any useful throughput info.

The ONLY number that matters is the ratio of the total number of bytes transferred over the total time the job is run. This includes the time for overhead and shoeshining and ...

 

I see nothing resembling that info being reported.

Link to comment
Share on other sites

Quote:

Hi

 

Many small files copy much slower that fewer large files. That holds true in Windows Explorer as well.

 


 

Of course.

 

Quote:

 

Retrospect just pulls the files off of a disk and writes them as fast as the hardware will allow.

 

 


 

Hardware's not the issue.

It is clear that there are issues of compression, Retrospect overhead, and non-optimal fragmentation (for whatever reason(.

 

Even when doing a Recyle backup, the backup set gets very fragmented, implying that Retrospect may not be sending large blocks to the file system.

 

Also, I do not see Retrospect reporting any useful throughput info.

The ONLY number that matters is the ratio of the total number of bytes transferred over the total time the job is run. This includes the time for overhead and shoeshining and ...

 

I see nothing resembling that info being reported AND I've never seen a clear explanation of EXACTLY what the performance numbers are measuring.

Link to comment
Share on other sites

We really tried to make Retrospect work. We have a disk with a ton of small files on it. On the large files, we were seeing 230mg throuput, but when it got to the folder with 200,000 3-9 k files, it crawled to 9mg!!!!

 

Calls to Retrospect were to no avail. They even said to run a program to zip them into a big file before the backup! Well, I will not massage my data for a backup system!

 

I hate it, but went back to Arcserve (v11). The throuhput is 300mg and in the slow section with small files, it drops to 240mg, so we are happy there.

 

I spent 2 months with retrospect, having paid about $1200 for it and options. Just could not get straight answers why the backups were so slow of how to fix it!

Link to comment
Share on other sites

Quote:

We really tried to make Retrospect work. We have a disk with a ton of small files on it. On the large files, we were seeing 230mg throuput, but when it got to the folder with 200,000 3-9 k files, it crawled to 9mg!!!!

 

 

 

Calls to Retrospect were to no avail. They even said to run a program to zip them into a big file before the backup! Well, I will not massage my data for a backup system!

 

 

 

I hate it, but went back to Arcserve (v11). The throuhput is 300mg and in the slow section with small files, it drops to 240mg, so we are happy there.

 

 

 

I spent 2 months with retrospect, having paid about $1200 for it and options. Just could not get straight answers why the backups were so slow of how to fix it!

 


 

 

 

Whomsoever at Dantz told you to zip the files before backup should be fired. Where's Donald Trump when we need him?

 

 

 

Retrospect itself appears to have a bufferring problem.

 

 

 

For example, if I do a Recycle backup to my external USB hard drive, Retrospect has about 70GB of unfragmented space in which to back up, currently, abbout 30GB. After a Recyle backup, under those conditions, there should barely be any fragmentation on the drive, yet that is not always the case. Rwtrospect should better buffer its writes.

 

 

 

Also, Retrospect does not take advantage of a significant amount of available memory. I realize that no app wants to be accused of hogging memory, but surely they could offer advanced users an option to set the amount of memory that Retrospect may use.

 

 

 

Also, I just not believe the timing figures displayed by Retrospect.

 

I want to see the following:

 

 

 

1. Total time from start to end of job for the backup portion.

 

2. The total number of bytes backed up.

 

3. Total time from start to end of job for the verify portion.

 

4. The total number of bytes verified up.

 

5. The time Retrospect waits for the user to MANUALLY swap media may be subtracted, but NOT the time for automatic volume switching.

 

 

 

All the other performance info is irrelevant, especially that which is on a drive by drive basis.

 

 

 

P.S. To be fair (why start now?), one cannot really compare the Arcserve performance figures with the Retrospect performance figures, without knowing how each is measured. The above 5 items I listed are the only figures that matter.

Link to comment
Share on other sites

Retrospect must not be using a ring buffer for the data.

 

 

 

I can see it acting this way if it is single threaded.

 

 

 

Grab a file, open, grab data, write to tape, repeat

 

 

 

But..

 

 

 

Arcserve has a process that forks off and loads the tape buffer, while a thread writes to tape, while a thread runs the rest. This is how they keep the tape buffer full.

 

 

 

On small files, I see/hear the tape drive start/stop constantly. Not streaming the drive at all.

 

While Arcserve DOES keep the tape streaming. The tape start/stops is what kills you.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...