Defining a disaster recovery plan using collaborative tools which have a database backend is not an easy thing to achieve. The issues are technical and yep, you guessed, non-technical…
In this short article, I’ll describe a what it means and the high level strategy for use. Log shipping enables you to configure SQL Server to continually send transaction log backups on from a primary database on a primary server instance to one or more secondary databases on separate secondary server instances. The transaction log backups are applied to each secondary database individually.
Continually backing up the transaction logs from a primary database and then copying and restoring them to a secondary database keeps the secondary database almost synchronized with the primary database.
Log shipping can also include an optional third server instance, known as the monitor server, that records the history and status of backup and restore operations and raises alerts if these operations do not occur as schedule.
More information concerning how to set this up is here:
The key strategy points are:
1: Setup the mirror Farm including setting up new topology and its configuration. Document and backup this mirror.
2: Backup/Restore all databases from Primary SQL to Secondary SQL (except the Config databae)
3: Enable SQL Log shipping and the monitors
4: Set the databases on the Mirror to Standby or No Recovery
Note. While the mirror farm is actively engaged in log shipping, all portal databases are in read-only standby mode
To carry out the switchover:
1: Close Open Connections
2: Change role of Secondary SQL to Primary
1: Create Portal/Restore from Databases
2: Connect Additional Content Databases
The main thing in all of this as I said at the start is ‘watch the non technical element’. This is the SLAs that define the availability and recovery time of your systems. There is very little point, for example, to have log shipping enabled in two sites if for example, you have no-one in the mirror site to aid in the switchover.