Are those separate farms?  How were they created?  There are too many missing pieces of information to give you a definitive response.  The error message you are quoting normally comes up when you take a branch of a web application (like a specific site collection) and try to restore it to a different branch in the same content database, but not over top of the existing branch.  So if the backup is from http://test.domain.com in content database db1 you couldn't restore it to http://test.domain.com/sites/test in content db1.

Hi, there are some problem with our UAT environment. So have backed up live and UAT and attempted to do a restore from within Central Admin. It is saying cannot restore because already exists. What do you have to do before restoring? Do you have to empty the contents of the database? Does this means keeps the tables and emptying them or droping them completely? Am using the new configuration option by the way,

Thanks.

If you are backing up the whole environment then you need to restore overtop of the existing environment.  If you are backing up specific site collections then you need to make sure you are restoring to a different content database.  if you restore to the same content database then you will get the error you describe because the GUID of the restored site will be the same as an existing site.  The easiest way to do it is to either restore to a completely separate lab environment for testing or at least create a new Web Application (which would create a new content database) to prevent the conflict.

Thanks. I dont think we need to restore content, just everything else. So is it possible to simply uncheck the content part during the restore process? Are the GUIDs only related to content?

If I leave out the content restore part, will the restore process simply overwrite all the other stuff without prompting that it already exists?

I'm not entirely sure what will happen in that event.  I suspect you will end up with a restored system with no content.  You would still need to restore to the same location or you will run into the GUID issue you are getting now.

When you say "same location" what do you mean by this? Same location as what? I am attempting tp restore from the physical live to the pyhysical UAT.

Hi,

yea they are separate farms. One for live and one for UAT. They use different URLs. By the way we do need the content I just found out. Isnt this restore option from central admin supposed to recoved a sharepoint environment to a new clean Sharepoint environment? Its like the enironment we are trying to restore to has stuff on it so it doesnt like it, it is not a brand new black Sharepoint environment. If this is the case how do we get a blacnk environment from the existing UAT?

The problem is that the UAT is messed up. Cannot publish web parts. We want to use the working live version to copy and get UAT working. Is this possible? When using Central Admin it gives you the option to use a new configuration file, so we though you could use the UAT settings in this?#

If this is not possible how can you get a copy of the live working version and use it as UAT on a separate farm?
Thanks a lot!

Was the UAT environment originally built from a backup of Production?  That's fairly common.  If it was then that's why you are getting the errors you are getting.  If so you will probably need to delete all the site collections and web apps in UAT and install on top of the bare farm.  Otherwise you will keep getting the conflicts you are seeing.  If UAT was built as a clean environment and not a backup then I can't explain why you are getting errors.  Other than to say that restoring a backup isn't a particularly reliable way to clean up a messed up system.

Hi Damon2012,

I too had the exact same issue a few weeks back also! I was asked to take a back up of a SP 2010 environment to then restore as the new UAT environment - which ment overwriting the existing UAT environment.

After tons of youtubing I found these steps helped me alot and just in case their any different to yours thought i'd share them with you - as they helped me!

• Logon to the SQL Server instance which hosts the content database of the web application that is created on the Production Environment.
• Make a backup of the content database and copy the .bak file to the SQL Server instance that hosts the content database of the acceptance environment.
• Logon to the SharePoint application server and fire up the Central Administration webpage.
• Go to Manage Content Databases and select the web application that needs to be updated with the latest content.
• Click on the content database and check the Remove Content Database and Press OK
  (You will be ask if youre sure about this action, press Continue/OK)
• Go the the SQL Server instance of the acceptance environment and if its not deleted, delete the content database from SQL.
• Restore the database which youve copied over from the production environment and assign the permissions which were granted to the previous database (FarmAdmin account needs DBO rights, as the application pool accounts needs access to the Database).
• Once youve successfully restored the database go back to youre acceptance SharePoint Server and open SharePoint PowerShell. Type in the following command:

PS C:\> mount-spcontentdatabase "WSS_Content_Portal" -DatabaseServer SQL01\DB01 -webapplication http://[the name of your web application]

If the mount action went fine, you should be able to look in the Central Administration console to see if the database is correctly mounted and without errors.

*It may also be worth checking, if the database needs an upgrade by going to Upgrade and Migration and then Review Database status - as this caused an issue twice for me before

Hope this helps - I owe the information to Wesley Niels (from what i gather from the video)

-TechieMark