Thursday, April 1, 2010

The semaphore timeout period has expired

I got this error message on my SharePoint farm backup (using the STSADM command
STSADM.EXE -o backup -directory \\srv001\sqlbackups -backupmethod full):

Object SharePoint_Config failed in event OnBackup. For more information, see the error log located in the backup directory. SqlException: Write on "\\srv003\SP_Backup\spbr0001\0000001D.bak" failed: 121(The semaphore timeout period has expired.) BACKUP DATABASE is terminating abnormally.

My first thought was that it conflicted with another backup job, so I moved the start time for the backup several times to see if that helped. Obviously it lost connection to the SQL server. But to move the start time did not help. I googled it but did not find anything helpful and after having analysed the Event Viewer errors and the backup log error, I saw that the error message was displayed almost immediately after the backup had started. And then I realised that maybe it had to do with the time limit for the backup job instead of a timeout against the SQL server. So, I increased the time limit in Scheduled tasks (which runs my bat file) with a couple of hours and then the backup went through without any errors.

Just one of those error messages that are hard to determine the right solution for....


Anonymous said...

beautiful beautiful woman

mekabar said...
This comment has been removed by the author.
mekabar said...

thank you Lise for this information
but i have other way to recover sharepoint database using sql
Restore instructions for SQL-level backups

Use the instructions in this section if you backed up the SharePoint SQL server databases by directly backing up the database files (.MDF, .LDF, and .NDF).

1. Stop all SQL Server, IIS, and SharePoint services.
2. Start the backup manager, go to the Control Panel page, and click the File Manager button.
3. Login to the file manager. Choose to restore all database files (either to their original locations or an alternate location; if you have existing files, we highly recommend choosing to move existing files to an alternate directory during the restore).
4. Also, if you chose to backup the search indexes, be sure to also restore these files at this time as well (to their original locations).
5. Use the SQL Server management tools to re-attach to the restored database files. See our KB article on restoring SQL Server databases for more detailed instructions.
6. Restart all services stopped in step 1.
7. If you chose not to backup the search index, then you must clear your search index and recrawl the content. To do this, open Central Administration, select the appropriate Shared Services Provider (SSP) from the navigation menu, underneath the search header, choose Search Settings. Then click Reset all crawled content and then go to Content sources and crawl schedules, which will allow you to initiate a full crawl.

Note that if you only want to restore certain items from your content databases, then you can restore the .MDF, .LDF, and .NDF files for your content databases to an alternate location and attach them as a different database name in SQL server. You can then create a recovery farm and attach the restored content database to the recovery farm, where you can restore your specific items from there.

comment by mosaab kaabar

Lise said...

Thanks mekabar, for sharing!