Академический Документы
Профессиональный Документы
Культура Документы
Summary
This document describes best practices in setting up, monitoring and administering Database Log
Shipping process which provides data redundancy and increases system availability. It focuses on the
common scenarios for disaster recovery, physical data corruption, protection against user errors and high
availability.
1
Database Log Shipping on Microsoft SQL Server
Table of Content
Overview of High Availability solutions in Microsoft SQL Server ______________ 4
Log Shipping fundamental concepts _____________________________________ 4
Overview _______________________________________________________________ 4
Technical implementation of Log Shipping ____________________________________ 4
Fail over ________________________________________________________________ 4
Fail back________________________________________________________________ 5
Backup directory (backup folder)____________________________________________ 5
Copy directory (copy folder)________________________________________________ 5
STANDBY mode of a database ______________________________________________ 5
Technical background of STANDBY mode_____________________________________________ 5
Influence of the Log shipping on a Backup Strategy ____________________________ 6
Considerations about database corruption____________________________________ 6
Considerations about user errors ___________________________________________ 6
Log Shipping as a part of disaster recovery plan _______________________________ 6
Evaluating data loss after failover ___________________________________________ 7
Log Shipping in SQL 2005 ______________________________________________ 7
Prerequisites ____________________________________________________________ 7
SQL Server prerequisites __________________________________________________________ 7
SAP prerequisites ________________________________________________________________ 7
Setting up Log Shipping ___________________________________________________ 8
Preparations ____________________________________________________________ 8
Configuring Log Shipping__________________________________________________ 9
Preparing SAP System to failover __________________________________________ 10
Failover scenarios _______________________________________________________ 12
Disaster recovery scenario ________________________________________________________ 12
Partial database loss scenario _____________________________________________________ 13
DB corruption scenario ___________________________________________________________ 13
User error scenario ______________________________________________________________ 14
Maintenance scenario____________________________________________________________ 15
Completing failover ______________________________________________________________ 16
General post-failover actions ______________________________________________________ 16
Fail back_______________________________________________________________ 17
Preparing the system to fail back ___________________________________________________ 17
Failing back____________________________________________________________________ 17
Monitoring and reporting for Log shipping ___________________________________ 18
Suspend Log Shipping ___________________________________________________ 18
Resume Log Shipping____________________________________________________ 19
Remove Log Shipping permanently_________________________________________ 19
2
Database Log Shipping on Microsoft SQL Server
3
Database Log Shipping on Microsoft SQL Server
SQL Server 2000 supported two approaches to increasing DB service availability: High Availability Cluster
and DB Log Shipping.
With SQL Server 2005 a new functionality was introduced additionally, the Database Mirroring.
The current document focuses only on the DB Log Shipping.
For more information on using SQL Server in a Windows Cluster (MSCS) environment, please refer to
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog01.mspx.
For more information on using SQL Server DB Mirroring, please refer to FAQ
http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirfaq.mspx and to SAP Note 965908.
Fail over
Failover is a capability of a service to switch over to a redundant or standby computer server in case of a
failure on the productive server.
4
Database Log Shipping on Microsoft SQL Server
Log Shipping does not possess a capability to fail over automatically from the primary server to the
secondary server. If the primary database becomes unavailable, a manual intervention of a system
administrator is necessary to restore DB service. He must recover the rest of transaction log backups and
bring the database to the online state.
Fail back
Fail back is a process of moving the service back to the original hardware after it is ready to run again. In
other words, it is a process, reverse to a fail over.
Like a fail over, the fail back in a log shipping scenario must be done manually by the system administrator.
5
Database Log Shipping on Microsoft SQL Server
6
Database Log Shipping on Microsoft SQL Server
select @@servername
must return the local servername on the Primary and Secondary server.
The database format of SQL Server 2005 is independent from the server platform. Thus, it’s possible
to have 64-bit Primary server and 32-bit Secondary server and vice versa.
SAP prerequisites
There is no mechanism in SAP kernel supporting DB Log shipping, thus there are no SAP parameters
controlling that. All actions must be done manually. That’s why there is no special requirement to SAP
Release, kernel patch level, SAP Support Package level.
7
Database Log Shipping on Microsoft SQL Server
Preparations
1. Make sure no transaction log backups for the DB <SID> are carried out until the Log Shipping
configuration is finished. If transaction log backups are scheduled as SQL job or using a third party backup
software, they must be deactivated.
2. Back up the complete <SID> database (full database backup). There is no necessity to stop SAP for
that, although lower DB performance during the backup must be taken into account. Any kind of backup
media (disk, tape) is suitable.
3. Restore the backup onto the secondary server. When using Management Studio, choose the option
“Leave the database non-operational, and do not roll back the uncommitted transactions.
Additional transaction logs can be restored. (RESTORE WITH NORECOVERY)”. See (2) on the figure
below. When using T-SQL command, add the option “WITH NORECOVERY” to the option list of the
RESTORE command.
During the restore there is a possibility to change data file destination folders. This is necessary if the
secondary server doesn’t have a drive letter which existed on the Primary server (see the page Options).
8
Database Log Shipping on Microsoft SQL Server
Note, in the column “Restore As” you have to specify a full path to the files (1). All folders in the path must
exist, but the files itself must not.
9
Database Log Shipping on Microsoft SQL Server
On the same screen an optional monitor server can be configured. Once the monitor server has been
configured it cannot be changed without removing log shipping first.
25. Under “Monitor server instance”, select the “Use a monitor server instance” check box, and then click
“Settings”.
26. Click “Connect” and connect to the instance of SQL Server that you want to use as your Monitor
server. It is recommended to use Windows authentication. The user must be assigned to the
“sysadmin” fixed server role.
27. Under “Monitor connections”, choose the connection method to be used by the backup, copy, and
restore jobs to connect to the monitor server.
28. Under “History retention”, choose the length of time you want to retain a record of your log shipping
history. It is recommended to retain the history for at least 2 weeks.
29. Click OK.
30. On the Database Properties dialog box, click OK to begin the configuration process.
In case of errors or warnings press “Report” and save the report to a file. If you cannot solve the problem
by your own, create a problem message at SAP attaching the error report file.
10
Database Log Shipping on Microsoft SQL Server
SAPDBHOST is the obligatory parameter. It’s the hostname of the database server. Since
the hostname is changed after failover, this parameter must be corrected appropriately.
dbs/mss/server is an optional parameter. If not set explicitly, its value is copied from
SAPDBHOST. This parameter is mandatory if SQL Server is installed as a named
instance, i.e., network hostname is not equal to SQL Server instance name.
The recommended procedure is as follows:
Copy the actual DEFAULT.PFL file to DEFAULT_PRIMARY.PFL
Copy the actual DEFAULT.PFL file to DEFAULT_ SECONDARY.PFL
In the DEFAULT_SECONDARY.PFL substitute <Primary DB Server hostname> with
<Secondary DB Server hostname> for the parameter SAPDBHOST.
If the parameter dbs/mss/server is explicitly set, in the DEFAULT_SECONDARY.PFL
substitute <Primary SQL Server name> with <Secondary SQL Server name>. This option
accepts prefixes and port number that may be necessary when the Secondary server is a
named instance. For instance,
dbs/mss/server = tcp:QASDB\TST,1433
where “tcp:” is a protocol specifier,
“QUASDB\PRD” is the SQL Server named instance name,
“1433” is the port number the SQL Server is listening to.
Refer to SAP note 208632 for more information.
3. Windows environment variables. Standalone SAP programs (i.e. tp, R3trans, saplicense)
require the environment variable MSSQL_SERVER to be correctly specified with SQL Server
name (see SAP note 98678). Since after a failover the name has changed, the variable must be
corrected too. This action is not as important as it is necessary only for technical transactions.
SAP System itself doesn’t read the environment variables and can start even with wrong values.
On Windows 2003 Server you can prepare a script, setting Windows environment variables on the
central instance and all application servers. The command is
SETX MSSQL_SERVER <Secondary SQL server name>
For example:
SETX MSSQL_SERVER QASDB\TST,1433
The script has to be executed before failover under user <domain>\<sid>adm.
On Windows 2000 the action needs to me done manually as follows:
- Log on as user <domain>\<sid>adm.
- right click on “My computer”, choose “Properties”
- Go to tab “Advanced”
- Press button “Environment variables”
- Choose the variable MSSQL_SERVER in the “User variables for <sid>adm” and press “Edit”.
- Enter the name of the Secondary SQL server, e.g. QASDB\TST,1433.
- Press OK until you leave the application.
11
Database Log Shipping on Microsoft SQL Server
Failover scenarios
Below only a failover of DB server will be discussed. If SAP Central Instance (SAP CI) coexists with
DB instance on the same hardware, a lot of further actions must be prepared for failover. All they are
out of scope of this document.
12
Database Log Shipping on Microsoft SQL Server
To fail over to the Secondary server without data loss the following actions must be done:
1. Suspend Log shipping as described in Suspend Log Shipping on page 18.
2. Stop the SAP System.
3. Back up the active transaction log on your primary server with option NO_TRUNCATE. That
option allows making a log backup even if the database is unavailable. This last log is also
called “tail log”. The command is as follows:
USE master
BACKUP LOG <SID>
TO DISK =
'\\backup_share\BackupFolder\<SID>_YYYYMMDDHHMM_tail.trn'
WITH NO_TRUNCATE
If the command finishes successfully, there will be no data loss, proceed with step 4.
Otherwise the situation meets not this scenario, rather Disaster recovery scenario, because
the transaction log is damaged or lost. Please proceed with step 2 of Disaster recovery
scenario on page 12.
4. Copy the tail log backup from the Backup folder to the Copy folder manually.
5. Log on to the Secondary server with SQL Management Studio
6. Start the Copy Job. It can be found under <Server> -> SQL Server Agent -> Jobs.
By default, its name is “LSCopy_<Primary server name>_<SID>”. Right click the job name
and choose “Start job at step…”.
7. When the copy job is finished, start the Restore job. By default, its name is
“LSRestore_<Primary server name>_<SID>”. Right click the job name and choose “Start job
at step…”.
8. If the restore delay is not used, proceed with step 11.
9. Identify the most recent TRN file used for restore: right click the Restore job, choose “View
history” and expand the recent history record. The step logs are displayed in a reverse
chronological order. Find the topmost step containing the message
“Restored log backup file. Secondary DB: '<SID>', File:
'\\copy_share\CopyFolder\<SID>_YYYYMMDDHHMMSS.trn'.
Note its name.
10. Find in the Copy folder TRN files with timestamps greater then the last restored TRN file and
restore those files in sequence with a series of commands like follows:
RESTORE LOG <SID>
FROM DISK = '\\copy_share\CopyFolder\<SID>_YYYYMMDDHHMMSS.trn'
WITH NORECOVERY
Note, the TRN files must be processed in strict chronological order, otherwise an error is
thrown. Should it happen, find the correct TRN file and proceed with the restore.
11. Restore the tail log TRN file with the command
RESTORE LOG <SID>
FROM DISK =
'\\copy_share\CopyFolder\<SID>_YYYYMMDDHHMMSS_tail.trn'
WITH NORECOVERY
12. Proceed with the section Completing failover on page 16.
In this scenario a simplified fail back is not possible (see Fail back on page 17).
DB corruption scenario
For more information about DB corruptions please refer to SAP note 142731.
In this case the Primary DB appears to be corrupted after a regular check or because some SQL
statements fail causing an ABAP short dump in the SAP system. The DB server itself is functioning and
none of the database files is lost.
13
Database Log Shipping on Microsoft SQL Server
If you faced a DB corruption, there is a probability that the transaction log has been corrupted too. In this
case the Restore job will be failing with errors like
During redoing of a logged operation in database 'SID', an error
occurred at log record ID (xxx:xxx:zzz).
If this is the case, the database can only be restored to the point of a corruption in the transaction log and
thus, some committed transactions will be lost.
If the restore operation finishes without errors, no data loss happens after a failover.
To fail over to the Secondary server the following actions must be done:
1. Inform end users about an urgent SAP System shutdown and stop the SAP system.
2. Log on to the Primary DB server with SQL Management Studio
3. Start the Log shipping Backup job. It can be found under <Server> -> SQL Server
Agent -> Jobs. By default, its name is “LSBackup_<SID>”. Right click the job name and
choose “Start job at step…”.
4. Suspend Log shipping as described in Suspend Log Shipping on page 18.
5. Log on to the Secondary server with SQL Management Studio
6. Start the Copy Job. It can be found under <Server> -> SQL Server Agent -> Jobs.
By default, its name is “LSCopy_<Primary server name>_<SID>”. Right click the job name
and choose “Start job at step…”.
7. When the copy job is finished, start the Restore job. By default, its name is
“LSRestore_<Primary server name>_<SID>”. Right click the job name and choose “Start job
at step…”. Check job history to identify failures during restore. If an error suggesting to a
corrupted transaction log occurs, proceed with Completing failover on page 16. In this case
take some data loss into account.
8. If the restore delay is not used, proceed with step 11.
9. Identify the last TRN file used for restore: right click the Restore job, choose “View history”,
expand the recent history record. The step logs are displayed in reverse chronological order.
Find the topmost step containing the message
“Restored log backup file. Secondary DB: '<SID>', File:
‘\\copy_share\CopyFolder\<SID>_YYYYMMDDHHMMSS.trn'.
Note its name.
10. Find in the Copy folder TRN files with greater timestamps and restore those files manually
with a series of commands like follows:
RESTORE LOG <SID>
FROM DISK = '\\copy_share\CopyFolder\<SID>_YYYYMMDDHHMMSS.trn'
WITH NORECOVERY
Note, the TRN files must be processed in sequence in a strict chronological order, otherwise
an error is thrown. Should it happen, find the correct TRN file and proceed with the restore.
11. Proceed with the section Completing failover on page 16.
In this scenario a simplified fail back (see Fail back on page 17) is not possible.
To fail over to the Secondary server without data loss the following actions must be done:
1. Immediately suspend Log shipping as described in Suspend Log Shipping on page 18 and
note the time when it was done. This crucial point will be referred as LS_STOP below.
2. Inform end users about an urgent SAP System shutdown and stop the system.
14
Database Log Shipping on Microsoft SQL Server
3. Identify the point in time when the user error was committed. If it cannot be identified precisely,
take the earliest time it might have happened. It will be referred as TIME_ERROR. Convert
TIME_ERROR to UTC time, let’s call it TIME_ERROR_UTC.
4. Let us call the difference between LS_STOP and TIME_ERROR as reaction time. If the
reaction time is greater then the restore delay, the user error has already been applied to the
Secondary DB. The error must be corrected by means of restore the DB from regular backups.
Otherwise proceed with the next steps.
5. Log on to the Secondary server with SQL Management Studio
6. Identify the last TRN file used for restore: right click the Restore job, choose “View history”,
expand the recent history record. The step logs are displayed in reverse chronological order.
Find the topmost step containing the message
“Restored log backup file. Secondary DB: '<SID>', File:
‘\\copy_share\CopyFolder\<SID>_YYYYMMDDHHMMSS.trn'.
Note its name.
7. Find in the Copy folder TRN files with greater timestamps, but not exceeding
TIME_ERROR_UTC and restore those files manually with a series of commands like follows
RESTORE LOG <SID>
FROM DISK = '\\copy_share\CopyFolder\<SID>_YYYYMMDDHHMMSS.trn'
WITH NORECOVERY, STOPAT = '<date_time>'
where <date_time> should be 1 minute before TIME_ERROR. Adhere to the full date and
time format ‘YYYY-MM-DD HH:MM:SS’, e.g. '2007-05-24 09:59:59'.
Note, the TRN files must be processed in strict chronological order, otherwise an error is
thrown. Should it happen, find the correct TRN file and proceed with the restore.
8. Proceed with the section Completing failover on page 16
Maintenance scenario
In this case the Primary server must be stopped for a substantial period of time while the SAP system
must go on running. In this scenario no committed data is lost.
To fail over to the Secondary server without data loss the following actions must be done:
1. Suspend Log shipping as described in Suspend Log Shipping on page 18.
2. Inform end users about an SAP System shutdown and stop the system.
3. Close all connections to <SID> database. You can check for them in Management Studio
under “Management” -> “Activity monitor”.
4. Back up the active transaction log on your primary server with option NORECOVERY. That
leaves the Primary DB in “restoring” state, where it is unavailable, but is prepared to simplified
fail back (see Fail back on page 17). The command is as follows:
USE master
BACKUP LOG <SID>
TO DISK =
'\\backup_share\BackupFolder\<SID>_YYYYMMDDHHMM_tail.trn'
WITH NORECOVERY
5. Copy the tail transaction log backup file from the Backup folder to the Copy folder.
6. Log on to the Secondary server with SQL Management Studio
7. Start the Copy Job. It can be found under <Server> -> SQL Server Agent -> Jobs.
By default, its name is “LSCopy_<Primary server name>_<SID>”. Right click the job name
and choose “Start job at step…”.
8. When the copy job is finished, start the Restore job. By default, its name is
“LSRestore_<Primary server name>_<SID>”. Right click the job name and choose “Start job
at step…”.
9. If the restore delay is not used, proceed with step 12.
10. Identify the most recent TRN file used for restore: right click the Restore job, choose “View
history”, expand the recent history record. The step logs are displayed in a reverse
chronological order. Find the topmost step containing the message
“Restored log backup file. Secondary DB: '<SID>', File:
‘\CopyFolder\<SID>_YYYYMMDDHHMMSS.trn'.
Note its name.
15
Database Log Shipping on Microsoft SQL Server
11. Find in the Copy folder TRN files with timestamps greater then the last restored TRN file and
restore those files in sequence with a series of commands like follows:
RESTORE LOG <SID>
FROM DISK = '\\copy_share\CopyFolder\<SID>_YYYYMMDDHHMMSS.trn'
WITH NORECOVERY
Note, the TRN files must be processed in strict chronological order, otherwise an error is
thrown. Should it happen, find the correct TRN file and proceed with the restore.
12. Restore the tail log TRN file with the command
RESTORE LOG <SID>
FROM DISK =
'\\copy_share\CopyFolder\<SID>_YYYYMMDDHHMMSS_tail.trn'
WITH NORECOVERY
13. Proceed with the section Completing failover on this page below.
If all actions are done correctly, there is a possibility to fail back very fast without copying the database
back to the Primary server (see Fail back below).
Completing failover
Independently from a failover scenario you have to execute the following actions to complete a
failover process.
1. Issue the command:
RESTORE LOG <SID> WITH RECOVERY
This brings the database online and it can be used with the SAP System.
2. Execute the procedure, fixing mappings between SAP SQL users and server logins:
use master;
exec sp_check_sap_login <SID>, <schema>, <Windows domain>, repair;
Where <schema> is the current DB schema (see SAP note 98678),
<Windows domain> is the domain of standard SAP users <sid>adm and SAPService<SID>,
‘repair’ is the keyword instructing to perform the correcting actions.
3. Copy the prepared SAP default profile file into DEFAULT.PFL in the folder
<drive>:\usr\sap\<SID>\SYS\profile
copy DEFAULT_SECONDARY.PFL DEFAULT.PFL
overwriting the existing file.
4. Correct environment variable MSSQL_SERVER on each application server as per Prepare
SAP System to failover, point 3 on page 11.
5. Start the SAP System.
16
Database Log Shipping on Microsoft SQL Server
Fail back
Fail back is a process of moving the database service back to the original Primary server. It can be
necessary by various reasons, for example:
The original Secondary server is equipped with less powerful hardware and cannot permanently
withstand working load with satisfied quality of service.
The original Secondary server must be freed for another role, e.g. DB server for QAS or training
system
Fail back should be carried out after the original problem on the Primary server has been solved.
There are 2 possibilities to fail back:
1. Simplified fail back without moving the database. This is only possible in case of a maintenance
fail over. It can be done within a couple of minutes.
2. Regular fail back with moving the whole database. It needs to be executed in all other scenarios.
As this fail back requires a full database backup and restore, it may take many hours to complete.
The system is however not necessarily down during that time.
1. If the original Primary server is lost and must be set up from scratch, refer to the chapter SQL
Server prerequisites on page 7.
2. If the previous fail over was done as per Maintenance scenario (see page 15) and the originally
Primary DB is in “restoring” state, proceed to step 4. Otherwise continue with 3.
3. Back up the original Secondary DB and restore it onto the originally Primary Server as described
in Preparations on page 8. This step may take a lot of time.
4. Configure Log Shipping as described in Configuring Log Shipping on page 9, with the only
difference: now under “Primary” the originally Secondary server is meant and vice versa.
Note: use the same share for Backup folder that you used for the original log shipping.
On this stage there are two configured Log shipping processes. For further reference let’s call them
Primary-to-Secondary and Secondary-to-Primary based on original roles of the servers.
The Primary-to-Secondary Log shipping is now suspended.
The Secondary-to-Primary one is active.
Failing back
1. Fail over from the originally Secondary server to the originally Primary one as described in
Maintenance scenario on page 15, except of step “Copy the prepared SAP default profile…”
during completing failover. On that step copy the original SAP default profile file into
DEFAULT.PFL in the folder <drive>:\usr\sap\<SID>\SYS\profile
copy DEFAULT_PRIMARY.PFL DEFAULT.PFL
overwriting the existing file.
2. Resume Primary-to-Secondary Log shipping as per Resume Log Shipping on page 19.
17
Database Log Shipping on Microsoft SQL Server
To call Log Shipping status using SQL Management Studio as of Support Pack 2 (SP2):
1. Start SQL Management Studio, connect to a server.
2. Right click on the server name and choose “Reports” -> Standard reports -> Transaction Log
Shipping Status.
To call Log Shipping status with a Monitor server using SQL Management Studio earlier then SP2:
1. Start SQL Management Studio, connect to a server.
2. Select the server instance in Object Explorer.
3. In the “Object Explorer Details” page, display the list of available report types by clicking the
arrow next to the «Reports» button. If the Object Explorer Details page is not displayed, select
Object Explorer Details on the View menu.
4. Click “Transaction Log Shipping Status”.
18
Database Log Shipping on Microsoft SQL Server
19
Database Log Shipping on Microsoft SQL Server
The copy and restore jobs rely on correct timestamps in the file names. That’s why the primary and
secondary servers must have synchronized system clocks. Either Windows Time Service in a domain or a
network time protocol should be used for that.
If system clocks must be adjusted, it is recommended to suspend log shipping and resume it afterwards.
As a matter of fact, the newly created file may be very large, several dozen or even hundred gigabytes. If
the path exists by accident, the file will be created successfully. If the appropriate disk doesn’t have
enough space or it is undesirable to put the new file to that folder, the following actions must be done:
If the described procedure was not adhered to and the restore job has failed already, the DB administrator
can still execute step 5 for the failing TRN file.
SQL Jobs
Some SAP Basis functions are implemented as scheduled SQL Jobs. They are listed in General post-
failover actions on page 16. Customers also may define own SQL jobs using standard tools (SQL Studio)
or third-party tools. All those jobs are stored in a standard database msdb, which is separate from <SID>.
As a result, any change in the jobs will not be automatically shipped to the Secondary server and should
be rescheduled by necessity on the Secondary server manually.
20
Database Log Shipping on Microsoft SQL Server
Q2. Can Log Shipping coexist with SQL Server database mirroring?
A2. Yes. A detailed explanation is out of scope of the document. Please refer to Microsoft Books Online,
article Database Mirroring and Log Shipping (http://msdn2.microsoft.com/library/en-us/53e98134-e274-
4dfd-8b72-0cc0fd5c800e.aspx).
Q3. What is a file with extension TUF, found in the Copy directory?
A3. The TUF file is the Transaction Undo File, and is created when performing log shipping to a server in
STANDBY mode of a database on page 5.
Q4. How a normal DB backup and TL backup on durable media (backup tapes) should be organized? Can
SAP transaction DB13 (DBACOCKPIT/DBA Planning Calendar) coexist with Log Shipping?
A4.The Primary database can be backed up with any tool, including DB13. However no transaction log
backups other then Log Shipping are allowed. That’s why the functionality of DB13 may not be used. This
is also valid for any third party backup software as well as for manual transaction log backups.
Q5. After somebody unintentionally switched the DB to SIMPLE recovery mode and then immediately
back to FULL, the Log shipping Restore Job is failing. How to fix it?
A5. The current Log Shipping must be removed and then set up again including full DB backup and
restore, because the transaction log backup chain is broken.
Q6. Because of error 9002 “Transaction log full” the DBA administrator backed up the log manually with
the option NO_LOG or TRUNCATE_ONLY. Afterwards the Log shipping Restore Job is failing. How to fix
it?
A6. The current Log Shipping must be removed and then set up again including full DB backup and
restore. The correct procedure in case of error 9002 would be to start the Log Shipping Backup job
immediately.
Q7. After somebody unintentionally deleted some TRN files from the copy folder, the Log shipping Restore
Job is failing. How to fix it?
A7. Check if the deleted files are still in the Backup folder. By default they are retained there for 3 days. If
yes, copy them manually to the Copy folder. If the files have already been deleted, the current Log
Shipping must be removed and then set up again including full DB backup and restore.
21
Database Log Shipping on Microsoft SQL Server
Appendix
22