Recover a CounterPoint Database Webinar: Radiant Webinar Mini-Series for Implementation Technicians To connect to phone conference, please call: 1.800.375.2612, and then enter Participant Code: 397670 (or listen via computer speakers)
Please welcome today s Presenter Shawn Hefner Specialty Retail Consulting Analyst (Professional Services) With Radiant since 2007 Worked with CounterPoint since 1999 Supports Partner Channel Services 2
Learning Objectives To receive implementation-specific informational updates to enable you to effectively deploy Radiant Specialty Retail Solutions for Customers. 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 3
Identify which systems are critical to the business
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 Backup Supply 5
Determine how long you can be without each system
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 Network Failure 7
Develop contingency plan for each critical system
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 Redundancy Methods within SQL 9
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. 10
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 GO 11
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 12
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 Database backups/transaction Log Backups should still be used. 13
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. 14
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. Database backups/transaction Log Backups should still be used. 15
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. 16
Implement and communicate the plan
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 18
Recap 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 What s Next? Ensure your customers know what to do or who to contact in the event of a critical system failure Document your recovery procedure for each customer 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? 19
Final Review: Learning Objectives To receive implementation-specific informational updates to enable you to effectively deploy Radiant Specialty Retail Solutions for Customers. 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 20
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 Thurs., 7/29 from 1-2pm ET: Compare Multiple Site Deployment Options 21
Thank you for participating in today s Retail Training Webinar! An online evaluation survey will be displayed privately to you shortly