Sharepoint 2010 Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint 2010       RSS Feeds

Automate SharePoint 2010 Farm Backups with PowerShell

  Date: May 30    Category: Sharepoint 2010    Views: 1054

I have a query and doubts about Automate SharePoint 2010 Farm Backups with
The Environment contains the Following Servers and Rules, All Servers Running
Windows Server 2008 R2 SP1:
a) Two SharePoint 2010 Servers with SP1 Running with WNLB, Both Servers is
Hosting the (SPCA, Service Apps and the Web Apps) to have a Full Redundancy and
b) Three SQL Server 2008 R2 with SP1 Running as Mirroring.

So, i have a Full Up-And-Running High Available SharePoint Farm which is working
fine. BTW, am using SQL Alias to connect to the SQL instances, also i have
created and test the PowerShell Scripts and the Batches and its also working
fine in a Single Box.

Now, My Questions is:

1) Can I Run the Task Scheduler in the 2 SharePoint Servers as Redundancy, Means
Run the Task on Server1 But if Server1 is Down Run the Task from Server2 ?
2) I know that SharePoint 2010 Aware of SQL Alias and Fail-over coz I Already
built the Same :) . Anyway, I just want to Know and to Ensure that What if my
Principal SQL Server is Down and the Task is Running, Is It going to take the
Backup from the Mirror SQL Server OR NOT ?



2 Answers Found

Answer #1    Answered On: May 30    

For redundant script running, I'm thinking your best bet there is to execute the
script from an outside source. That will mean that you'll definitely have to
enable remote access to powershell on your front ends:
PS> Enable-WSManCredSSP -role server
PS> Enable-PSRemoting
You may also need to run:
PS> Set-WSManQuickConfig
...which will set WinRM to autostart, set it to accept requests, open the
firewall, and recycle the service.

On the machine you'll run the script from you'll need to run:
PS> Enable-WSManCredSSP -role client -delegatecomputer
...for each server it will need to execute remotely on.

You'll also need to either disable script security on each front end or
digitally sign all of your scripts with a certificate that is then deployed to
all of your front ends. (There's a gotcha here if you compose your scripts
using the PowerShell ISE. The ISE saves the scripts encoded UCS-2 Big Endian,
while the certificate signing engine only accepts scripts to be signed encoded
as UTF-8. If you open and then resave from NotePad, it should fix the problem.)

After that you'll be able to craft a script to attempt execution on one server,
and if it fails, attempt execution on the next server in the chain and so on.

As far as how SharePoint handles mirrored databases, that's ultimately up to
your SQL environment. SharePoint can be made "mirror aware" by configuring all
of the databases with a FailoverServer. You can confirm a failover server has
been set with:
PS> Get-SPDatabase | select name, server, failoverserver

And you can set it with:
PS> $db = Get-SPDatabase -Identity <SPDatabasePipeBind>
PS> $db.AddFailoverServiceInstance("<target-sql-server-name>")
PS> $db.Update()

Incidentally, using an empty string ("") for the target name will clear the
field and remove failover capabilities. When a request comes in that requires
database access, SharePoint will attempt to connect to the primary database
server. If the SQL mirror has failed over, it will get a connection denial and
then attempt to connect to the failoverserver. I also believe SharePoint keeps
track of the last server it connected to, so not all requests need to
fail/failover before a successful connection. A backup should act the same as
a web site request as far as how SharePoint handles access to databases/failover

Answer #2    Answered On: May 30    

Thanks a lot for your information and help, its really very interesting answer.
Thanks once again.

Didn't find what you were looking for? Find more on Automate SharePoint 2010 Farm Backups with PowerShell Or get search suggestion and latest updates.