Invalid snapshot only on replication

[leduke]

Hello !

I've got a problem with only one VM with my replication job. I got an error: "invalid snapshot configuration". First I had an stange snapshot on this VM, but I corrected the problem, but I've still got the problem on the replication Job. I don't understand why my backup job run fine on the same VM... Do you think that the problem is not on the source machine but one the target machine ?

Thank you.

[Vitaliy S.]

Hi Alex,

Most likely it is source VM that causes this issue. Can you please tell me if you've run the replication job after fixing the issue with snapshots on the source VM? Just want to make sure that invalid VM configuration wasn't replicated to the target host.

Thanks!

[leduke]

When the VM got an invalid snapshot, the backup was ok, but not the replication. I correct the problem, but the replication job was created before the problem was fixed. i think the invalid configuration was repicated onthe target VM. I think I have to recreate the replication job and delete the corrupted target VM, no ?

[Vitaliy S.]

Yes, I would probably do the same.

[leduke]

The problem is partialy fixed. I deleted the replication VM, recreate a new job. The snapshot config is now good and the job is running.

But, I have another problem.... I don't understand. Since the firts repliation of this VM, I have delete a hard drive on the source VM. My replication failed becaus the G:\ drive was not found... I created a new job, why veeam backup want to replicate a Drive that is no longer present on the VM ?

Thank you.

[foggy]

Alex, how have you deleted that drive from the source VM?

[leduke]

Alex, how have you deleted that drive from the source VM?

Yes ! I have delte it before de snapshot error was fixed and before the replication job re-created

[foggy]

I mean how have you done that? Have you edited the VM properties and removed the disk? How do you determine that the disk is replicated?

[leduke]

I modify the VM properties and deleted de virtual disk. Now I have recreate a new job for this VM, and deleted the old replication VM. So, vDisk deleted on the virtual, brand new job created, brand new target, I don't unserstand how the veeam backup know that they were a G:\ drive connected in the past... where did he get this information ?

[Vitaliy S.]

Veeam is relying on the VM configuration file (VMX) to find all attached virtual disks. I would recommend to take a look at this file more closely, if you need any assistance with this please contact our support team directly. Thanks!

[leduke]

When I create the replication job, I selected all disk, I will try to do the replication with only 3 disks selected and not all (even if there is only 3 disk).

[veremin]

Hi, Alex. As Vitaliy has said already, it definitely stands to reason to review and correct, if need be, .vmx configuration file, since all the information about attached disks is taken by VB&R from it.

Hope this helps.
Thanks.

[leduke]

My vmx file seems to be ok... But My message error is not only on the hard disk, but on the folder drive letter, this is the original message:

Code: Select all

The system cannot find the path specified. CreateDirectory(G:\DBBackups) function call failed. Cannot create folder. Folder path: [G:\DBBackups]. Cannot create folder. Folder path: [G:\DBBackups\Replicas]. Cannot create folder. Folder path: [G:\DBBackups\Replicas\vm-1392]. --tr:FC: Failed to create directory. Directory path: [G:\DBBackups\Replicas\vm-1392]. --tr:Failed to call DoRpc. CmdName: [FcCreateDir] inParam: [<InputArguments><DirName value="G:\DBBackups\Replicas\vm-1392" />

This G:\ drive (the virtual hard disk) was deleted last week....

I don't mind it's a vmx mistake...

[veremin]

There must be a misunderstanding, since the error that can be seen in the posted log is related completely to the repository where replicas metadata is stored and not to the replicated VM.

It just a coincidence that both (repository and deleted disk) are located under the G:\ letter.

Hope this helps.
Thanks.

[leduke]

So it is a metadata were the old job's information was stored ? Where the metadata is stored, on the database or in the repository ? Can I clear it ?

[veremin]

VB&R uses replica metadata to quickly detect changed blocks of data between two replica states. These files are stored in selected repository and can be found under the “replicas” folder. As I can see from the posted log, in your case it’s G:\DBBackups\Replicas. They can be manually deleted without any impact or whatever.

However, I don’t think it would solve your issue, since the error you get is completely related to some repository problem, having nothing to do with the G:\ drive being deleted from the given VM.

Furthermore, I'm wondering whether your repository where replica-metadata is stored is mapped drive by a chance.

Hope this helps.
Thanks.

[leduke]

Furthermore, I'm wondering whether your repository where replica-metadata is stored is mapped drive by a chance.

Hope this helps.
Thanks.

Yes ! This drive was a backup drive, but it also was my old repository (used during a small period, before bying a new network Drive).

[veremin]

As mentioned in the provided topic, if you’re using mapped drive as a backup repository and see the said error, you should try to run a job under the service that creates the mapped drive, or you can use psexec to create a mapped drive within the system context.

Otherwise, If you don’t use G:\ drive as a repository any longer, then, go to the replication job settings and specify existing repository as a place where replica metadata should be stored.

Hope this helps.
Thanks.

[leduke]

The repository in the new replication job has been set to the new repository (Qnap Network drive).

[veremin]

I'm still wondering whether the creation of new replication job along with new repository specification has finally solved your issue.

If it hasn’t, then, please, open a ticket with our support team and let them investigate this issue directly.

Thanks.

[leduke]

The Veeam server and all the vmware infrastructure have been rebooted (power shutdown), and now the replication job is now OK.

Don't understand why..........