Offsite Copy - Pointless?

[West]

Offsite Copy - Pointless?

Can someone please proove me wrong -
I've done testing and found that once the image job hits the backup destination (an esata drive), and has the offsite copy enabled to goto a USB (connected to the same server). The Copy takes longer than the Job itself becuase it is not "COPYING" from the backup destination. I went to the presentations saying its supposed to replicate across to the offsite location FROM the backup destination. But how does it do that without  going back through the server that initialised the job itself? IN other words the COPY cant go directly to the OFFSITE location, and takes up extreme amount of bandwidth...
I could just run Another backup job that would do it faster?

So, to me i dont think the Offsite copy is worth it.
I was actually dissapointed becuase i thought this feature would be really useful.
Please comment and let me know if this is how it REALLY works.. etc

[David_F]

At support, our test results shows the typical amount of time one should expect given the load of the system and bandwidth use to transfer a copy of the recovery point image to a offsite storage location. The command is invoked at the client level but ran at the storage location to transfer a copy of the recovery point image. In your testing have you had better transfer rates going to network storage location or FTP site? Does all of the machines that you have tested performed in the same manner?

[sbarningham]

Hi
'scuse me jumping in here.
I too have these problems but also some info that may help.
It seems if storage is restricted to 'windows' systems that good transfer speeds are obtained, however once I introduce a non 'windows' storage device such as a NAS box using  Linux, setup as FTP or CIFS/SMB server then transfer speeds for off-site drop to a crawl, even though the backup speeds are good.
Regards
Steve

[David_F]

Steve thanks for the information.