Veeam 6.5.0.144 Replication to DR site

[kmile]

Hi Everyone,

Its my first time on the forum. I have one little question.
I believe I have our offsite replication configured properly. The question is to do with 'Map replicas to existing VMs' tick box. I am using this option for the initial replication job.
Do I need to un check it after the first successful replication job? Or do I leave it there and Veeam will know what to do in the next jobs?

I would appreciate your input.

Thank you in advance,
Kamil

[veremin]

Hi, Kamil. Replica mapping is an one-time operation, so feel free to untick corresponding option, once the initial run is finished. Thanks.

[kmile]

This was quick Thank you for your reply. What would happen if the option was not unticked?
Thanks

[veremin]

Actually, nothing is going to happen, even if you leave this option ticked. Thanks.

[kmile]

Ok. Many thanks. I am quite new to replication. Am I right in thinking that the initial replication always/usually takes longer than the later incremental ones? The VM I am replicating is 670GB in total. The initial replication was done locally and then the storage with the replica has been transported to the DR site.
I started the replication over WAN yesterday, it's been going for 19 hours and it's at 70% reading 6MB/s as processing rate (bottleneck network). It processed 465GB and transferred 34.2GB. The original replica at DR site was just over a week old hence so much data to be transferred. When replicating the same VM to a local storage everyday it never exceeded 12GB, sometimes it was as little as 4GB of data transferred.
Will the replication always need to process all 670GB or is this only at the initial replication (As you know I use replica mapping for this).

Sorry for some many details, I hope it makes sense.

Appreciate your input.
Kamil

[veremin]

Will the replication always need to process all 670GB or is this only at the initial replication

Yep, during first run VB&R needs to process it in order to find differences between two virtual machines – source and target one. After that replication runs are supposed to be much quicker. Thanks.

[kmile]

Good to know that.
Many thanks for your assistance.

[veremin]

You’re welcome. Should any additional help be needed, don’t hesitate to let us know.

[kmile]

Hi Again,

The replication job finished successfully. I am now running it again to compare the performance between the initial replica and normal replication job and wow - this thing is flying. Here are the details of the initial replica job:
Name....................Status..... Start time.......End time...........Size..............Read.........Transferred.....Duration
SERVER NAME..........Success....13:21:56.........23:10:42 (+1).....670.0 GB........668.0 GB.....52.1 GB.........33:48:45

The job I am running now (I unticked 'Map replicas to existing VMs') has been running for 1 hour and 30 minutes and it is already at 65%! This is really good.

I have however one more question:
The job is scheduled to run every day at 19.00 and in it's configuration it has 'Restore points to keep' set to 7. Now the question: If I run the job manually like I did this morning will this run be taken into account or the restore points are only counted with the scheduled jobs? The job will still run tonight at 19.00.
Sorry, I hope my question does make sense.

Again, thank you in advance for your assistance on this.

[foggy]

Kamil, all the restore points are counted within the retention policy you specify. You even can run the job 7 times a day and on running it the 8th time, the oldest point will be subjected to retention.

[kmile]

Thank you Alexander. Say I ran the job 7 times a day and my retention period is 49 restore points. (7 times a day x 7 days a week) Does this mean I will always have 7 days or a week worth of restore points?
Am I understanding it correctly
By "subject to retention" do you mean deletion? When the restore points outside of the retention period get deleted?

As always I would be very grateful for some clarification.

[veremin]

49 restore points

Actually, there is a limited number of replication restore points you can keep and this number is 28 (as per VMware limitation).

By "subject to retention" do you mean deletion?

Yep, you’re right. Each run of replication job (be it scheduled or manual one) produces new restore point and the total number of restore points is controlled by retention policy. Thanks.

[kmile]

Thanks Vladimir. Sorry for asking obvious questions but I somehow feel better when I receive a confirmation from somebody who knows the product better, than me relying only on the user guide and my understanding of it.

One other question please: Say I start replication of a VM at 9.00. It takes 3 hours for the job to finish - 12.00. Is the VM replicated current (12.00) or is it 3 hours old from 9.00?

I hope this question makes sense

[veremin]

Sorry for asking obvious questions but I somehow feel better when I receive a confirmation from somebody who knows the product better, than me relying only on the user guide and my understanding of it.

Not a problem.

One other question please: Say I start replication of a VM at 9.00. It takes 3 hours for the job to finish - 12.00. Is the VM replicated current (12.00) or is it 3 hours old from 9.00?

Second (9-00). Thanks.

[kmile]

Many thanks!

[veremin]

Configuration backup is totally different feature that has its own retention policy. This setting, in its turn, has nothing to do with the settings of your backup/replication jobs. Thanks.

[kmile]

Guys, I am back.
I hope an easy one for you - if you can please. Replication has been working fantastically so far.
One question though:
I would like to schedule it to automatically run twice a day, at 13:00 and then at 18:00.
I don't seem to be able to get this working. What I did initially that worked is the following:
Selected 'Run periodically' every 5 hours and only enabled the following time periods 13:00-13:59 and then 18:00-18:59. It worked initially but then it stopped. It did not run at the weekend but strangely it is scheduled to run today at 13:00, which is correct.

Surely I must be doing something incorrectly here. Any ideas please?

[veremin]

did not run at the weekend but strangely it is scheduled to run today at 13:00, which is correct.

I’m wondering whether an interval during which replication job is allowed to run includes weekends, as well.

From my perspective, there are two options how you can achieve what you’re after – you have to either use the backup window, which you’ve implemented already (though, the interval can be set even as 13 00 – 19 00) or utilize the PS script in conjunction with Windows Scheduler (scheduled task at 13 and 18 o’clock):

Code: Select all

Get-VBRJob –name “Name of Replication Job” | Start-VBRJob 

Thanks.

[kmile]

Thank you very much.
It would be very useful if the scheduler had options to chose specific times for the backup/replication to run.
Has this been implemented by any chance in version 7?
Regards

[veremin]

In fact, it’s not possible to select double daily time in the schedule settings of replication job both in 6.5 and 7.0 versions. So, you have to either use PS with Windows Scheduler or run replication job every X hours with backup window being explicitly specified.

Thanks.

[kmile]

Thanks.

[kmile]

Hi Guys,

I discovered something really strange.
I checked the Veeam server this morning to see if the replica of one of our VM is scheduled correctly after yesterdays successful replication.
The replication job was correctly scheduled to run at 12:00 today. I now came back from lunch and the job is now scheduled for 18:00 and the one at 12:00 did not run - no notifications, no failures - nothing.

Why this may be please?

Thanks

[veremin]

Apart from manual intervention or scripting activity, I can’t imagine anything that might change replication job schedule. May I ask you to observe this behavior for several days and see whether the issue is reproducible or not? In case, it’s, you’d better contact our support team. Thanks.

[kmile]

This has been happening for some time now.
I have the job set to run periodically every 5 hours with two backup time periods 12:00-14:59 and 18:00-20:59.
This is to ensure I replicate all changes done before lunch time and then again all changes between lunch time and end of working day.
Am I doing something incorrectly here? May be it is not happy because is set to run every 5 hours? But then again this morning the backup was set to run at 12:00 but it did not run and after lunch I noticed it changed to run at 18:00. It works fine most of the days...
I had this situation going for some time now. When it happens I manually run the job but I would like it to run automatically...

[veremin]

Everything seems to be ok with the specified parameters; though, I’m not sure why you’ve set “run every 5 hours”, if, in reality, you want to run a replication job every 6 (at 12, and 18 o’clock). Thanks.

[kmile]

Thanks. I will keep an eye on this.
The offsite replication for one of our VMs (670gb VM) usually takes about 2 hours which is great.
However, once a week it runs for over a day! The retention policy is set to 14 days.
Does replication do full replica once a week no matter what the retention period is set to?
Is it possible to have something like the reverse incremental backup?
How does the replication increments work?

Many thanks again
Kamil

[veremin]

Does replication do full replica once a week no matter what the retention period is set to?

Actually, it shouldn't perform full run. After initial synchronization replication job is always incremental.

How does the replication increments work?

It works like a typical backup job, using CBT, in order to understand what blocks have been changed since the latest job run. Only changes are being copied to target location. As to retention policy, once the number of restore points is exceeded, the oldest restore point is merged with the next one (the same concept is implemented in backup copy job).

However, once a week it runs for over a day!

I’m wondering whether CBT is being used during these runs or not. Without CBT VB&R uses its proprietary mechanism, reading the whole VM image in order to find changed blocks. It, in its turn, might be quite a time consuming process.

Thanks.

[foggy]

I’m wondering whether CBT is being used during these runs or not.

Also look at the Transferred data count, could some activity inside the VM cause larger amount of changes prior these job runs?

[kmile]

Many thanks. CBT is being used.
I think we may have discovered what is causing this. However, it is still a guess.
That particular VM has a 600GB partition with a lot of files on it. That partition is backed up every Sunday (Full backup) using Backup Exec 2010 (tape backup). On the following day the replication takes very long and between 30 - 40 GB of data is transferred (whereas normally it is between 2-4 GB).
We think that Backup Exec could be remove the Archive Bit and hence the replication takes so long (Monday - Thursday the 600 GB is also backed up with Backup Exec but only a differential backup is performed).
Does this sound anything you have seen before?

Thanks,
Kamil

[veremin]

Yep, it makes total sense. The described activity affects badly amount of changed blocks, therefore, Monday replication job usually takes such a long time. Thanks.