Log shipping is a process that automates backing up database and transaction log files from a production SQL Server to a standby server. It keeps databases in sync by backing up transaction logs on an interval and restoring them on the standby. Log shipping consists of a primary server that is backed up and a secondary server that hosts the copies. It requires SQL Server Agent jobs to be configured for backup, copy, and restore operations between servers. Log shipping provides high availability but requires manual failover and can result in some data loss depending on backup frequency. It can be combined with other options like mirroring or replication.

1. SQL Server Log Shipping
By
Zeba Tabassum

2. Agenda
• High Availability Options
• Log shipping
• Recovery Option
• Role Change
• Requirement
• Demo
• Log Shipping Jobs
• Permissions
• Monitor Server
• Benefits
• Drawbacks
• Combining log shipping and mirroring
• Combining log shipping and replication

3. High Availability Options
• At a high level, there are five main high availability options including a new
feature set to be release with SQL Server 2012:
• Log Shipping
• Mirroring
• Replication
• Clustering
• AlwaysON

4. Log Shipping

5. Replication

6. Mirroring

7. Log Shipping
Definition
Log shipping is the process of automating the backup of database and
transaction log files on a production SQL server, and then restoring them onto
a standby server. The key feature of log shipping is that it will automatically
backup transaction logs throughout the day (for whatever interval you
specify) and automatically restore them on the standby server. This in effect
keeps the two SQL Servers Databases in “synch”.

8. Log Shipping

9. Log Shipping

10. Log Shipping

11. Log Shipping
• Log shipping consists of two servers:
– The primary server in a log shipping configuration has the primary
database you want to back up and restore on another server.
– The secondary server hosts the database that maintains a copy of
your primary database; and, of course, it is common that a server can
maintain and host multiple copies of primary databases coming from
multiple servers.

12. Recovery Option
• The last step in configuring log shipping is to configure the recovery mode
on the Restore Transaction Log tab of the Secondary Database Setting
dialog box.
• For this recovery option, you have two options:
– No Recovery Mode
– Standby Mode

13. Role Change
To perform a role change from the primary server to the secondary server,
you need to perform an initial role change to be able to make future role
changes. You can do this by following these steps:
1. Manually fail over from the primary server to the secondary server.
2. Disable the log shipping backup jobs on the initial primary server.
3. Configure log shipping on the secondary server (using the wizard).

14. Minimum Requirements
• SQL Server 2005 or later.
• Standard, Workgroup or Enterprise editions must be installed on all server
instances involved in log shipping.
• The servers involved in log shipping should have the same case sensitivity
settings.
• The database must use the full recovery or bulk-logged recovery model.
• Shared folders for transaction log files,copying T-Log backup files.
• SQL Server Agent Service must be configured properly.

15. Additional Requirements
• We should use the same version of SQL Server on both ends.
• It is possible to Log Ship from SQL 2005 to SQL 2008, but you can not do it
the opposite way.
• Log Shipping can be used for failover only if you have the same versions of
sql server on each end.

16. Demo

17. Demo

19. Demo

26. Log Shipping Jobs
• Internally when Log Shipping is configured, there are 4 jobs created
between Primary Server and Secondary Server, they are Backup Job, Copy
Job, Restore Job and Alert Job
• Backup job: This job is created on Primary Server; this job takes the
transaction log backup of the Database on a scheduled time
• Copy Job: This job is created on Secondary Server, this job Copies the
transaction log Backup from Primary Server to the Standby/Secondary
Server.
• Restore Job: This job is created on Secondary Server; this job restored
the copied transaction log backup on the Secondary Server.

27. Permissions on Shared folders
• For the backup job, read/write permissions to the backup directory are
required to the following account: SQL Server service account on the
primary server instance.Proxy account of the backup job. By default, this is
the SQL Server Agent account on the primary server instance.
• For the copy job, read permissions to the backup directory and write
permissions to the copy directory are required by the proxy account of the
copy job. By default, this is the SQL Server Agent account on the
secondary server instance.
• For the restore job, read/write permission to the copy directory are
required by the following: The SQL Server service account on the
secondary server instance. The proxy account of the restore job. By
default, this is the SQL Server Agent account on the secondary server
instance.

28. Monitor Server
An optional instance of SQL Server that tracks all of the details of log
shipping, including:
• When the transaction log on the primary database was last backed up.
• When the secondary servers last copied and restored the backup files.
• Information about any backup failure alerts.

29. Benefits Of Log shipping
• Log shipping doesn’t require expensive hardware or software. While it is
great if your standby server is similar in capacity to your production server,
it is not a requirement.
• Once log shipping has been implemented, it is relatively easy to maintain.
• Assuming you have implemented log shipping correctly, it is very reliable.
• The manual failover process is generally very short, typically 15 minutes or
less.
• Implementing log shipping is not technically difficult.

30. Drawbacks of Log Shipping
• Log shipping failover is not automatic. The DBA must still manually failover
the server, which means the DBA must be present when the failover
occurs.
• The users will experience some downtime. How long depends on how well
you implemented log shipping, the nature of the production server failure,
your network, the standby server, and the application or applications to be
failed over.
• Some data can be lost, although not always. How much data is lost
depends on how often you schedule log shipping and whether or not the
transaction log on the failed production server is recoverable.

31. Drawbacks of Log Shipping
• The database or databases that are being failed over to the standby server
cannot be used for anything else. But databases on the standby server not
being used for failover can still be used normally.
• When it comes time for the actual failover, you must do one of two things
to make your applications work: either rename the standby server the
same name as the failed production server (and the IP address), or re-
point your user’s applications to the new standby server. In some cases,
neither of these options is practical.

32. Combining Log Shipping & Mirroring

33. Combining Log shipping and
Replication