{"id":530,"date":"2009-06-29T22:54:00","date_gmt":"2009-06-29T22:54:00","guid":{"rendered":"https:\/\/brainlitter.itgroove.net\/2009\/06\/29\/sharepoint-site-collections-read-only-during-stsadm-scheduled-backups\/"},"modified":"2009-06-29T22:54:00","modified_gmt":"2009-06-29T22:54:00","slug":"sharepoint-site-collections-read-only-during-stsadm-scheduled-backups","status":"publish","type":"post","link":"https:\/\/regroove.ca\/brainlitter\/2009\/06\/29\/sharepoint-site-collections-read-only-during-stsadm-scheduled-backups\/","title":{"rendered":"SharePoint Site Collections Read Only during STSADM Scheduled Backups"},"content":{"rendered":"
\n

This was an interesting discovery, as I try not to work after 10pm (when my automated, scripted Site Collections are due to run). <\/p>\n

\u00a0<\/p>\n

When I tried to save a document to a document library, I was greeted with the following two issues: <\/p>\n

\u00a0<\/p>\n

When saving to a document library, I got… <\/h2>\n

\"\" <\/p>\n

You do not have the correct permissions. Contact the server administrator. <\/em><\/span><\/p>\n

\u00a0<\/p>\n

And when trying to add a new item to a list, I got… <\/h2>\n

\"\" <\/p>\n

Error: Access Denied <\/em><\/span><\/p>\n

\u00a0<\/p>\n

That’s what I get for trying to be extra efficient with my current workload. Time to go to bed, like a normal human … helps with the grumpies in the morning as well. Oh right, you are waiting for the answer\/solution. Ok, here it goes… <\/p>\n

\u00a0<\/p>\n

SP2 for SharePoint, modifies the default behaviour of STSADM backups <\/h1>\n

\u00a0<\/p>\n

I have a nightly scheduled Site Collection Backup script that runs at 10pm – I don’t have a huge Site Collection\/Content Database and I like the extra security and flexibility I get regarding recovery of a full Site Collection. It’s been humming away for 2+ years and I’ve never had a problem … until now. With the release of SP2, the ‘SetSiteLock’ option is now on by default. Prior to SP2, it was an option\/flag you set as a best practice (I didn’t, I forgot, didn’t care at the time, I don’t remember…). But now, it is on by default. Which means my Site Collection is read only during this operation. <\/p>\n

\u00a0<\/p>\n

In my case, I’m perfectly happy with that. And I’m too lazy to go back to my script and add in the necessary ‘NoSiteLock’ switch (what can I say, I like the idea of the best practice being forced\/bestowed upon me – if it bothers me in the future, maybe I’ll change it). <\/p>\n

\u00a0<\/p>\n

Full details of the issue can be found here: http:\/\/technet.microsoft.com\/en-us\/library\/cc287967.aspx<\/a> and specifically, the interesting notes\/passages are the following: <\/p>\n

\u00a0<\/p>\n

\n\n\n\n\n\n
\n

\"\"Note: <\/strong><\/span><\/p>\n<\/td>\n<\/tr>\n

\n

The force<\/strong> and nositelock<\/strong> parameters were first introduced in Windows SharePoint Services 3.0 with Service Pack 2 (SP2).<\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

\u00a0<\/p>\n

and… <\/em><\/p>\n

\u00a0<\/p>\n

\n\n\n\n\n\n
\n

\"\"Important: <\/strong><\/span><\/p>\n<\/td>\n<\/tr>\n

\n

If changes are made to the site collection during the backup process, the backup can become corrupted. Backing up large site collections can take a long time. To reduce the chance that user activity will interfere with a site collection backup, or that the time that is required to back up large site collections will exceed the available maintenance window, follow these recommendations: <\/span><\/p>\n