Recover a CounterPoint Database

22  Download (0)

Full text

(1)

Webinar: Radiant Webinar Mini-Series for Implementation Technicians

(2)

Retail Training & Certification Services Confidential & Proprietary Information of Radiant Systems, Inc., July 2009 v1.0

Please welcome today’s Presenter …

Shawn Hefner

Shawn Hefner

 Specialty Retail Consulting Analyst

(Professional Services)

 With Radiant since 2007

 Worked with CounterPoint since 1999

 Supports Partner Channel Services

(3)

Learning Objectives

After completing this webinar, you should be able to:  Identify which systems are critical to the business  Determine how long you can be without each system

 Develop a contingency plan to operate while each critical system is unavailable  Implement and communicate the plan

(4)
(5)

Overview



Disaster Recovery is a plan for continuing business in the event of a system

failure.



Identify what systems are critical to your business and how long you can be

without that system.

● CounterPoint

● Database

● Other Applications

● Internet connection

● Phone lines (credit card authorization)

● Power

(6)
(7)

Possible Systems

 Phone lines

● Is it VOIP / Digital lines?

● Do you need your Router?

● How long do you need it to last?

 Server Failure

● Parts break down ● Hard drive Crashes ● Corruption

 Workstation Failure

 Power Loss

(8)
(9)

Contingency Plan

 Offline V2

 Manual Tickets/Call In Credit Cards

 Terminal Server to another location

 Phone Lines

● Hardwired Line for Backup

● Emergency Cell Phone

 Power Loss ● Battery Backups ● Emergency Generators  Servers ● Replacement parts Ø 1 Day Turnaround ● Hard drive Crashes

Ø Redundancy

Ø Backups

● Database Crashed

Ø Backup to the last 15 minutes

 Backups

(10)

Retail Training & Certification Services Confidential & Proprietary Information of Radiant Systems, Inc., July 2009 v1.0

Backups

 Top Level Files

● Generally once per day

 Full Database Backup

● Generally once per day ● Keep multiple days

 Transaction Log Backup

● Only if database is in Full Recovery mode

● How much data can you afford to loose?

Ø Credit Cards

● Often as frequent as every 30 minutes

● Only good until the next database backup

 Backups should not reside on the same system that is backing them up.

 Offsite backups should be in a secure location (safe deposit box)

 Restoring Database Backups

● Brings the database back to the point in time of the backup.

 Restoring Transaction Logs

● Can be restored in sequential order after restoring database backup

● Each log applies transactions that occurred during that period of time since the full database backup.

(11)

Restore Log Example

Use CPSQL GO

/* Kill Connected Database Users to Get Exclusive Access For Database Restore*/ EXEC sp_KillDatabaseUsers 'CPSQL'

GO

/* Restore CPSQL Database Using Full Database Backup */ RESTORE FILELISTONLY

FROM DISK = N'C:\DatabaseBackups\ CPSQL_FULL.BAK' GO

RESTORE DATABASE [CPSQL]

FROM DISK = N'C:\DatabaseBackups\CPSQL_FULL.BAK' WITH

MOVE N' CPSQL' TO N'C:\DatabaseFiles\CPSQL.mdf',

MOVE N' CPSQL_Log' TO N'C:\DatabaseFiles\CPSQL_Log.ldf', NORECOVERY, NOUNLOAD, REPLACE, STATS = 20

(12)

Retail Training & Certification Services Confidential & Proprietary Information of Radiant Systems, Inc., July 2009 v1.0

Restore Log Example (Cont’d)

/* Restore CPSQL Database Using The First Transaction Log */ RESTORE LOG [CPSQL]

FROM DISK = N'C:\DatabaseBackups\CPSQL_LOG1.TRN' WITH NORECOVERY, STATS = 20

GO

/* Restore CPSQL Database Using The Second Transaction Log */ RESTORE LOG [CPSQL]

FROM DISK = N'C:\DatabaseBackups\CPSQL_LOG2.TRN' WITH NORECOVERY, STATS = 20

GO

/* Restore CPSQL Database Using Tail Log */ RESTORE LOG [CPSQL]

FROM DISK = N'C:\DatabaseBackups\CPSQL_TAIL_LOG.TRN' WITH RECOVERY, STOPAT = 'Oct 22, 2009 00:06:50 AM'

GO

/* Check tables to make sure the information is there */ USE CPSQL

GO

SELECT * FROM PS_DOC_HDR GO

(13)

Database Mirroring

 Database Mirroring is SQL Server option to keep a database synchronized on two servers.

● Queue transactions, with manually failover

Ø Defaults to 1 minute

● Immediately commit transactions on both sides (Full Safety) with manual failover

● Immediately commit transactions on both sides (Full Safety) with automatic failover (High Availability).

Ø Requires a third “witness” server

 Can provide real time failover or manually, through running a SQL script

 Only one database can be used at a time: the principal is active and the partner is not

accessible at all.

 Requires Full Recovery and custom maintenance scripts

(14)

Retail Training & Certification Services Confidential & Proprietary Information of Radiant Systems, Inc., July 2009 v1.0

Log Shipping

 Log shipping is a SQL Server function to keep a backup database server in sync.

 Transaction logs are copied (shipped) and applied to a redundant server on a schedule

(typically 15-60 minutes).

 The database is read only on the backup server.

 A SQL script must be used to enable the backup server.

 CounterPoint Companies.ini must be redirected to the backup server.

 Database must use Full Recovery

 Database backups/Transaction Log Backups should still be used.

(15)

SQL Cluster

 A SQL Cluster is at least two servers using shared drive storage.

 The two servers have a “heartbeat” constantly checking to see if the other is online.

 In most cases, one is active and the other server is inactive (passive) unless the

heartbeat fails.

 No data loss since they run on the same hard drive.

 About 2 minutes to fail over (depending on hardware)

 Requires specialized hardware (SAN)

 No intervention required for failover.

(16)

Retail Training & Certification Services Confidential & Proprietary Information of Radiant Systems, Inc., July 2009 v1.0

PeerDirect Replication

 PeerDirect is used for the Multi-Site option in CounterPoint.

 Data is replicated to other sites. Sites can have only their specific data or all data.

 A site with all data can be used as a Disaster Recovery Site.

 Database backups/Transaction Log Backups should still be used.

 Regbackup should be used to backup PeerDirect registry keys at all sites.

 If a PeerDirect database is restored, dresetdb should be used to avoid PDRE GUID

conflicts.

(17)
(18)

Retail Training & Certification Services Confidential & Proprietary Information of Radiant Systems, Inc., July 2009 v1.0

Contingency Plan

 Implement contingency plan

 Test plan

● Drop the power

● Kill the Network Connection

● Try a test restore

 Document plan

● Put it in writing and tell everyone where it is located

 Train employees on plan

● Ask them questions

● Make sure they understand the plan

● Get their feedback

 Plan to revisit the plan for changes

(19)

Recap

Key learning highlights:

Key learning highlights:

● Build a contingency plan for each critical system

● Combine database backups and a failover option to ensure rapid recovery

● Document and train on the recovery plan

Discussion Questions

Discussion Questions

● Do you have a recovery plan implemented for each customer?

● What have you done to ensure that someone can act as your backup in the event of recovery?

What’s Next?

What’s Next?

● Ensure your customers know what to do or who to contact in the event of a critical system failure

(20)

Retail Training & Certification Services Confidential & Proprietary Information of Radiant Systems, Inc., July 2009 v1.0

Final Review: Learning Objectives

20

Having completed this webinar, you should be able to:  Identify which systems are critical to the business  Determine how long you can be without each system

 Develop a contingency plan to operate while each critical system is unavailable  Implement and communicate the plan

(21)

Schedule Preview:

Webinar Mini-Series for Technicians

 Thurs., 6/17 from 1-2pm ET: Import & Export Data

 Thurs., 7/1 from 1-2pm ET: Upgrade From CounterPoint V7 Part 2

 Thurs., 7/15 from 1-2pm ET: Configure and Use Dashboard

(22)

An online evaluation survey will be displayed privately to you shortly…

Thank you for participating

Figure

Updating...

References

Related subjects :