On each web front end server  that needs to backup  a virtual server, you’ll need the SQL client  tools installed  with SP3.

I have done this, but still when i select the option for backup  its given me msg install client  tools?

If you are using a server  farm, then it is not enough if you install client  components and SP3 on you database server. You should also install  them on the front end server.


If you are not using a server farm, you don’t need SQL client and you could not have installed  SPS without installing SQL Svr SP3.

Is anyone using AvePoint DocAve 4.0 for SharePoint backup? See link:
http://www.avepoint.com/products/DocAve4_0.htm. We are currently using
SPSBackup and STSAdm but are looking for a good item-level
backup/restore solution. I did find a very good article from Daniel
Webster of Mindsharp comparing different backup  solutions here:
www.windowsitpro.com/.../49794.html. He
recommended CommVault's Galaxy Backup & Recovery (Windows IT Pro
Editors' Choice award). However, AvePoint DocAve 3.1 was used in
comparison. I was wondering if anyone could tell me if DocAve 4.0 had
improved significantly from version 3.1.

Thanks in advance for any feedback.

I'm new to this group and to SharePoint in general so please excuse the dumb questions.

We are using WSS and are trying to setup a backup  process that runs as a scheduled task using the stsadm tool. I believe we are having permissions issues when running this. What are the necessary permissions to run this.

You must be a local admin on the box to run STSADM and STSADM must be run on the
box itself. Even though you are passing it a URL it doesn't go across a network
to get the data. There is a property post-SP2 that limits the access that local
admins have. If you have set that switch then the user running STSADM must be
in the SharePoint Administrator Group, as set in SharePoint Central Admin.

A while ago I had a VBS script that would walk through the Site Collections and
STSADM back them up. I'm not sure if I can find it or not. If you're
interested, let me know.

You mean ?


The following code example uses the Stsadm.exe tool to back up all site collections

within a portal  site. The code can be copied into a VBScript file (.vbs).


Option Explicit

Const STSADM_PATH = "C:\Program Files\Common Files\Microsoft Shared\web server  extensions\60\BIN\stsadm"

Dim objFso, objFolder, objFiles, objFile, objShell, objExec, strResult, objXml, objSc, objUrl, strUrl, strFileName, strCmd

Set objFso = CreateObject("Scripting.FileSystemObject")

Set objFolder = objFso.GetFolder("C:\backup\")

Set objFiles = objFolder.Files

WScript.Echo "Begin backup"

' Delete all backup  files currently present in the backup folder.

For Each objFile in objFiles

objFile.Delete(True)

Next

' Retrieves all site collections in XML format.

Set objShell = CreateObject("WScript.Shell")

Set objExec = objShell.Exec(STSADM_PATH & " -o enumsites -url http://woodgrove/")

strResult = objExec.StdOut.ReadAll

WScript.Echo strResult

' Load XML in DOM document so it can be processed.

Set objXml = CreateObject("MSXML2.DOMDocument")

objXml.LoadXML(strResult)

' Loop through each site collection and call stsadm.exe to make a backup.

For Each objSc in objXml.DocumentElement.ChildNodes

strUrl = objSc.Attributes.GetNamedItem("Url").Text

strFileName = "C:\backup\" & Replace(Replace(strUrl, "http://", ""), "/", "_") & ".bak"

strCmd = STSADM_PATH & " -o backup -url """ + strUrl + """ -filename """ + strFileName + """"

WScript.Echo "Backing up site collection " & strUrl & " to file " & strFileName & " using the following command " & strCmd

objShell.Exec(strCmd)

Next

WScript.Echo "Backup of portal site collections successful"



The following code example shows how to call the previous VBScript file. The

code can be copied into a batch file.

cscript [path to backup script]mybackupscript.vbs


change it where it says

. Set objFolder = objFso.GetFolder("C:\backup\”)

Set objExec = objShell.Exec(STSADM_PATH & " -o enumsites -url http://woodgrove/")

Oh, also change it where it says

strFileName = "C:\backup\" & Replace(Replace(strUrl, "http://", ""), "/", "_") & ".bak"

I posted a few days ago about SPTimer problems affecting incoming
e-mail. I also noticed similar problems with SPTimer affecting backups.
I now find that actually every backup  has failed with the same problem.
That is path cannot be null. Unfortunately the developer didn't think it
was worth mentioning which path it was that couldn't be null. Does
anyone have any thoughts on what path it could be. Indeed has anyone got
backups to actually do a backup that works?

SPTimer backups  have always worked great for me.

Where did you see the error? From within Central Admin? Or in the
12\logs?



Here is a batch script I use on a schedule (the path is REMed because
stsadm is in the system path):



@echo off

echo =================================================

echo backup  sites on the sharepoint  Portal 2007 Server

echo =================================================

c:

rem cd \Program Files\SharePoint Portal Server\Bin

@echo off

stsadm -o backup -directory y:\backup -backupmethod differential -quiet

echo completed

rem pause 5

Thanks for the reply. The errors are in the event logs on the server  and
other places as well. The only place I ever saw a reference to them is
from a Google search. However, I didn't find any resolutions although
others were having the same problems.

The error which appear in the event logs is:

The Execute method of job definition
Microsoft.SharePoint.Administration.Backup.SPBackupRestoreJobDefinition
(ID 6ac9d3a1-335d-4603-8cef-4ff62f59864f) threw an exception. More
information is included below.

The backup  job failed. For more information, see the error log that is
located in the backup directory.

If I schedule a job in Central Admin I get that error and the following
error message and others which are the same except for the database
name. The log file that it mentions is a collection of gobbledygook that
doesn't mean much to me but I guess it means something to others.

Object MOSS_SharedServices_Search_DB failed in event OnBackup. For more
information, see the error log located in the backup directory.

The main error in the log files is (this is also repeated for each
database)


SQL Server Command: BACKUP DATABASE [WSS_Search] TO DISK=@db_loc WITH
NAME=@db_name, STATS=5, NOINIT, NOSKIP, NOFORMAT, NOREWIND

@db_name=WSS_Search,
@db_loc=D:\Backups\spbr0005\0000001E.bak

[13/08/2007 19:59:58]: Error: Object WSS_Search failed in event
OnBackup. For more information, see the error log located in the backup
directory.

SqlException: Cannot open backup device
'D:\Backups\spbr0005\0000001E.bak'. Operating system error 3(error not
found).

BACKUP DATABASE is terminating abnormally

Now I suspected this was a rights issue. However, D:\Backups\spbr0005 is
the directory where I found the log file. It was perfectly capable of
writing the log file there so why can't it open the backup file
0000001E.bak in the same directory. Of course, as is so often the case,
the file is there and SharePoint has written stuff to it. All very odd.

What I've done to get round this is more or less what you suggested
which is I run a batch file every night to run stsadm to do manual
backups but it isn't ideal.

Normally this issue is caused by the SQL Account that is
perfuming the backup  needing access to the directory you are backup up to.
Check that the account that is used by SQL to backup can write to that
directory by performing a manual backup to that location using SQL. If you
go to the SQL Server abd run the command from a Query window:

BACKUP DATABASE [WSS_Search] TO DISK=' D:\Backups\spbr0005\0000001E.bak'
WITH
NAME=' WSS_Search', STATS=5, NOINIT, NOSKIP, NOFORMAT, NOREWIND

This should then verify that you can actually write to this location using
SQL. If you have done this already then my apologies.

I hadn't thought of that. When I tried it on the
SQL server  I got a similar error to what I had before. I've called the
account that MOSS uses to access the DB server "mossdbusr" and it is a
member of the local admins group. However, I think what you are saying
is that it is another account that will be trying to write the backup
files. My best guess is that it is the SQL service  account so I just
gave it Full Control of the backup  directory but sadly that made no
difference. Now there is something that I don't understand here. In my
setup I've created a directory called D:\Backups on one of the MOSS
servers but should that be on the SQL server? It is probably a stupid
question but I don't recall anything in any book or installation guide
that said it should. I've just created a D:\Backups directory on the SQL
server but that made no difference. By any chance is this something that
only works when used in situations where there is only one server
running everything?

Hope your well. Normally the backups  are run using the
service account that MOSS2007 uses. I assume that the location you are using
to backup  to is actually created and setup as UNC share. It should not make
any difference where the backups are being written to at all. What you could
do to test the permission issue is login into SQL Management as the
"mossdbuser" and try to run a backup of one of the MOSS databases. Tell it
to backup to the same location you had before and see if SQL can write to
the location. The other test would be to make the MOSS accounts local
administrators of each of the servers and run the backup again, you may
already have this.

Thanks for the information. I think I really don't understand this at
all and I probably haven't explained things very well so perhaps I can
give some background and ask some (probably) stupid questions.

I have 2 web front end servers and a third server  that does
search/index, This one is also the central admin site. On that machine I
have created a directory called D:\Backups for all the backups. There
are 2 more servers running SQL in a cluster. The D:\Backups directory is
not shared. When I start a backup  using the GUI on the central admin
machine, it creates a directory called D:\Backups\spbr0004 or
D:\Backups\spbr0005 (it increments the number each time) and puts some
files in there. After a few seconds it then claims that it cannot access
one of the files that it just created.

Reading your e-maiI makes me think that the SQL server needs to have
direct access to the D:\Backups directory on the search/index server. So
here is the stupid question: Is that actually what is required and
therefore it is just a stupid mistake on my part.

If it creates the spbrxxxxx directory and stops with a security error,
you most likely need to add the SQLSERVER machine account to the file
share with write permissions. In addition, you should access the backup
directory via UNC file share (\\server\share), not <drive:\directory>.
Share permissions don't matter so much, just make sure you secure the
NTFS permissions accordingly.

Your SQL servers absolutely need access to that directory. The Central
Admin backups  happen in two parts. The first part happens on the
SharePoint box that you're running Central Admin on. Obviously that box
can get to its own D drive. When the backup  gets to the part where it
backs up SQL that operation is actually happening on the SQL box and
that operation is trying to write to the same spot the first part did.
If you use a local path that can't happen. Like Ben said, create a
share and use that path instead of a local path. You'll need to make
sure that share is accessible from the SQL box and the account SQL is
running as must have write access to that share.

Thanks for the feedback. That would explain it. I thought it would be
something stupid I'd done or, in this case, not done.

If it creates the spbr000n directory and stops with a security error,
you most likely need to add the SQLSERVER machine account, in addition
to the central admin app pool ident (farm account) to the file share
with write permissions. In addition, you should access the backup
directory via UNC file share (\\server\share), not <drive:\directory>.

I know how to fix it now..............

Hi Angarika

Can you please tell us the solution for this error.