SharePoint restore from Client server

[CadenL]

Hi

I have a single SharePoint Server running SP2013 which hosts all the roles on the same server. eg Web Server, SQL server and App server are all installed on the same server.

I've followed through with all the permissions and requirements for GRT backups and restores and have successfully backed up the SharePoint server with both a VMware policy type (with the SharePoint GRT option selected) and also done backups with the MS SharePoint backup type selected and the GRT tickbox selected.

I can do GRT restores from both the VMware backups and the agent based backups when I start the restore from the Master server (which is a NetBackup Appliance) but when I try a restore from the SharePoint client I can only successfully restore individual files when I use an agent based backup - If I select one of the VMware based backups I can't expand the restore selection to see the individual files - I can only drill down as far as the database. I this a restriction or is there something wrong? Should I be able to restore files from VMware based backups from the client BAR or can this only be done from the master server?

When I try to drill down through the database I can see a 'restore' starting in Activity Monitor - which I assume is the mount of the database - and this completes with a status 0 but I don't see anything more in the BAR on the client.... no files appear for me to select for restore.

I've got the NFS client service installed and all the permissions correct - it all works for the agent based backups when I do this on the client, it's just VMware GRT restores on the client that's not working - I can do VMware GRT restores fine from the master server.

thanks in advance for any thoughts

[Michal_Mikulik1]

Hello,

I have the same problem. I have VMware policy with Enable Sharepoint attribute checked. The backup is saved on primary MSDP server first, then it is AIR replicated to another MSDP server in another NBU domain .

When I browse Sharepoint backups in primary NBU domain then I am able to browse down to file level as expected.

When I browse them in the second NBU domain, it behaves as you describe - I can browse only to database level.

So the problem looks to be server related, not client - I have tried to reinstall NFS on secondary MSDP but no change yet.

It is 8.1.1 version everywhere and client trust both Masters via certificates.

So currently no idea where the problem is.

Michal

[CadenL]

Thanks for letting me know - if I get anywhere myself I'll post my findings.

However, I have discovered that what I thought I was seeing was incorrect. I thought that from the master server I could browse the VMware backups to file level and only database level when I do it from the client. It turns out that I was in fact browsing the agent based backup when I thought it was the vmware type backup. 

It turns out I can't browse to file level from the vmware based backup from either the master server or the client but can do both using the sgent based backup - so at least the master and client are behaving the same and therefore more likely to be something to do with the cataloging. I don't have AIR configured yet and so can't comment on if I see the same as you - but I am now testing with a different master server to see if that's the same. I believe my issue will be related to ASC catalog job and making sure I browsing the correct client to see the catalog info - however I do only have one server in my SharePoint farm so I don't know how I can get that wrong - I suspect it will all come down to name resolution as it always does with NetBackup 

[Michal_Mikulik1]

Hello,

behaviour of the traditional Sharepoint agent, and the VMware/Sharepoint based agent is different.

With traditional Sharepoint agent, GRT info is catalogued during backups, thus GRT browsing of these images is very fast.

During VMware/Sharepoint backups, only info up to database level is catalogued with ASC. File-level info is not catalogued and is created on demand during browsing (it is called sometimes as "live browse"). Thus there are long running Restore jobs which takes care of this process. So it should be some communication error, or a NFS error if this does not work, not cataloging error.

Regards

[Lowell_Palecek]

@CadenL, what version is your Windows, and do you have your data volumes on mount points?

[CadenL]

Hi Lowell

No I'm not using mount points just drive letters.

The Windows version is Windows 2012 R2

many thanks