Robocopy and corrupt files

[Ariel]

Hey, we are using Veeam to create reverse backups of servers, and we want to send the vbk's to an offsite drive. We have a virtual Veeam server, which backs up to an iSCSI drive, which is then also mapped to our physical backup server which contains our offsite drives, which then attempts to robocopy all the files (for now, we'll whittle it down to just the vbk's eventually) from the iSCSI drive to a local disk. However a large portion of the files (vbks, vrbs, some vibs) cause robocopy to throw the following error:

ERROR 1392 (0x00000570) Copying File H:\DENON\DENON-F2011-09-27T220047.vrb
The file or directory is corrupted and unreadable.

Then later when I tried to use grsync from the same location, and it threw the error "file has vanished"

So is Veeam pumping out broken files, or is robocopy somehow messing them up when it tries to copy them?

[Gostev]

Sounds like some bad issues with the storage you are writing backups to. What is your "iSCSI drive", is that possibly some low-end NAS?

[antspants77]

If you have Surebackup running this will lock the files.
We had the Surebackups kept running, so that Exchange Restores would be quicker, but ran into this issue.
Also an issue with Synthetics when SureBackup is running.

[Ariel]

Gostev, we're using a Qnap box... you think this is causing issues?

[Vitaliy S.]

Yes, could be. I recall that our existing users complained about pretty bad iSCSI implementation on QNAP.
There are some existing topics about this > http://forums.veeam.com/search.php?keywords=QNAP+iscsi

[Gostev]

I actually sent my QNAP back because of that. But the sad truth is, I am yet to find low-end NAS with reliable and performant iSCSI implementation.

[Ariel]

so what would be a proper option to replace this? should we use a network drive? can we use the qnap as a network drive instead of as an iscsi drive or do you recommend against it entirely? thank, and sorry if this is covered elsewhere...

[Vitaliy S.]

Given the issues you describe above, I would suggest going with CIFS/NFS.

For more details please look through this topic that highlights all pros and cons of using different backup targets: recommendations for veeam backup storage

[Ariel]

hmm, also just to throw into the mix which I had forgotten about, when using our Dell Equallogic SAN, the same corruption issues arose.

[tsightler]

Any chance there's some antivirus software running that is doing something behind the scenes. Veeam just creates regular files, there's nothing really special about them. Many users copy them off nightly or replicate them so if you're having issues just copying files around, that's pretty strange. Even if the file itself was somehow "corrupt" internally, you would still be able to copy it. Only if Veeam was actually corrupting the filesystem would it be able to cause such an error, and since Veeam simply reads/writes files via normal Windows API it would seem impossible to corrupt the filesystem.

[Ariel]

hmm, we have Trend Micro Worry Free Business A/V running, do you think we should try running after disabling it?

[Vitaliy S.]

Oh, definitely or you should at least add backup files into exception list.

Recently we had another problem reported where Trend Micro was involved: BSOD STOP: 0x0000003B SYSTEM_SERVICE_EXCEPTION

Good catch, Tom!

[Gostev]

Yep, by all means, please exclude all backup files from the scope of antivirus.

[tsightler]

Yes, I suspect it may be tripping a virus definition or some other behavior and the A/V is blocking access to the file. Just a suspicion at this point but I would suggest disabling A/V to test for sure.

[jsprinkleisg]

...We have a virtual Veeam server, which backs up to an iSCSI drive, which is then also mapped to our physical backup server...

Wait - kinda sounds like you have an iSCSI LUN mapped to two different servers simultaneously? If that's the case, that could definitely cause corruption problems.

[tsightler]

Certainly true. I guess I assumed he meant mapped as in "mapped drive". If your mapping an NTFS formatted iSCSI LUN to more than a single host, that's a path to certain corruption.

[Gostev]

I actually sent my QNAP back because of that. But the sad truth is, I am yet to find low-end NAS with reliable and performant iSCSI implementation.

Back from VMworld with brand new Drobo B800i. Planning to put it through some good testing in my lab with v6, and will report back. Folks from Drobo are claiming their focus is providing fast and reliable production and backup storage (without tons of fluff features), which sounds like exactly what I need. Will see what they've got and how well it works.

[Ariel]

Wait - kinda sounds like you have an iSCSI LUN mapped to two different servers simultaneously? If that's the case, that could definitely cause corruption problems.

you think so? I just jumped back on here to say that disabling AV did not help. How would you recommend we access that drive? Map to it like \\veeamServer\iscsiDrive?

[Gostev]

He means you should not attach the same LUN via iSCSI initiator to two Windows servers at once, which is very valid suggestion. Attach it via iSCSI to backup server, and from other servers access it via a CIFS share.