Configuring log shipping

SQL Backup provides a wizard to guide you through the process of setting up log shipping, to ship transaction logs from a primary server to a secondary server. For example, you may want to do this if you are maintaining a 'standby' server as a backup to your primary server. For more information about this, see Using SQL Backup log shipping to maintain a standby server.

You use SQL Backup to perform regular backups of the primary server, and restore them on the secondary SQL Server.

In the log shipping process:

1. Transaction log backups are performed on the source database on the primary SQL Server (for example the production database).
2. The backup files are copied to a network share that can be accessed by both SQL Servers.

   If the copying process fails for a backup file (due to an extended network outage, for example), SQL Backup automatically attempts to copy the file to the network share at regular intervals. Any future transaction log backups that are created are queued behind the file that could not be copied. Once the copying process is working again (because the network outage has been fixed, for example), SQL Backup copies each transaction log backup to the network share, in the correct order.

3. The backup files are restored to the destination database on the standby SQL Server.

The database must use the full or bulk-logged recovery model.

The wizard sets up SQL Server Agent backup jobs that use SQL Backup to perform the backup and restore operations.

When you use SQL Backup to ship your transaction logs, the transaction log backups are not immediately restored on the secondary server; you specify a time delay (recommended) or you can specify a separate schedule for the restore operation.

By default, the first time the log shipping job is run, SQL Backup creates a full backup of the source database and restores it on the destination SQL Server prior to creating the log shipping tasks. This is to ensure that the destination database is in the correct state for restoring the transaction log backups. However, you can configure SQL Backup to skip this backup and restore; this is useful if you have already set up a destination database that is ready to receive transaction logs.

Note that you can use the Log Shipping wizard with remote SQL Servers only if SQL Backup Pro is installed on both of the SQL Servers.

You cannot ship transaction logs from a later version of SQL Server to an earlier version (for example, from SQL Server 2008 to SQL Server 2005), because of the differences in their structures. You can ship transaction logs from earlier versions of SQL Server to later versions, but in this case the destination server must use the non-operational recovery completion state (RESTORE WITH NORECOVERY). This is a SQL Server restriction.

Additionally, you cannot ship transaction logs created on a SQL Server instance that has version 6 SQL Backup server components installed, to an instance that has an earlier version of the server components installed. This is because of differences in the SQL Backup (.sqb) file format introduced in SQL Backup 6. In this scenario, you should update the destination SQL Server instance with the latest SQL Backup server components before configuring log shipping.

To start the Log Shipping wizard, click Log Shipping. The Log Shipping wizard comprises the following steps: