Veeam Unable to Restore Stubbed Files

[ian118]

Hello,

I had a support case ref 5132864.

I was unable to restore some files from my Windows File Server the error we get is "The File cannot be accessed by the system. (Exception from the HRESULT: 0x80070780)".

After alot of investigation this is because Veeam is unable to restore stubbed files. Either via Windows recovery or FLR.

Stubbed files are very common on file servers now where people have introduced archiving especially on Windows servers this is very common place.

The support agent suggested I posted on the forum to see if this was likely to be fixed in a upcoming version? - Or if not could it please be passed to you developers for investigation and hopefully a improvement on a future version.

I think we would not get this issue if Veeam was able to restore directly to original location from the backup file without mounting/copying via the backup server.

TIA

[Gostev]

Hi,

Actually I would disagree with your assessment that "stubbed files are very common" because this is the first time I see this issue being reported in over 3 years.

So, are you saying that stub files is a native functionality of Windows Server? Can you please describe a process of creating such stub files, and how this all works (I did search Google quickly, but could not find anything relevant).

Thanks!

[ian118]

Stubbed files are created via Archiving software of which there are many vendors.

A stubbed file is where a file has been moved to your archive system if it matches policy but a pointer (stubb file/sym link) is left in place so if the user wants to access a file they would open it as normal and it would be retreived.

In terms of restores - the backup software would just copy the stubb file back - but veeam comes up with the error above. Im surprised you have not come accross this before.

[Gostev]

Thank you for clarification. If the stub files are created and maintained by 3rd party software, then it explains why are you seeing this error. In order to support restoring such stubs, our software needs to be "enlightened" to be able to understand stub object format (which is most likely different between various archiving solutions, which as you said there are many exist). We have no plans of implementing such support at this time.

However, what is not clear to me is why are you trying to restore these stub files through Veeam (and not through the software which actually archives them)? Aren't these archiving systems actually intended to archive and restore specific versions of individual files in most efficient manner? Why not use the native capabilities of this file archiving software then?

[ian118]

Gostev,

As for why we might want to restore these from Veeam. A example would be if someone deleted a directory from a file server, that directory might contain normal non stubbed files and archived files potentially 1000's of files. Usually with backup software it would'nt matter the backup software would restore the normal files and the stub files with no issue. Certainly without this error.

Clearly if this was not known its not likely to be "fixed". Can you advise if any more windows filerestore options are likely to be forthcoming in later versions of Veeam i.e direct restore to original location. It may be this will solve the issue with Veeam and stubbed files.

[Gostev]

I am not quite sure future restore types would help. No matter of restore option used, file still needs to be read from backed up image, and written to the destination. If something in this process fails for you today, then I would not hope too see any changes with new restore types (as they would still need to perform the same file level operations).

I think the main issue here is that stub files for your existing archiving solution are using some sort of file system hacks. If the stub file was absolutely regular file, for example with the only content being a link to some repository, then we would process this file normally. May be you should look at other archiving solutions to see if there are some available that work like I explained (using normal files for the stub objects), without any hacks. Obviously we will work transparently with solutions that leverage regular files for stubs.

Hope this helps a bit.

[Gostev]

Another idea, if you archiving solution requires some sort of server (or client) piece install, make sure you install it on Veeam Backup server before trying file level restore. I suspect it may use some file system driver to intercept access to certain files, and re-route reads to fetch file's content from some other place. So with this piece installed, restore may actually work. Although in this case obviously the file will be restored as full file, not as a stub - which is probably not acceptable for you anyway. Oh well, in that case back again to my previous suggestion.

[marine]

This is very upsetting to hear this as we are currently looking to implement some type of archiving solution as well. If some of you sysadmins out there have not looked into transparent archiving solutions then you should certainly do so. It gives you the ability to archive old, stale data (files and email) off your expensive, primary SAN and have them stored on a slower, cheaper SAN or disk array. Everything looks the same to the end user, they can click on an old file/email and it opens just the same as it always did. They are totally unaware that they clicked on an old "stub". So you can set your retention policies and basically have any email/file older than xxx days go to the slower disks. Or immediately archive email attachments etc.

However, now I'm a little worried that Veeam won't be able to restore a folder that contains both regular and "stubbed" files! To the original poster, may I ask what archiving software you are using?

[tsightler]

Have you tried using native tools to copy these "stubs"? If the stubs can normally be copied by regular Windows files tools, then you can just use the regular windows tools to restore them via Veeam, rather than using Veeam's file browser. Perhaps tools like xcopy.

[tsightler]

BTW, as a followup to my own post, these "stubs" are implemented in Windows as NTFS "Reparse Points". These are reasonably documented at http://msdn.microsoft.com/en-us/library ... 85%29.aspx and it appears that Veeam is not really at fault. It appears that the default behavior for a "reparse point" if the filter driver is not installed is to deny access to the file, which is what is happening. Veeam is simply trying to open the file as normal. That being said, it does appear that Veeam could modify their tool to support these without too much trouble.

In the interim, there appear to be precious few tools currently available to manipulate "respase points". The only tool I was able to find that advertised the functionality is the extremely excellent XXCopy (www.xxcopy.com). It shouldn't be fairly simple to simply minimize the Veeam file browser and use XXcopy to perform restores of "stubbed" files.

[cffit]

I know we are 4 years out on this issue, but I had the same problem recently. Our file archiving software uses reparse points and VEEAM doesn't restore them. I couldn't even boot up a VM in instant recovery and get them to copy out. I wasn't able to get xxcopy to work either.

[alanbolte]

The instant-recovered VM's file system will be identical to the original file system at the time of backup because Veeam is an image-level backup. On the instant-recovered VM, you should be able to check the existence of the NTFS reparse points using 'fsutil reparsepoint' queries from the command line. If the archival storage is not a virtual disk that was backed up as part of that VM, perhaps there was a problem with connecting to the storage from the instant-recovered VM.

[singy2002]

Hi,
I am implementing Veeam for a customer who uses a third party archiving solution which leaves a stub file in its place, when trying to restore the file or folder containing the stub file (as well as normal files), Veeam kicks up an error "the file cannot be accessed by the system"

I have tried restore/copy to, neither work, same result when browsing from c:\veeamflr

I have found one old forum post relating to this sort of thing from 2011 but wondered if anyone was aware of a workaround.

http://forums.veeam.com/veeam-backup-re ... t7601.html

i am not requiring the actual file to be restored just the stub - which will allow the users to then recover from the archive solution.

Regards
Andy

[singy2002]

My post has been merged here but this doesn't offer any solution or even confirm if it is or is not support?

[Vitaliy S.]

Files that cannot be restored via native capabilities should be skipped, and the entire process should continue the process. Can you open a support case and let our team look through the logs?

[PariPari]

Hi,

what archiving software are you using? Is the item still in the archive? If yes, just recreate the stubfile with the archiving utilitys.
I had the same problem with a Fileserver archiving Solution. The User deleted the a whole folder with several archived an non-archived files in it. We restored every non-archived file with Veeam and recreated the shortcuts for the archived files from the archive.

Though, it would be nice if Veeam could just restore the stubfiles without questions

[subchris]

Has this been resolved yet? I understand that the archiving utility can restore these file stubs/placeholders, but other backup solutions are able to backup the files and restore them as well. Also, when attempting to restore a directory that has live files as well as these stubs, the whole restore fails. Why won't it just skip the errors and keep going?
Veeam seems to want to recall the files from the archive to allow the restore to complete. If I installed the service to allow that on the Veeam server, I am sure that would solve the issue. But, that defeats the purpose. I would rather it just restore the files as offline files as our previous solution did when it was a physical server.

[Helferlein]

This thread is already quite old, but currently I have the same problem now with our new Archiving Solution from Metalogix.

Just tried to restore a folder with archived files and got the error:

Win32 error:The file cannot be accessed by the system.
Code: 1920

Is there still no solution that those stub files may be restored?
Any news about that?

[LucHeinz]

I moved our Backup from Microfocus Data Protector to Veeam. Since then I have the same Problem.
We use Archive Manager for Files 8.0 (Quest /Metalogix) to archive files and never had problem restoring stubfiles with Data Protector.
When can we expect a Solution from Veeam?