Backup-SPSite may cause Content db read only

Feb 2, 2012 at 6:58 PM

Hi,

I found a potential issue with the Backup of site when something happen wrong. The cmdlet Backup-spsite used without the parameter -NoSiteLock the DB may remains in read only if the operation isn't completed properly. Of cource the best practices says that "If users are writing to the site collection while the site collection is being backed up, then the NoSiteLock parameter is not recommended for potential impact to backup integrity" Then maybe it could be a good idea to look at the db status and make sure if the db wasn't in read only mode that this last want will not be remains stuck in read only.

Coordinator
Feb 3, 2012 at 2:58 PM
Edited Feb 8, 2012 at 8:52 AM

Hey,

As always thank you for the feedback.

Regarding the suggestion of the "Sanity Check" to ensure the DB is not set to read only, I think you are confusing the Backup-SPSite cmdlet slightly.

The Backup-SPSite cmdlet doesn't set the DB to Read-Only. It sets the site collection to 'Locked' during the backup unless the -NoSiteLock is stipulated. If the -NoSiteLock is set then the site collection remains readable and writeable during the backup. As you correctly point out, this is not recommended, hence the reason I have not set it in the script.

What the Backup-SPSite cmdlet does is record the original site collection lock state so that it is restored to that state once the backup has completed.

I could have used the UseSqlSnapShot option which is recommended if running Enterprise Edition of Microsoft SQL Server.

Leave it with me ........

Darren

Feb 3, 2012 at 3:07 PM
Hi,

After a discussion with Microsoft (of course they charge us 500$/h for that) they explained that it is possible that the collection remains locked after a backup operation with Backup-SPSite cmdlet... it happened in my side causing access denied. Well Ms knows this issue but seems not having planned fix for this issue soon.

for the script you send me for the NAS access it worked fine. I suppose it could be an idea to integrate it into the main script maybe with a variable in the config file.

best regards

Patrice Genest
Sharepoint Administrator
Cross Platform Services (Direct report to Eric Phenix)

Account: Pratt & Whitney Canada (UTC)
1000, Boul. Marie-Victorin (01DC5) | Longueuil, Quebec | J4G 1A1
t. +1.450.677.9411 73273 | m. +1.514.603.8013 | f +1.450.647.9205
pgenest@csc.com |
www.csc.com

Ce message est CONFIDENTIEL. Si vous n'en êtes pas le destinataire, veuillez le supprimer sans en faire de copies et prévenir l'expéditeur par messagerie électronique qu'il n'a pas été acheminé à la destination voulue. NOTA: Quel que soit le contenu du message, il ne lie CSC à aucune commande ni à aucun contrat à moins que la commande ou le contrat fasse suite à une entente écrite ou à une initiative gouvernementale explicite prévoyant expressément l'utilisation de la messagerie électronique à cette fin^CSC • This is a PRIVATE message • If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the delivery error. NOTE-Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose • Les sciences de l'informatique Canada Inc • Computer Sciences Canada Inc.




From: "marsdendd" <notifications@codeplex.com>
To: Patrice Genest/CAN/SC/CSC@CSC
Date: 2012-02-03 09:44 AM
Subject: Re: Backup-SPSite may cause Content db read only [spfarmbackup:290752]




From: marsdendd

Hey,

As always thank you for the feedback.

Regarding the suggestion of the "Sanity Check" to ensure the DB is not set to read only, I think you are confusing the Backup-SPSite cmdlet slightly.

The Backup-SPSite cmdlet doesn't set the DB to Read-Only. It sets the site collection to Read-Only during the backup unless the -NoSiteLock is stipulated. If the -NoSiteLock is set then the site collection remains readable and writeable during the backup. As you correctly point out, this is not recommended, hence the reason I have not set it in the script.

What the Backup-SPSite cmdlet does is record the original site collection lock state so that it is restored to that state once the backup has completed.

I agree that checking the LockState of the site collection before executing the backup and ensuring the Lockstate is returned to that state irrespective of whether the backup was successful or not is a valid suggestion and I will look at implementing this.

Darren

Read the full discussion online.

To add a post to this discussion, reply to this email (spfarmbackup@discussions.codeplex.com)

To start a new discussion for this project, email spfarmbackup@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Coordinator
Feb 3, 2012 at 3:34 PM

 

Great that the NAS fix worked. Have already included that in the next release. It was as i thought, issue with WMI.

Regarding the site lock issue. Come across it a couple of times and even worse, i've seen it where the Site collection shows as Unlocked and still remains locked. That has me scratching my head I can tell you.

I think on reflection I will look at the UseSqlSnapShot.

Darren

Alors, Bon Weekend.

Feb 3, 2012 at 3:43 PM
hi,

using UseSqlSnapShot is mentioned as a best pratice by Ms... but it will works only for Sql server enterprise I thing.
Maybe it should be an idea to provide both option.
Without the SQLSnapShop mybe just changing the state to nolock in the catch and finalyze part should be fine.
Ms said that there is no problem to reapply the nolock on a sitecollection already in nolock. Then in that case we can ensure that the state is ok whatever the circumstances.


Patrice Genest
Sharepoint Administrator
Cross Platform Services (Direct report to Eric Phenix)

Account: Pratt & Whitney Canada (UTC)
1000, Boul. Marie-Victorin (01DC5) | Longueuil, Quebec | J4G 1A1
t. +1.450.677.9411 73273 | m. +1.514.603.8013 | f +1.450.647.9205
pgenest@csc.com |
www.csc.com

Ce message est CONFIDENTIEL. Si vous n'en êtes pas le destinataire, veuillez le supprimer sans en faire de copies et prévenir l'expéditeur par messagerie électronique qu'il n'a pas été acheminé à la destination voulue. NOTA: Quel que soit le contenu du message, il ne lie CSC à aucune commande ni à aucun contrat à moins que la commande ou le contrat fasse suite à une entente écrite ou à une initiative gouvernementale explicite prévoyant expressément l'utilisation de la messagerie électronique à cette fin^CSC • This is a PRIVATE message • If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the delivery error. NOTE-Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose • Les sciences de l'informatique Canada Inc • Computer Sciences Canada Inc.




From: "marsdendd" <notifications@codeplex.com>
To: Patrice Genest/CAN/SC/CSC@CSC
Date: 2012-02-03 10:34 AM
Subject: Re: Backup-SPSite may cause Content db read only [spfarmbackup:290752]




From: marsdendd

Great that the NAS fix worked. Have already included that in the next release. It was as i thought, issue with WMI.

Regarding the site lock issue. Come across it a couple of times and even worse, i've seen it where the Site collection shows as Unlocked and still remains locked. That has me scratching my head I can tell you.

I think on reflection I will look at the UseSqlSnapShot.

Darren

Alors, Bon Weekend.

Read the full discussion online.

To add a post to this discussion, reply to this email (spfarmbackup@discussions.codeplex.com)

To start a new discussion for this project, email spfarmbackup@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Coordinator
Feb 8, 2012 at 8:53 AM

This is now solved and will be in the next release. Version 2.0

 

Feb 8, 2012 at 2:29 PM

Great!

did you plan to move the site collection backup before the farm backup?

I did it and it I saw an amelioration on the Compressing issue. Like the farm backup take more time the Zips can be completed before the end of the script

Nov 12, 2012 at 4:14 PM

As an FYI, I still had the (or at least a) site locking issue when using the version 2.2 script.  I added a secondary script to unlock all of my sites

 

get-spsite |Set-SPSite -LockState Unlock

 

Hopefully this may help anyone else seeing this behavior.

--Brian

Coordinator
Dec 3, 2012 at 4:25 PM

Hey Brian,

I have been trying to recreate this without success. 

1. The script iterates through the sites.

2. Determines the current lock state.

3. Stores state in hastable.

4. Backs site up

5. Returns site back to original lock state based on hashtable.

Debugging throws nothing up so far. I will continue to look into it......

Thanks for the feedback

 

Dec 7, 2012 at 3:08 PM
Edited Dec 7, 2012 at 3:17 PM

I can confirm this is an issue w/ 2.2. Once of my site collections was locked after a failed backup. Thank you to NorcalWingman for posting the solution!!! 

I agree with the other comments here. Maybe at some point in the script set all site collections to unlocked before proceeding, perhaps at the beginning. Or maybe a secondary script could be scheduled at a later time to force all to be unlocked. Just ideas, I don't have enough experience with powershell yet.

If someone knows how to iterate over all the sitecollections and output the locked/unlocked status that would be really helpful.

Dec 7, 2012 at 3:55 PM

I'm not sure if doing an unlock of all the site is the perfect approach... but if we can take a snapshot of all the unlock site at the begining of the script and at the end of the script making sure from the snapshop restoring the status found at the beggining of the script

Dec 7, 2012 at 5:31 PM

Unless there can be some kind of catch-all trap for all errors, I think there may be two problems with that: 1) That would only work if the script gets to the end without errors. 2) If the sites are locked up due to a failure, any subsequent runs of this script would see that the sites are still locked up, not unlocked.

Coordinator
Dec 10, 2012 at 10:46 AM

 Hi All,

I have added here a stripped down version of the code which checks the state of the site, stores it in a hastable and then returns it to the original state.

I write out the results to help you follow what is taking place at each stage....

You can test the script by changing the state of some of your sites and you will see that in each instance it checks the initial state, and returns it to its inital state which is the whole point of this part of the script. NorcalWingmans suggestion is a workaround only in the event that ALL sites are in an unlocked state. Simply iterating through the sites and setting them all back to Unlock defeats the whole point of the determining the lock state and ensuring the site is set back to its original lock state after backing up the site. Which I daresay is okay in the majority of cases but not all. I wanted to make the check more intelligent by ensuring any locked sites were backed up and not inadvertantly unlocked after. The requirement originally came about because there were occasions when the lock state of the site stayed as locked following the site backup. There is a try/catch that encapsulates the site backup action.

Of course it would be simpler all round if we all used the Backup-SPSite cmdlet with the -UseSQLSnapShot parameter which guarantees no site lock – and still ensures consistent backup but the one thing that writing this script has shown me is the variety of SharePoint farms out there means that I have to try and satisfy as many use cases as I can.

So here is the script.....please feel free to test and I would welcome your feedback.

Clear-Host

#Region Setup paths & prepare for script execution

# Check if the execution policy is set to Unrestricted  
try
{
    $policy = Get-ExecutionPolicy  

    if($policy -ne "Unrestricted")
    {  
        Set-ExecutionPolicy "Unrestricted"
    }
}
catch
{
    $errText = $error[0].Exception.Message
    Write-Host "A problem occurred whilst attempting to set the the Execution Policy. Reason: $errText"
}

#Get the path that this script is running in
$scriptRoot = Split-Path (Resolve-Path $myInvocation.MyCommand.Path)
# Location of Logfile
$results = $scriptRoot + "\" + $(Get-Date -format dd-MMM-yyyy) + "-SiteLockStateLog.log"

#EndRegion

#Region Initiate logging using Start-Transcript
function Start-Logging
{
# Initiate logging
try
{
    Start-Transcript $results -Verbose
}
catch
{
    $errText = $error[0].Exception.Message
    Write-Host -ForegroundColor Red "$errText`r"
}
}
#EndRegion

#Region Stop logging using Stop-Transcript
function Stop-Logging
{
try
{
    Stop-Transcript -Verbose
}
catch
{
    $errText = $error[0].Exception.Message
    Write-Host -ForegroundColor Red "$errText`r"
}

Exit
}
#EndRegion

#Region Load the SharePoint snap-in for PowerShell
function Load-Snapin
{
$snapin = (Get-PSSnapin -name Microsoft.SharePoint.PowerShell -Verbose -ErrorAction SilentlyContinue)

if ($snapin -ne $null)
{
Write-Host -ForegroundColor Green "VERBOSE: SharePoint Snap-in is loaded. No action required.`r"
}
else
{
try
{
Write-Host -ForegroundColor Yellow "VERBOSE: SharePoint Snap-in not found. Loading SharePoint Snap-in.`r"
Add-PSSnapin Microsoft.SharePoint.PowerShell -Verbose -ErrorAction Stop
}
catch
{
$errText = $error[0].Exception.Message
Write-Host -ForegroundColor Red "VERBOSE: Loading of SharePoint Snap-in failed. Reason: $errText`r"
Stop-Logging
}
}
}
#EndRegion

#Region Get lock state of all site collections
function Get-LockState
{
<#
Readonly    -Sets the site collection to read-only
NoAdditions -No new content can be added. Only updates and deletions allowed 
Noaccess    -Sets the site collection to unavailable to all users
Unlock      -Sets the site collection/web application to unlocked
#>


    try
{
$Sites = Get-SPWebApplication $Url | Get-SPSite -Limit ALL -ErrorAction Stop

# Add lock state to a hashtable
$hashSiteCollection = New-Object System.Collections.Hashtable -ErrorAction Stop

foreach($Site in $Sites)
{
$lockState = "NoAccess"

if ($site.WriteLocked -eq $true)
{
$lockState = "NoAdditions"
}
if ($site.ReadOnly -eq $true)
{
$lockState = "ReadOnly"
}
if (($site.ReadOnly -eq $false) -and ($site.WriteLocked -eq $false))
{
$lockState = "Unlock"
}

$hashSiteCollection[$site.Url] = $lockState
                    
}
}
catch
{
$errText = $error[0].Exception.Message
Write-Host "There was an error whilst attempting to get site lock state. Reason: $errText"
}

    return $hashSiteCollection
}
#EndRegion

#Region Reset site lock state to initial site lock state
function Reset-LockState
{
param ([System.Collections.Hashtable]$initialLockState, $currentLockState)

Write-Host "Setting lock state of all site collections back to initial lockstate."
   
    try
{
foreach($key in $initialLockState.Keys)
{

            Write-Host "Initial state:" $initialLockState[$key] "Current state:" $currentLockState[$key]

if ($key -eq $null)
{
                return
}
elseif ($initialLockState[$key] -ne $currentLockState[$key])
{
Write-Host "If current state is not same as initial state then reset to:" $initialLockState[$key]
                Set-SPSiteAdministration -LockState $initialLockState[$key] -Identity $key -ErrorAction Stop
Write-Host "Info: $key lock state reset from " $currentLockState[$key] " to " $initialLockState[$key]
}
}
}
catch
{
$errText = $error[0].Exception.Message
Write-Host "There was an error whilst attempting to reset site lock state. Reason: $errText"
}
}
#EndRegion

#Region
function Start-Iteration
{
Write-Host "Getting current lock state of all site collections BEFORE backup...."
       
        $initialLockState = Get-LockState # Get lock state for all site collections & store in hashtable
       
        Get-LockState
   
    try
{
Write-Host "Next we execute the site(s) backup......"
}
catch
    {
$errText = $error[0].Exception.Message
Write-Host "SharePoint sites backup failed. Reason: $errText"
}
finally
{
    Write-Host "Getting current lock state of all site collections AFTER backup...."
            $currentLockState = Get-LockState
Reset-LockState $initialLockState $currentLockState  # Set lock state to state stored in hashtable
}
}
#EndRegion

#Region MAIN

Start-Logging
Load-Snapin
Start-Iteration
Stop-Logging

#EndRegion


Dec 14, 2012 at 2:49 PM

Hi Darren - To clarify, these scripts may be an inclusion in another point release? I just want to make sure that the intent here is that this wouldn't be a separate process. Sorry if that seems like a dumb question. -Rob

Jan 8, 2013 at 11:28 AM

Hello,

Me too, i have some lock issue with your script. Normally, it's not possible with your function to get and reset lock state but this function is only before and after 'Backup-Sites' function and not before and after 'Backup-Farm' function. So, to test i add them to 'Backup-Farm' function  and at this time i don't had any lock. Maybe, it's a solution...?

Best regards,

Florent CHAUVIN

 

 

 

 

Coordinator
Jan 8, 2013 at 10:26 PM

Hi Florent,

The Get and Set Lock state has been reworked in v2.3 and is not set to run pre site backup and post site backup (on a site by site basis.)

Darren

Jan 14, 2013 at 1:52 PM

Hi Marsdendd,

 

After I upgraded to the v2.3 script I have an issue with site collections that are running in "Not locked" status are changed to "No access" after the backup have run. Is this related to the topic here? And any idea what might cause it?

Coordinator
Jan 14, 2013 at 3:40 PM

Hi,

The method to get the lock state and reset it was reworked because one or two people encountered this, as shown above. It appears the change has not had the desired effect. The diffiiculty is replicating this behaviour.  

The original reason for implementing this was because occasionally, the same thing would occur even before the Get/Set site lock methods were implemented.

I will look at this again and see if there is a more robust way of ensuring the Site lock state is reset. What i dont want to do is apply the carte blanche Get-SPSite | Set-SPSite -Lock Unlock as this nullifies the reason for the Get/Set Lock methods completely.

In the meantime can you set Verbose logging is set on Backup and Restore in Diagnostic logging and see if we can trap it if it reoccurs.

Thanks

Darren

 

Jan 30, 2013 at 3:51 PM

Hi Darren,

I just did some debugging, and I noticed that in some cases, the values for WriteLocked and ReadOnly are empty, neither true nor false. And when that happens, the Get-LockState function determines the locakstate is "NoAccess". 

But I've worked around it for now by commenting out the call to Set-LockState

Apr 16, 2013 at 3:56 PM
Edited Apr 16, 2013 at 3:57 PM
Hi Darren,

maybe you can modifiy Get-LockState function to be more accurate and secure by adding 'Unknow' state. Example :
#Region Get lock state of all site collections
function Get-LockState
{
    param([string]$Url)

    <# 
        Unknow      - Lock state not checked
        Readonly    - Sets the site collection to read-only 
        NoAdditions - No new content can be added. Only updates and deletions allowed  
        Noaccess    - Sets the site collection to unavailable to all users 
        Unlock      - Sets the site collection/web application to unlocked
    #>
        
    try
    {
        $site = Get-SPSite -Identity $site.url
        
        $lockState = "Unknow"
        
        if ($site.WriteLocked -eq $true)
        {
            $lockState = "NoAdditions"
        }
        if ($site.ReadOnly -eq $true)
        {
            $lockState = "ReadOnly"
        }
        if (($site.ReadOnly -eq $false) -and ($site.WriteLocked -eq $false))
        {
            $lockState = "Unlock"
        }
        if ($_.ReadOnly -eq $null -and $_.ReadLocked -eq $null -and $_.WriteLocked -eq $null)
        {
            $lockState = "Noaccess"
        }       
    }
    catch
    {
        $errText = $error[0].Exception.Message
        Write-Log "Error: There was an error whilst attempting to get site lock state. Reason: $errText"
        $GLOBAL:hasErrors = $true
    }
    
    return $lockState
}
#EndRegion
and modify Set-LockState function to bypass set when 'LockState' is 'Unknow' :
#Region Set site lock state to original site lock state on completion of site backup
function Set-LockState
{
    param ([string]$Url, [string]$siteLockState)
    
    try
    {
        If ($lockState = "Unknow")
        {
            Write-Log  "Warning: Site lock state is unknow on site $($site.Url)"
        }
        Else
        {
            Set-SPSiteAdministration -LockState $siteLockState -Identity $site.Url -ErrorAction Stop
            Write-Log  "Info: Site lock state set to $siteLockState on site $($site.Url)"           
        }
    }
    catch
    {
        $errText = $error[0].Exception.Message
        Write-Log "Warning: There was an error whilst attempting to set site lock state. Reason: $errText"
        $GLOBAL:hasErrors = $true
    }
}
#EndRegion
It's just a proposal and not a resolution.

Florent.
Coordinator
Jul 8, 2013 at 3:25 PM
Edited Jul 8, 2013 at 3:25 PM
Dear All,

This issue should not occur from v2.4 onwards as I have removed it completely. I was just over engineering things and the site backup cmdlet will take care of the site lock state just fine on its own. I have however added the option to use the NoSiteLock option.

http://technet.microsoft.com/en-us/library/ff607901.aspx
_NoSiteLock
Specifies the site collection to remain read and write during the backup.

If the NoSiteLock parameter is not specified, then a site collection that has a site collection lock setting of "none" or "no additions" will be temporarily set to "read only" while the site collection backup is performed. Once the backup has completed, the site collection lock will return to its original state. The backup package will record the original site collection lock state so that it is restored to that state.

If users are writing to the site collection while the site collection is being backed up, then the NoSiteLock parameter is not recommended for potential impact to backup integrity
_
Aug 12, 2013 at 11:16 AM
Hi

Any idea when v2.4 will be available for download?

I am also having the site locking issue after failed backup or when the script does not finish.