Hi, I took the backup through Central Administration. Now I installed MOSS as Server farm installation on 2 different servers.I mean, one is Application server and the second one is the Database server. While Restoring the Backup : I could not connect to the Database server. But if I restore the same backup on a stand alone/Single serverinstallation of MOSS, I could succeed. Hencefor a server farm installation of MOSS on 2 different server, Why I could not connecct to the Database server,while restoring ? Is there any special configuration I need to configure for Database server Access. can anybodytell me, the step by step restore process of a backup through Central Administration for the Server farm installation(2 different servers in the farm.). Error: Object SharePoint - 6789 (previous name: SharePoint - 80) failed in event OnRestore. For more information, see the error log located in the backup directory. SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object SPWebApplication Name=SharePoint - 6789 Parent=SPWebService is being updated by SHOPZONE\agtech_m, in the OWSTIMER process, on machine SPN-PRD-APP3. View the tracing log for more information about the conflict. Object WSS_Content_Changed (previous name: WSS_Content) failed in event OnRestore. For more information, see the error log located in the backup directory. SqlException: Cannot open backup device '\\192.168.18.17\Backup\SharepointBackUp\spbr0000\00000015.bak'. Operating system error 2(The system cannot find the file specified.). RESTORE DATABASE is terminating abnormally.

Hi, This problem usually occurs when the SharePoint restore process is interruptedwhile the process is running. I suggest two solutions to this problem. Restart the WSS timer service and then try to restore the backup If this does not work, then try this Re-runthe SharePoint Products and Technologies Configuration Wizard and then try to run the restore process. Hope this solves the problem

Hi, I've encountered the same problem myself many times and found that restarting the Timer service usually helps. I haven't tried to re-run the Configuration Wizard though. I'll keep it in mind. Thanks!

The Timer Service restart and/or SharePoint Products and Technologies Configuration Wizard re-run did not work for me. In my case, the restore got further when I increased the search crawler frequency (for the Searchdb)andpaused the Shared Service Provider crawls - one was set to 5 mins, the other to 7 mins. The restore never completed without error, but a newerror logged emerged that indicatedI could use the command line STSADM, with'AddContentDB' option, to attach the restored db (which was created in SQL Server). The Sharepoint web application was provisioned successfully during the restore (checked IIS App pool,IIS website, and Inetpub virtuals), but thesubsequent site collection creation failed. The restored db was in SQL Server, so I used that db name (as specified on the original restore page) - "stsadm -o addcontentdb -url http://YourServerNameort -databasename wss_content_YourRestoreNameHere" . Hope that helps someone. Gus.

How exactly do youpause the Shared Service Provider crawls. Were you ever able to do a full backup. This is horrible that Microsoft doesnt document exactly what needs to be done in order to run a full backup. They've always been incomplete with their documentation.

These types of things are why I just use SQL backups :-) Less moving parts and works every time. Additionally, you can't schedule the backups through Central Administration but you can do that with the STSADM commands. The only thing you really get with the SP backups above those in SQL is that it allows you to back up the index. In my opinion, if you have to rebuild an index after a failure that is probably going to be the least of your worries.While I know all of this doesn't solve your problem -- if you need to do a backup fire off a SQL backup in the meantime.I'd guess the reason the backup is failing is that when you run a backup from SP the following IDs all need write access to the directory where you are trying to backup: Account running the backup SQL Service Account Account running the timer service I've had issues if Network Service is the account running any of these 3 IDs. Anyway, just my $.02. I say try the SQL backups and save the headaches.John SharePoint911: SharePoint Consulting Blog: http://www.rossonmoss.com Twitter: JohnRossJr MOSS Explained: An Information Workers Deep Dive into Microsoft Office SharePoint Server 2007

I have seen the same problem, especially when restoring a farm on another server. Giving sufficient NTFS permissions (read/write) to all the accounts I could think of that had anything to do with SharePoint and the accompanying SQL server, didn't solve the problem. Besides, I only get the error with some BAK files, while other BAK files could be accessed without any problem (and the log file could be written without problems), so I think it has nothing to do with NTFS permissions. Restarting the WSS timer service doesn't help either. I have given up and I'm now trying to restore the databases themselves. But, I must say, it is really very annoying and I share the view of hjygyuuyuy: backing up and restoring SharePoint is a disaster!

Backup questions go to the Admin forum. Belatedly moving thisWSS FAQ sites: http://wssv2faq.mindsharp.com and http://wssv3faq.mindsharp.com Total list of WSS 3.0 / MOSS 2007 Books (including foreign language) http://wssv3faq.mindsharp.com/Lists/v3%20WSS%20FAQ/V%20Books.aspx

hi patro, actually restarting the timer service worked for me.. Regards David

hi patro, actually restarting the timer service actually worked for me.. Thanks KhanRegards David