Webinar: Radiant Webinar Mini-Series for Implementation Technicians
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
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
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
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
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
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.
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
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
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
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.
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.
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.
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
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
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
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
An online evaluation survey will be displayed privately to you shortly…
