PROBLEM TO REPLICATE EXCHANGE SERVER

[nai]

Hello, I have a problem to replicate a exchange server. Exchange server is a server with windows 2003 SP2 and with Exchange 2003. Every time I run it, after a time the task faile in the same point of data replicated whit this message:

Replicating file "[Datos Exchange Lun3] srvex/srvex_1-flat.vmdk"
BackupDisk failed
Client error: An attempt was made to access the data beyond the end of the virtual disk. Size of the disk: [16121548800]. End of the requested region: [16121856000].

Server error: End of file

Can anyone help me please?

[TrevorBell]

I think best open a support case for this, but as it says it thinks it can read further on the disk than you actually have,.

[nai]

and what is the meaning of that? I don´t understand

[Vitaliy S.]

Hello Elena,

It seems like the declared size of the vmdk file doesn't match the actual file size. Could you tell us whether you've performed any actions on that virtual disk before? And yes, Trevor is correct, to get quicker assistance, please open a support ticket with us.

Thank you!

[Gostev]

Elena, this issue is actually documented in the release notes. I have copied it below for convenience.

• Replication job with ESXi target starts failing with “An attempt was made to access the data beyond the end of the virtual disk” error after source VM disk size is increased. To work around this issue, remove replica VM, and re-create the replication job after making changes to source VM disk size.

If you don't believe this applies to you, then please contact our support directly for further investigation.

[Amer]

Hi there:
do we need to start the replica job every time we extend a virtual hard disk, this seems bit odd, we need to have the ability to keep our old replica/backups and as you know the storage always requirs increase in soime stage. Is there any work around that, that will be great.
Regards

[Vitaliy S.]

Hello Amir, currently there is no workaround for that, you need to re-create replication job every time you extend the hard drive. Thank you.

[athome]

Can one workaround on this be to manually move/rename the folder for the replica from vcenter.. and then from veeam B&R console: go under the replica-job, select the specific server and "Delete from disk"
In this way.. one does not loose ones existing replica in case of some failure happens before the new replicate-job has run completed.

A

[Vitaliy S.]

Andres,

Well, this can be done, but you will only be able to perform a failover to the latest VM state, as older restore points are only accessible from Veeam backup console.

Please note that we are re-designing our replication engine for the next release and we will not have a dependency between older restore points and the backup console.

Thank you.

[MB-NS]

Hello,

it's not clear but from your feedback, should I assume it is no more needed to start a full replication with Veeam v6 ?

Regards,

[Vitaliy S.]

With Veeam v6 this procedure will be performed automatically (assuming that you're using snapshot based restore points). Thanks!

[MB-NS]

Hello Vitaliy,

Do you mean that it will trigger a full automatically, or that it doesn't need a full to keep on replicating ?

[Vitaliy S.]

When you resize source VM virtual disks, all snapshots (restore points) on your VM replica have to be deleted because it is not possible to change virtual disk without affecting the snapshot tree. V6 automatically removes existing restore points and performs a full resync of your VM image.

[MB-NS]

Thanks

is this resync done in place, without consuming additional space ?
If yes, what happens if I have a disaster event during this resync, that requires I do a failover ? will I still be able to failover to the VM ?
In any case I assume it will be considerably longer than an incremental replication, right ?

[foggy]

is this resync done in place, without consuming additional space ?
If yes, what happens if I have a disaster event during this resync, that requires I do a failover ? will I still be able to failover to the VM ?

To avoid such situation, you can create another replication job for this VM and remove the old job and the old replica VM along with its restore points only after a successful run of the new job.

In any case I assume it will be considerably longer than an incremental replication, right ?

Yes, right.