v6 Offsite Replication : Seeding How To

[WPHIT]

Hi Everyone,

Looking for some advice.

I'm replicating between two sites over a 100MB fibre link, currently I'm not seeding I'm just doing straight replications. But with 50+ servers to replicate this is going to take too long.

Try as I might but I cannot get seeding working.

This may be something I'm doing wrong?

1. Setup a new backup respository on a USB drive connected to the Veeam Server at SITEA
2. Backup SERVERA to this drive
3. Take drive to SITEB and upload vbk files to a respository connected to my VEEAM Proxy server (SITEB)
4. Re-Scan that repository in Veeam (SITEA)
5. Do a new replication job but this time select to seed from the repository connected to the VEEAM proxy server at SITEB

Is this correct please?

Thanks,

Andrew

[Vitaliy S.]

Hi Andrew, please take a look at the first page of this thread for the proper replica-seeding procedure.

[rbrambley]

I'm replicating between two sites over a 100MB fibre link, currently I'm not seeding I'm just doing straight replications. But with 50+ servers to replicate this is going to take too long.

and

5. Do a new replication job but this time select to seed from the repository connected to the VEEAM proxy server at SITEB

If you are already running a replication job for a VM you just click the seeding (low bandwidth) check box on the first screen of the existing job wizard / properties and then configure the repository location on the seeding screen in the job.

Seeding for replication is not an ongoing process. It's a 1 time feature for getting the new full replication done across the WAN.

If your jobs are completing but talking too long you should double check your config and consider other changes.

• Do you have a proxy at both sites? Is the job going from a proxy at sitea to a proxy at siteb?. This allows Veeam to compress the data before sending and then inflate on the other side. This is a required config.
• Look at the VMs and the times to complete / data transfered in the job reports too. Are a few VMs taking longer than the others? Maybe move those VMs to their own jobs using other proxies (for example) so they don't hold up the bulk of the other VMs.

Of course, there is only so much we can do for low bandwidth between sites - I have to say this because I see a lot of high expectations on large amount of data passing over smaller, saturated pipes.

[homerjnick]

I'm away to start replication at our 10Mb WAN DR site...I read the procedure in the manual and in this thread but have a quick question.

It was noted earlier by Vitality the stepped procedure but this is what I have done.

1) Taken a NAS device and added it to my Veeam server as a repositry at my Production site.
2) Taken backups of VM's I want replicated to this repositry
3) Take NAS off my Production site and added it to the network at my DR site.

I was then going to add a new repositry using the NAS device which is now at the DR site (or can I just repoint the location of the repositry when the NAS was on my Production Site)

New repositry has the backups in there so can use that as my seed.

Will that work?

[rbrambley]

Even with the files local at the DR site you could create a scenario where data is ping ponging back and forth. Things to think about:

Has your NAS changed ip addresses?
What is the network route / gateway for the NAS and for Veeam ?
Is your Veeam install you will be using to run the new replication job different from the one that create the backup seed?

If it's a new Veeam server (at the DR site) other than the one that ran the backup job then you have to create a new repos linked to that new DR Veeam anyways. Proxy and repos sets can only be linked to one Veeam server.

So, think about where the replication job will be created, and what proxy / repos sets are configured there, and how they will communicate and data will flow, and keep it all local to your DR site!

[homerjnick]

Even with the files local at the DR site you could create a scenario where data is ping ponging back and forth. Things to think about:

Has your NAS changed ip addresses?
What is the network route / gateway for the NAS and for Veeam ?
Is your Veeam install you will be using to run the new replication job different from the one that create the backup seed?

If it's a new Veeam server (at the DR site) other than the one that ran the backup job then you have to create a new repos linked to that new DR Veeam anyways. Proxy and repos sets can only be linked to one Veeam server.

So, think about where the replication job will be created, and what proxy / repos sets are configured there, and how they will communicate and data will flow, and keep it all local to your DR site!

I have one Veeam server at my Production site and one Veeam Proxy at my DR site.

Yes the NAS device will change its IP and the same Veeam server that ran the backup will run the replication.

I will create the replication job on the Veeam server at my Production site but point the new rep job using a seed on the NAS box which is now at the DR site with the backups I created now in a new repositry which is on the DR site...

I fail to see if this is an issue? My only concern is am I ok to use the NAS to backup directly to at my Prod site as it is added as a repositry and then move it to the DR site, add another new repositry that points to the NAS at the DR site, scan it and it picks up the backups that were dumped there whilst the NAS was at the Prod site??

[foggy]

I fail to see if this is an issue? My only concern is am I ok to use the NAS to backup directly to at my Prod site as it is added as a repositry and then move it to the DR site, add another new repositry that points to the NAS at the DR site, scan it and it picks up the backups that were dumped there whilst the NAS was at the Prod site??

Nick, no issues, actually. I believe that you even can just repoint the existing repository to the new location and rescan it to get existing backups imported.

[homerjnick]

I fail to see if this is an issue? My only concern is am I ok to use the NAS to backup directly to at my Prod site as it is added as a repositry and then move it to the DR site, add another new repositry that points to the NAS at the DR site, scan it and it picks up the backups that were dumped there whilst the NAS was at the Prod site??

Nick, no issues, actually. I believe that you even can just repoint the existing repository to the new location and rescan it to get existing backups imported.

Fantastic...thanks.

[homerjnick]

Foggy,

How do I repoint the existing repository?

I go into the properties and then the Repository part but the "Path to Folder" that contains the network share path is greyed out so I cannot type in there to change it.

The "Share" section is also greyed out...so I cannot type in the new shared folder path.

[foggy]

Seems that there's indeed no way to do that, sorry. For some reason it seemed to me that you could edit the location for Windows-based repository.
Then in your case, you need to add a new repository and point it to the DR site NAS.

[homerjnick]

Fair enough I can do that...

[vcosonok]

G'day, I stumbled across this post when I made the mistake of advising a colleague incorrectly based on my experience of VBR5. Alas, I had not read the VBR6 user guide before advising my colleague. The following blog post might provide some enlightenment:

VBR6: How to Configure Replica Seeding in Veeam Backup v6 for Offsite Replication

Cheers!

[chad156]

I has an issue were my failover failed and my Servers are still running from the DR site. I performed a back up of the virtual machines and sent the USB drive back locally to replicate back with a seed.

When I set it up and run the job I get and error that it cannot find the VM in the backup to seed from.

I have the repository setup and when I scan the repository it say it skipped two backups?

Can someone shed some light on this?

[chad156]

I'm not sure why my post was merged...I know how to seed, i've done it many time.

[Gostev]

The post was correctly merged because we want all seeding-related questions and issues covered in the single topic instead of being spread across the forum.

However, it would be even more correct if moderator removed the post completely instead of merging, because it violates the rules of posting technical issues displayed when you click New Topic. No issue can be troubleshoot without having debug logs available, so first thing R&D will ask me when I approach them with your issue is support case ID.