WSS (MOSS) Backup
Our topic currently is backup and recovery.
I finally decided to spell "backup" without a hyphen so now I am ready to go. Here's some good references from our new friends:
-
I found this post from Joel Oleson that provided alot of information
-
And this one from Scott Jamison, et. al. at TechTarget.com.
I've got my WSS server running so I need this solution.
Of course WSS 3.0 includes a pretty strong backup tools inside Central Administration Operations. In the Backup and Restore section, you get a Perform a backup option.
Here you can select the entire farm or any one of you web applications including Central Admin or Search. You can select a full or differential and then specify a location for the backup file. The location must exist and the logged in user and the SQL Server Service account must have access to that location. It helps to make the taget folder a share so you can just map your backup out to \MyServerackups.
Of course the first time I tried it it failed with this error:
Access to the parth \MyServerackupsspbrtoc.xml is denied.
So, since this is a Timer Job, you have to go the Timer Job Definitions and delete the blown-up job.
I found one post that suggested adding the network service account to the backup folder will sufficient privileges to create and update the file.
And another that said to run asp.net regiis -ir in the .NET 2.0 folder.
Then, I came upon this TechNet article which did very little to help.
So, I started over and I hate it when this happens but I created a share on my server and I gave Network Service, System and my App Pool Identity full control of the share and ran it again and it worked.
So that's great, I now have an excellent backup of my site collection.
Now, I notice that my Share permissions are a bit different from my folder permissions and it was the Share permissions I needed to set. I was also able to eliminate Network Service and System and still get it to work. I'm not surprised about Network System since I'm not using any such account anywhere but my SQL Server is running under the local system account and I thought it might make a fuss. The only ID I needed is the App Pool Identity.
So now, each time I run a full backup, the resulting folder is 90Mb and again, I've got something less than 100 documents in the whole thing.
Oddly, if I have my App Pool Identity in my local administrators group and I give that group full access to the share, I get the access error. But, if I list the App Pool Identity explicity, it will run successfully.
I was also able to reduce the share permissions to read and create and it still worked.
So I try the same deal using the STSADM tool. The command looks like this:
C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12BIN>stsadm.exe -o backup -url http://MyServer/ -directory \MyServerackups -backupmethod full
And this generates alot of scrolling text in my command window but, in the end, it says it's failed with errors.
So I add System back to the share permissions and try again and the output says that the operation has completed successfully.
From all of this, I conclude that, using the CA UI, the logged-in user can trigger the job which will run using the CA App Pool Identity; if that identity has Read and Create on the Share, then the job ought not fail. On the other hand, using STSADM, the command is run from Windows which triggers SQL Server which runs under it's own identity, in my case, it was LOCAL SYSTEM and, therefore, I had to add SYSTEM to the Share permissions with Read and Create.
Thanks for paying attention.
-robot
Tags: