Pros and cons of Backup Copy feature

[trevora]

We currently run 6.5 on two virtual Veeam servers. Each runs two backup jobs per night which are staggered to reduce load (i.e. one job starts at 19:00, another at 21:00 etc). All backup jobs save to a NAS device. Each job runs a post backup script which runs a psexec command to a physical Win2008 server to robocopy the VBK files only (from reverse incremental backups - we don't copy the incremental files) to a USB drive that is plugged directly into this server (the USB drive then gets taken to off site storage and we cycle through several of them).

The new backup copy feature in v7 looked good initially, but the more I think about it I'm not sure it's any better than we have at the moment, for the following reasons:

1. Our current copy to USB starts as soon as the backup completes and we need this to happen to make sure the USB copies are in place as soon as possible for transfer to remote storage. As I understand it, the Backup Copy job will only start according to a schedule even when running continuously. I assume we could set the schedule to run frequently (every 15 mins?) to minimise the delay and presumably it will only copy the backup if it has changed (i.e. it won't try to copy every 15 minutes?).
2. Our current backup copy method puts the load away from our production environment and into the physical server and NAS device. Presumably there is an impact on the virtual VM's (and therefore our production environment) if they are backing up and then busy copying the backup (although I guess the USB copy speed is the limiting factor here anyway)?

In summary, is there any benefit in us moving over to use the Backup Copy features in v7?

[foggy]

1. Our current copy to USB starts as soon as the backup completes and we need this to happen to make sure the USB copies are in place as soon as possible for transfer to remote storage. As I understand it, the Backup Copy job will only start according to a schedule even when running continuously. I assume we could set the schedule to run frequently (every 15 mins?) to minimise the delay and presumably it will only copy the backup if it has changed (i.e. it won't try to copy every 15 minutes?).

If there is a new restore point already available at the moment when the backup copy job sync interval starts, the backup copy job will start processing it immediately. So you just need to schedule your jobs correspondingly.

2. Our current backup copy method puts the load away from our production environment and into the physical server and NAS device. Presumably there is an impact on the virtual VM's (and therefore our production environment) if they are backing up and then busy copying the backup (although I guess the USB copy speed is the limiting factor here anyway)?

Backup copy job does not affect production VMs in any way since it is copying data directly between backup repository servers.

All that said, your concern about copy speed is reasonable, you should test whether USB drives are capable of handling the backup copy job synthetic activity.

[veremin]

In this case of using backup copy job in conjunction with rotated drives, don't forget to implement the regkeys introduced in the 3 product patch. These regkeys allow you to use rotated drives as a target for backup copy job. Thanks.

[trevora]

Thanks for the info - it looks like this is definitely a good option for us then.

If there is a new restore point already available at the moment when the backup copy job sync interval starts, the backup copy job will start processing it immediately. So you just need to schedule your jobs correspondingly.

Just to check I understand this correctly, if we set the backup copy sync interval to run once per day and start 15 minutes (as an example) after a backup job start time will the backup copy job then wait until the backup job completes and then start the copy job immediately?

[foggy]

Yes, your understanding is correct.