VMware Cloud Community
tomtux
Contributor
Contributor

Failed to create snapshot for XXXX, error -3902 ( file access error)

Hi all,

We're using VDR 1.0.2. Often I get the the following error until I reboot the vdr-appliance:

Failed to create snapshot for XXXX, error -3902 ( file access error)

When I get this error-message, I although can create a snapshot manually. We' re using a CIFS-Share for our vdr-backup-destination.

Any hints?

Thanks a lot.

Tom

0 Kudos
20 Replies
joep_leurs
Contributor
Contributor

same problem here.

a CIFS share on a windows 2008 x64 server.

any help appreciated.

0 Kudos
admin
Immortal
Immortal

Restart the VDR appliance - for some reason, it lost connection to the vCenter Server

0 Kudos
ian4563
Enthusiast
Enthusiast

Yeah, same problem for me. When I reboot it fixes the problem for a bit but my backup job is gone after reboot. Have to go recreate my job.

0 Kudos
kohlerma
Contributor
Contributor

Same problem for me,

After rebooting the vdr-appliance the backup works. But after a while (hours) a regular job or manual backup fails again.

Configuration:

VDR-appliance (1.0.2) and servers to backup are on a ESXi 4.0.0.181792

CIFS share for backups are on a Synology NAS in the same LAN

ESXi and VDR are connected to a VirtualCenter over a WAN (MPLS) connection

I have another VDR-appliance on a ESX 4 connected to the VirtualCenter (all in the same LAN) where I also do backups on a CIFs share. Here I don't have this problem.

any help appreciated

0 Kudos
helloitsrainn
Contributor
Contributor

This issue still exists. After a few days of use the VDR Appliance just stops working. After a reboot, if you're lucky, your VMs are still backed up and can continue being backed up. But after I rebooted, my backup job is gone, my destinations are gone and my backups are unusable. I've had to start all over again.

0 Kudos
admin
Immortal
Immortal

What are you using as a destination (VMDK or CIFS share). Without the destination disk discovered and mounted, you cannot see the backup jobs and restore points. If VMDK, if you were to look under Hosts and Clusters and edit settings on the VM, does the VMDK still show up? When you reboot, are there any errors about not being able to mount?

If CIFS share, you may have to reattach via the Configuration/Destinations/Add Network Share link.

0 Kudos
qvantas77
Contributor
Contributor

Azmir, Is there another release of VDR in near future?

Regards

Johan

0 Kudos
helloitsrainn
Contributor
Contributor

Hi,

Yes, I understand that backup destinations must be available. VDR had been running fine for a few weeks before this happened.

From all the problems I've been hearing throughout my VMUG and on these message boards, I would not say VDR is production ready. Just last week, I changed the VDR VM to use 4GB of memory instead of 2GB and it crashed.

Otherwise, the product is great, it just has some more wrinkles to iron out.

0 Kudos
AlbertWT
Virtuoso
Virtuoso

Yes, I agree with you man, the current version of VDR v 1.0.2.562 is still troublesome 😐

I often get the failed backup error message of Create Snapshot failed error -3941

Kind Regards,

AWT

/* Please feel free to provide any comments or input you may have. */
0 Kudos
blautens
Contributor
Contributor

I'm using the same version of VDR, and I was not able to backup my Windows Server 2008R2 VMs, with a fairly generic error:

Failed to create snapshot for VMNAME, error -1 ( unknown).

I was backing up to a CIFS share, so I added a disk to the VDR appliance that was a LUN on my FC attached SAN. Same issue. So I read I had to uninstall VMWare Tools and do a custom install and not use the VSS driver. So I did that for both my 2008R2 VMs, and now I get this error:

Failed to create snapshot for VMNAME, error -3941 ( create snapshot failed)

And yes, every once in a while I have to reboot my VDR. But I rebooted my VDR after removing the VSS drivers and I still get this error.

So yes, VDR still has issues...which is too bad - because when it works, it works well. My VAR sold us an Acronis Enterprise suite that was supposed to do backup (as well as P2V, etc.), but ironically, the latest version of Acronis doesn't work with vSphere (only took Acronis 3 days to figure that out), but vConverter and VDR could make me forget about Acronis issues, with just a little more reliability out of VDR. Especially since the new file level restore GUI debuted.

Keep up the good work, VMWare....you're almost there!

MCSE, VCP4
0 Kudos
czscht
Enthusiast
Enthusiast

Hi,

I was looking for help for the same issue, seems none is there ? I am using vDR in version 1.0.1.362, using 2 vDR appliances backup (or trying to) at 2 sites. One vDR is using a CIFS share as a destination, the other an iSCSI-target mounted as "disk2" into the vDR itself.

After the initial inistallation it worked fine for 3 days, then both vDRs stopped working with this error -3902. I had to reboot the vDRs, delete and reformat the backup destinations, remove the nackup jobs and basically start from scratch. This made it work for 1 time, the next night the backup job ended with error -3902 again.

Integrity checks on both backup destinations are OK.

Since I am using an outdated version of the vDR I hopen 1.0.2 is better, but according to the other postings, it seems as bad as the 1.0.1 release.

I am also having troubles with vCenter (clicking on "Performance" of a host in vCenter leaves the vSphere client not responding - hourglass forever) I did use the vDR through a direct connection from vSphere client to the 2 host, but that did not change a thing.

Any ideas ?

Regs,

Thomas

0 Kudos
AlbertWT
Virtuoso
Virtuoso

Hi there,

Sadly at the moment those errors are still happening in v1.0.2

up to this point, I no longer interested in this product anymore Smiley Sad and now trialling various 3rd party backup tools which performs better dedupe backup and replication using vStorage API.

Kind Regards,

AWT

/* Please feel free to provide any comments or input you may have. */
0 Kudos
admin
Immortal
Immortal

VDR 1.1 is available now and addresses the -3902 issues with vcenter Server disconnects/reconnects

http://downloads.vmware.com/d/details/datarecovery11/ZHcqYmQlcHBiZGUlcA==

More information on in the forums about what else is in the release.

0 Kudos
AlbertWT
Virtuoso
Virtuoso

Great, downloading VDR v1.1 and trialling it now.

Cheers.

Kind Regards,

AWT

/* Please feel free to provide any comments or input you may have. */
0 Kudos
tomtux
Contributor
Contributor

I will try it too.....

0 Kudos
swany7
Contributor
Contributor

Where did you find the information that indicates this addresses the -3902 issues? I do not see anything about this in the release notes?

0 Kudos
pym
Contributor
Contributor

The VDR log states that VDR is at v1.1.0.707. Yet the plug-ins page tells me that I am running 1.1.0.27.

I guess it doesn't really matter since I am still getting the "Failed to create snapshot for XXXX, error -3902 ( file access error)" fairly consistently on 3 of my 8 servers over the last 2 weeks; one manage to get done once 10 days ago. another one got done yesterday and the MS-WSUS server never got done yet, despite numerous reboots of VDR.

0 Kudos
blautens
Contributor
Contributor

Dohh! Stupid vacation autoreply - sorry.

MCSE, VCP4
0 Kudos
admin
Immortal
Immortal

You should open up an SR. The -3902 error is effectively a communication error between the VDR appliance and the vCenter Server instance being dropped - in effect, a networking issue. In VDR 1.0.2, a reboot would fix it. In VDR 1.1, if you are still having issues, then you a still having networking problems as described above.

Some things to look at

1) Firewall and ACLs:

VDR uses TCP port 443 on the VC Server by default (or whatever port you have set vCenter Server to use for https). Make sure that this port isn't getting blocked

VDR uses TCP port 902 to communicate to the ESX hosts running the VMs being protected. oMake sure that this port isn't getting blocked

2) How is the VDR appliance connected to the vCenter Server and more importantly the 5 ESX (you mention servers, so assume servers = ESX hosts) hosts that are having -3902 issues? One quick test is to vMotion the VDR appliance to one of the failing ESX hosts and see if the 3902 errors still crop up after a few days.

0 Kudos