2 Office Topology and v9

[dtwiley]

I'm about to deploy Veeam B&R v8 into a company with 2 sites, they have Hyper-V hosts in each site. The primary site will have a tape drive.

My plan was to have a repository and proxy in each site, with the central console on the primary site which is all fairly standard. I'll then use local backup jobs and then copy jobs to get the data to the remote sites in a bidirectional manner, ie. Site A copies to B and B to A

This has always caused the dilemma as a loss of everything at the primary site means I also lose the console so would have no way of recovering the servers. I'm assuming in this situation I'd basically have to install the enterprise console in the second site and then attach the local repository?

How does this change in v9 with the standalone console? Or is there a better way than what i'm doing it in v8?

Thanks

[veremin]

Or is there a better way than what i'm doing it in v8?

You're doing everything good. Though, If I were you, I would add configuration backup, probably, from production site to DR. In this case, if production server is lost, all you would need to do is to re-install backup server and restore its configuration.

How does this change in v9 with the standalone console?

Currently there are no best practices for a product that is yet to be released.

Thanks.

[dtwiley]

Thanks, I always do the config backup to a remote repository for this reason. Is there any more information on the v9 standalone console, not specifically best practice but any diagrams on what a topology in v9 may look like? Will partners have early access before release?

[veremin]

That's the only information that we've shared so far regarding ROBO enhancements.

In order to participate in early testing (beta), kindly, contact the System Engineer you're working with.

Thanks.

[ncolt]

I use vSphere Replication to copy over my Veeam management server to a DR vCenter, I guess you could use Hyper-v replica for this. In theory this should be quicker to restore than from configuration backup, although I've yet to test it.

[veremin]

Both of the ways (configuration backup, backup server replication) to protect backup server are described here. So, it's up to you to stick to whatever one you like most. Thanks.

[dtwiley]

Thanks, I guess this means I could use Veeam Replication too and just fire it up in Hyper-V rather than use the native Hyper-V replication.

Thanks all.

[veremin]

Yep, you can replicate VB&R server using either native Hyper-V replication or VB&R itself (recommended approach, as you'll have single pane of glass). Thanks.

[dtwiley]

Thanks, BTW, if i'm replicating a server to a remote site, can I save bandwidth by having the backup source the changed blocks from the replica rather than copying them over the WAN again?

I understand I can do this for the initial backup but is it possible to do this for ongoing backups?

It seems inefficient to have blocks streaming across all day for replicas and then have a backup copy job do it all again at the end of the day.

[veremin]

Keep in mind that you can use backup copy job as a source for replication job. Thanks!

[dtwiley]

Keep in mind that you can use backup copy job as a source for replication job. Thanks!

That's only useful if the backup copy runs more frequently. Normally we'd run backup copy jobs once a day but would want replicas to be updated every hour.

[veremin]

You can use local backup jobs running more frequently as a source for replication jobs. Though, in this case the blocks that have changed since the last run will still be replicated over WAN. Thanks.

[dtwiley]

Thanks, but this only takes load off of the production environment, local backups are by definition still local which means there is no benefit to remote transmission to the remote site.

Surely most people run replicas more frequently than backups, wouldn't it make more sense for backups to source from replicas instead?

eg.

Production VM A on site A, is replicated to site B every hour, then every night at say 11pm, a job runs which backs up the VM on A to a local repository on site A, then a copy job runs which copies this from site A to site B, HOWEVER it looks at the blocks already transmitted during the day on the replica on site B and sources blocks from there (so it doesn't have to pull them over the WAN from site A) and then finishes off with any changed blocks since the last replica from site A over the WAN, dramatically reducing duplicating WAN traffic.

Would I be right in thinking that if we were using a large enough WAN Accelerator database that these blocks would be sourced from the site B cache anyway and they will be there from the replica thus achieving the same thing?

[foggy]

Right, this is actually how it works, provided the same pair of WAN accelerators is used by both replication and backup copy jobs.