Jump to content

Retrospect 9 Performance on 4-core Mac Pro


Recommended Posts

One of my customers asked for an assessment of how to get the best performance out of their backups and still have some security on the backup set and make the best use of storage. They are similar to many of my other customers in that they have a modern multi-core Mac Intel CPU server with 1000T network and eSATA or Fibre Channel attached storage devices. One difference with this customer is that they back up mostly JPG files. I set out to test a variety of scenarios to see how they would perform and where the bottlenecks were. I thought it was worth sharing and may also give the Retrospect developers some information about how Retrospect 9 performs in the real world backing up JPG images. Here are the results and my recommendations to them:

 

--------------

 

 

I set up a series of backups of 19,613 files totaling 13.75GB of primarily JPG files which should give similar results on a smaller scale to what the customer has. There were no TIFF files in my batch so compression of those files would result in slightly higher overall compression.

 

I used a 2010 Mac Pro 2.93 GHz quad-core eSATA connected to a Western Digital My Book Studio Pro II 4TB backup drive. The client machine is a MacBook Pro connected via 1000T ethernet with a 7200 RPM 500GB disk drive.

 

For the first test I ran the following settings: Password protection, no compression, no verification, no catalog compression and got the following results:

 

Elapsed time: 6 min 31 secs, Data Rate: 2.1 GB/min, Backup Set size: 13.73 GB

Retrospect CPU Usage ~ 100% of 1 CPU almost entire time

Workstation CPU ~ 15% of 1 CPU average

 

I then turned on Media Verification and ran it again which produced:

 

Elapsed time: 9 min 20 secs, data rate: 1.5 GB/min, backup set size: 13.73 GB

Retrospect CPU Usage ~ 100% of 1 CPU almost entire time

 

I did not test turning on "Thorough Verification".

 

I turned verification back off and turned on compression which produced:

 

Elapsed time: 12 min 42 secs, data rate: 1.5 GB/min, backup set size: 14.62 GB - NOTE LARGER SIZE WITH COMPRESSION

Retrospect CPU Usage ~ 100% of 1 CPU almost entire time

 

I believe that the larger size above was the result of Retrospect trying to compress JPG documents which are already highly compressed which results in the compressed file actually being larger than the original.

 

Turning verification back on and keeping compression yielded:

 

Elapsed time: 14 min 18 secs, data rate: 0.894 GB/min, backup set size: 14.62 GB

Retrospect CPU Usage ~ 100% of 1 CPU during both backup and verification phases

 

To see how much disk drive bandwidth affects the remote backups I switched from using the eSATA 3Gbps port to FireWire 800 on the same drive and re-ran the uncompressed fastest backup:

 

Elapsed time: 6 min 42 secs, data rate: 2.0 GB/min, backup set size: 13.73 GB

 

This surprised me, I was expecting the eSATA to perform at a much higher rate but the current version of Retrospect is unable to deliver the data fast enough to make use of it.

 

At this point I switched to using AES-128 Encryption and re-ran the relevant tests (using the eSATA interface again)

 

Testing with encryption but no compression yielded:

 

Elapsed time: 11 min 45 secs, data rate: 1.1 GB/min, backup set size: 13.73 GB

 

Retrospect CPU Usage ~ 115% of 1 CPU almost entire time

 

Testing with both encryption and compression yielded

 

Elapsed time: 17 min 40 secs, data rate: 0.76 GB/min, backup set size: 14.62 GB

 

Retrospect CPU Usage ~ 110% of 1 CPU almost entire time

 

Conclusions:

 

1. Retrospect Server is single-CPU-limited even with uncompressed remote backups. Use the fastest CPU available.

2. Even with a fast 2.93 GHz Xeon CPU Retrospect was barely able to fully saturate FireWire 800 so there is not a lot of benefit

to using the faster eSATA interface on a machine below 3GHz. The faster interface yielded only about a 3% speed benefit.

3. Media Verification slows backup of a remote device by about 50%

4. Compression slows backup by about 100% and may result in larger backup files if highly compressed original files are being backed up.

5. Data Encryption appears to be able to make use of at least part of an additional CPU reducing its impact on the backup time.

6. Data Encryption did NOT increase the size of the backup but did incur almost a 50% performance penalty over password protected

7. The combination of Encryption and Compression reduces the speed to only about 1/3 the speed of Password without compression

8. Slowest backup is Encryption, Compression, Verification

 

Recommendation for my customer:

 

1. Leave compression off, the decreased speed and increased size of already-compressed files makes it not worthwhile for JPG backups

2. Leave catalog compression off

3. Use either "No Verification" or "Media Verification" (but keep "Generate MD5 Digest" option turned on for manual verification)

 

Recommendation to Retrospect team

 

1. Figure out how to take advantage of multiple CPUs on the server machine

2. Consider distributing the compression and/or encryption workload to the client

Link to comment
Share on other sites

2. Consider distributing the compression and/or encryption workload to the client

I disagree with that statement, at least for Windows clients. Even without compression, many of our Windows' clients slows to a crawl when the backup runs. It has become better for the latest (fastest) computers added to our network.

At the very least, compression should be optional PER CLIENT.

 

(I do agree with the rest of your recommendations.)

Link to comment
Share on other sites

  • 2 weeks later...

Although I don't run the Mac version of Retrospect, I agree that when backing up a Windows machine (Proactive, for example) it will be brought to its knees when the disk scan takes place before and after the actual backup. Pushing the encryption/compression to the client would be great in a desktop/server environment where there is an 'out of hours' window where the users are not impacted.

 

Rich

Link to comment
Share on other sites

  • 1 month later...

I disagree with that statement, at least for Windows clients. Even without compression, many of our Windows' clients slows to a crawl when the backup runs. It has become better for the latest (fastest) computers added to our network.

At the very least, compression should be optional PER CLIENT.

 

(I do agree with the rest of your recommendations.)

 

I agree that it should be an optional feature. I too have some older singe-core Pentium machines at clients and pretty much everything brings them to their knees.

Link to comment
Share on other sites

Your tests didn't show why you recommended having Catalog Compression turned *off* -- can you elaborate why?

 

I was trying to maximize the performance wherever possible. There is a significant delay for a large backup set at the end of a script when it does the catalog compression. Timing that aspect of it in my test wouldn't have been meaningful because the catalog was so small. Some of the backups that I manage have several million files.

Link to comment
Share on other sites

Thanks for the information, both enlightening and a little shocking.

 

v9 Lion compatible and only uses one core of the cpu (is that what was meant, as your point one says 1 cpu rather than 1 core, unless this is a multi cpu server?)

 

I did the test on a 1-CPU 4-Core Hyperthreading Xeon Mac Pro (8 threads). When I said 100% of 1 CPU I should have said 100% of one thread so on this machine it was only using about 12-15% of the processing power available.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...