Disaster recovery is a approach which consists of the precautions/steps taken so that the effects of a disaster will be minimized and the organization will be able to quickly resume back. When one of the web application, site collection or a Web Front End goes down this does not mean it is a disaster recovery situation. DR approach Is used when the entire farm goes down. Approaches/models varies between different organization depending on  cost,  customizations,  Recovery time,  Recovery Point, size of data and other factors.

Scenario:

You have a SharePoint 2010 Farm which is running some business processes. You want to be prepared for replicate of the SP farm for disaster recovery scenarios so in case of any Disaster you can bring your farm back to online in minimum data loss,  least failover time and also cost effective.
Model used here is Hot Stand By it has minimum Recovery Time to bring the farm online.
Hot StandBy Sharepoint 2010 Disaster Recovery can be done by different ways :- Log Shipping,  Mirroring.
In this article I have configured the DR using the log shipping  (more preferred).

Log Shipping in DR:

1.       Log Shipping  performs three Task to perform the operation : Backup Transactional Logs, Copy these logs to secondary Server and Restore the log backup to the database.
2.       Each task creates a Job, all the jobs run in regular interval scheduled.
3.       The primary server instance runs the backup job to backup the transaction log on the primary database and then it places the log backup in the primary log backup file location.
4.       The secondary server instance runs its job to copy the primary log-backup file to its own local destination folder.
5.       Now secondary server run its own restore job to restore the log backup from destination folder to secondary database

 Points to Note:-

• Log Shipped Databases can be attached to web application while they are log shipping.
• Multiple Secondary Database can be configured in log shipping database.
• Log shipping Database can be queried if it is in standby Mode.
• This is a Low Cost solution.

 Limitations:

• Chances of some amount of data loss is always.
• By default, the failover process for log shipping is manual. You can create scripts to automate failover.
• Database must use the full or bulk-logged only to configure log shipping database.
• Database account need to have control on the shared path.
• Bit more complex the mirroring.

Before you Start:

 In the example we are considering that both Farm(Production and DR) are part of same Domain.

 Preparing the farm 

 SharePoint supports Log Shipping for following Databases:

 Config DB and Admin Content DB are not supported to be log shipped. You should create a new Configuration Database in DR farm (Same Configuration Database cannot be shared or used in two different farms) 

Step by step configuration of DR. (Configuring the log shipping) 

Steps to failover:

 Changes Need to be done when you failover from Production SharePoint 2010 to SharePoint 2010 DR Farm. 

Some Common Queries:

Q1:       Is The performance of the sharepoint primary server will effect during the log shipping?
A1:       Yes, You might also face performance issue if the system takes to ship log consistently more then time that is required to create new logs. It is better to backup and copy many small transaction logs compared to large transaction logs. 
 
Q2:       In the event of an unplanned failover, some data loss is possible ?
A2:       Yes, depending on the frequency of log shipping and the time of failure. It is possible to lose data from the last log shipping interval before a failure.
 
Q3:      Is log shipping method feasible with more than 10 number of databases?
A3:      This is subjective to hardware, network throughput and resources available on servers. SQL Performance Counters can be used to find the optimized level for your environment.
 
Q4:     How can we verify what solutions custom/3rd party web parts are in the environment in new farm after DR ?
A4:     stsadm -o enumsolutions will give you details on what all solutions are deployed in the farm. OR check CA solutions page.
 
Q5:    Can we crawl the content before the failover on the DR Farm?
A5:     No we cannot crawl the content before the failover. It is recommended to crawl the content after the failover.
 
Q6:    Do we need to disable the timer jobs on the failover (secondary) farm?
A6:    Yes, we should always disable the timer job on the failover on secondary farm.
 
Q7:    Do we need to plan for the SSL certificates on IIS websites on DR Server?
A7:    Yes, if web apps are hosted on SSL then certs should be applied to DR farm IIS Sites respectively.

WSS logging database grows very fast and it cause the storage problem most of the time in sharepoint server 2010.

To reduce the size of the logging database or to purge the old data from the logging database we can these steps. 

To find the Logging Database Name go to following path:-

Login to Central Administration -> Monitoring -> Configure Usage and health data collection->

The Logging database stores the following things:-

• ULS Logs from 14 Hive\LOGS

• Raw Resource Usage Data

 This data is used by Web Analytics in Sharepoint. Two timer jobs Microsoft SharePoint Foundation Usage Data Import and Microsoft SharePoint Foundation Usage Data Processing are used for importing and processing the raw data in the web analytics database.

By Default the system retains 14 days of Usage data in this database. By following PowerShell command we can check and change the value of retention days of this database. Get-spusagedefinition and Set-SPUsageDefinition  

Try  Get-SPUsageDefinition

 Now you need to find which table is taking most of the space inside the WSS logging Database. 

You Can check the same from the SQL Server

Login to Sharepoint Management Studio -> Select your logging Database (Right Click) -> Reports- > Standard Reports -> Disk Usage by Top Tables.

 Say RequestUsage* is taking most of the space inside WSS Logging database so  you can bring down the retention period of  Page Request Event.

Or if you want you can bring down the retention period for all the Events for any number of days from 14 to 1. 

Use the following command to do so.

Set-SPUsageDefinition -Identity"Page Requests" -DaysRetained 3

Run the same Power Shell command again to cross check "Get-SPUsageDefinition" and check the Retention period is changed or not.

After that we need to run the two timer jobs to clean the old data 'Microsoft SharePoint Foundation Usage Data Import' and 'Microsoft SharePoint Foundation Usage Data Processing'.

Go to Sharepoint Central Administration -> Monitoring -> Configure Usage and health data collection-> Log Collection Schedule.

And it will take you to the timer jobs.

 Now Click on both the Job Definitions one by one and hit 'Run Now' to run the timer jobs

Once the timer jobs is run you can check and confirm database has released the space.

******************************************************************************************************************************