Jump to content

Backup is too slow


baxsie

Recommended Posts

We're using Retrospect 7.6 on a quad core machine with 4GB of RAM, on a gigabit network, and to backup ~750GB of data takes around 24 hours.

 

Here's the rub:

 

1Gbps = 10^9 bits per second / 8 bits/byte = 125,000,000 bytes per second or 122000 kibytes per second or 119.2 Mibytes per second

( source 1 and source 2 )

 

Theoretically then we're looking at a maximum of 4.5 GB / minute, so 166 minutes to pull that much data through the network, in a perfect world.

 

Let's assume we actually get 25% of that speed. If this were the case, we would be looking at just over 11 hours to pull all that data through the network. This would be doing phenomenally well.

 

Let's look at reality for our backup set now -- more along the lines of around 26 hours for our backup to complete, which would be equivalent to a little over 480 MB/min average. The problem is that 480 MB/min boils down to 60 MB/min per execution unit.

 

What are we missing here?

Link to comment
Share on other sites

Theoretical values are just that, theoretical and never going to happen in real life.

 

What type of backup device?

How much free space is on the C: disk on the backup server?

Are you using compression?

Are you using encryption?

What is the speed of the source hard disk?

 

The speed of the source disk, the size of the packet being read from the source and then written the destination (transfer rate/size), the size of the disk buffers, disk fragmentation, small files, large files, mixture of file types and the speed of the network connection on the source are all factors in performance.

 

480 MB/Minute over the network seems like a good speed to me. Very typical.

 

I don't know why you feel 480 MB/minute is the same as 60 mb/min/execution unit. Have you even tested this? I am sure that it isn't that bad. Have you considered putting multiple network cards in the backup server so that each execution unit pulls data from different network interfaces?

Link to comment
Share on other sites

The theoretical I was referring to was based on actually measured bandwidth versus the theoretical per the specifications for gigabit ethernet.

 

The 480 MB/min is what we're actually seeing, which works out to be 480 MB/min / 8 execution units = 60 MB/min per unit.

 

That said, will retrospect take advantage of multiple NICs to get the backup done? If this is the case, we would have loved to have known sooner, as this would have made us change the backup server years ago.

 

How much difference will multiple NICs make, in a real-world situation?

Link to comment
Share on other sites

I'm assuming you are actually trying to backup 8 clients simultaneously. Is that right?

 

480 MB/Minute over the network seems like a good speed to me. Very typical.

 

Per execution unit, I'd agree.

 

60 MB/min per unit.

 

That's fairly slow if that is indeed what you are seeing.

 

How much difference will multiple NICs make

 

None. You only need multiple NICs if you are maxing more than a single gigabit's worth of speed. But you aren't even maxing out a 100 Mb connection!

 

That being the case, there may be rational reasons for your getting such poor performance (again, across 8 execution units). For example, if you are backing up many, many, very tiny files.

 

OTOH, if you are backing up a single client, again, the size and number of files often plays a major role in the performance. This speed seems reasonable for a relatively fast desktop on a 100 MB connection.

 

What's the size of an average file?

Edited by Guest
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...