-itim-incident-management

1. Presented by
Mr. Manish Tripathi ( I – 15-18-19)
Thakur Institute of Management Studies
&
Research
(Sunday 30 July, 2017)
1
ITIM Incident Management
Deletion of Database data and its restoration

2. THE INCIDENT
• I am the database administrator of SQL database
responsible for its administration, backup, security,
maintenance and all related activities
• I receive a call from an application owner that at
3.10 PM a wrong query has been run in a crucial
master database and because of that important
data has been deleted / altered
• Because of criticality of data, the incident is report
to GM (IS)
• I have been given the task of restoring back the
data 2

3. SQL SERVER LOG SHIPPING
• Log shipping is the process of automating the
backup of a database and transaction log files on a
primary (production) database server, and then
restoring them onto a standby server
• This technique is supported by Microsoft SQL
Server, 4D Server, MySQL, and PostgreSQL
• The primary purpose of log shipping is to increase
database availability by maintaining a backup
server that can replace production server quickly
• Actual failover mechanism in log shipping is
manual 3

4. SQL SERVER LOG SHIPPING
• The transaction log backups are applied to each of
the secondary databases individually
• Monitor server records the history and status of
backup and restore operations and, optionally,
raises alerts if these operations fail to occur as
scheduled
4

5. 5

6. LOG SHIPPING CONFIGURATION
• Primary server: main production SQL server in
Mumbai
• Secondary server: DR server in greater Noida
• Transaction log backup: 15 minutes
• Copy to secondary server: immediately
• Apply transaction long: 24 hours
6

7. BENEFITS OF LOG SHIPPING
• Provides a disaster-recovery solution for a single
primary database and one or more secondary
databases
• Supports limited read-only access to secondary
databases (during the interval between restore jobs)
• Allows a user-specified delay between when the
primary server backs up the log of the primary
database and when the secondary servers must
restore (apply) the log backup. A longer delay can be
useful, for example, if data is accidentally changed on
the primary database. If the accidental change is
noticed quickly, a delay can let you retrieve still
unchanged data from a secondary database before the
change is reflected there
7

8. HOW INCIDENT WAS MANAGED
• Primary database taken offline so that it can not
be changed
• At the secondary Database , all transaction logs
applied manually up to 3 PM ( a careful and time
consuming job)
• Secondary Database is made online
• Backup of secondary Database is taken and copied
to primary server
• Backup of Primary database is taken
• Primary database is restored from the backup of
secondary Database
• Loss of data from 3 PM to 3.10 PM
8

9. LEARNINGS FROM THE INCIDENT
• Incidents can happen even when due care is taken
• We should be proactively ready to deal with the
incidents
• A good DR strategy must be in place beforehand
9

10. 10