A boon for small and medium sized businesses, SAP Business One is an ERP solution with a focus to automate business functions like financial management, operations management, and human resource management. Its architecture is a typical client-server model where client software is a Microsoft Windows-based product that connects with back-end server whereas server software runs on Microsoft SQL server database or SAP HANA Database. Though the tool comes with several benefits that we have listed below, it also requires a comprehensive disaster recovery plan.
Key Benefits of SAP Business One
- Customer relationship management
- Marketing campaign management
- Opportunity and sales activity management
- Integration between CRM and inventory
- Gain customer insights
- Management of customer warranties, service contracts, and service calls
- Integrate with Microsoft Outlook
- SAP Business One mobile app
- Carry out efficient reporting and analytics
Why do you need a Disaster Recovery Plan?
Disaster due to application failure, cyber attack or any calamity causes downtime and massive monetary loss to the business. It brings the business to a halt. At times, data loss and downtime is so long and severe that it causes irretrievable loss to company reputation. In such a scenario, it is vital to secure a robust disaster recovery plan. SAP Business One is a mission-critical application. Foolproof disaster recovery not only ensures cost savings but is also seen as a survival strategy.
Disaster Recovery Technology for SAP Business One
Among various disaster recovery options, cloud technology has played an important role, especially for small and medium sized businesses. Disaster recovery options give businesses a flexibility to choose from and plan accordingly. Disaster recovery in SAP environment refers to the copying of the database log files.
Information managed by SAP is stored in the database. Consequently, any change to the database is represented in the logs. When you send log files to a remote server allocated for disaster recovery, you are able to retrieve all the information when required.
There are two ways of putting recovery technology in place:
In this case, the database at the main site stays unchanged until it receives information from disaster recovery site that the database there is updated.
Here the database at the main site is allowed to make changes irrespective of changes updated at the disaster recovery site. The changes are later sent to disaster recovery site creating a lag between the main site and the disaster recovery site.
Managing RPO for SAP Disaster Recovery
Disaster recovery plan must be executed by establishing Recovery Point Objective (RPO). RPO refers to the maximum targeted period of time in which data might be lost due to disaster or how much data can you afford to lose in case of a disaster. Establishing RPO depends on disaster recovery solution. For instance, in the traditional approach, RPO depends on the size of your database logs. For big logs, you need a big RPO.
Checklist for SAP Business One Disaster Recovery
Let us briefly introduce commonly used disaster recovery options:
Traditional data recovery for SAP
In the traditional method, there are two identical servers: one at the main data center and the other at the disaster recovery site. Here you gather database logs at the primary center and send them over the network to the disaster recovery center. A high cost of ownership and poor uptime speed should render traditional approach a less favorable option. However, many businesses stick to it because it works well for them.
Disaster recovery to public cloud
Public cloud services like Amazon Web Services are often chosen by businesses with less frequent changes at web server level, front-end application or interface applications. Here the data back-up is done on the public server and updated once in a while as and when necessary. This is an economical option as the server is used only when required as in the event of a disaster or update.
However, when running SAP Business One, your database should always be in sync with the server and send updates. However, due to security concerns, the public cloud is not the right option for everyone. Businesses with limited budgets often go for this option or when other options are costly.
Disaster recovery using VMware SRM
In contrast to traditional disaster recovery method as mentioned above which relies on database-level replication by sending the log files; VMware Site Recovery Manager performs a full server replication. Here additional files created as part of SAP operations are also replicated to the disaster recovery site.
When you use VMware SRM, a VMware farm is created on your primary datacenter as well on the Disaster Recovery site. VMware SRM replication is replicated across the two farms which allows for a quick recovery time objective (RTO) to restore a business process post disruption. Besides, it enables you to store all the files not dwelling within the database.
HANA-specific disaster recovery
HANA runs on its own application server with its own replication method using HANA replication tool. This tool replicates the entire HANA appliance to another site. To replicate HANA from the main datacenter to a disaster recovery site, you need two operational HANA database, one at the main datacenter and the other at the recovery site.
The advantage of using this method is the excellent speed and performance offered by HANA replication. However, it is always better to use asynchronous solution during replication to ensure HANA database function is not interrupted. Though expensive, HANA-specific disaster recovery is the best recovery option often used by customers already running SAP HANA. Check out whats there in SAP HANA 2.
One size does not fit all
Disaster recovery solution depends on customer’s existing facilities, the level of security required and budget. Accordingly, a suitable solution can be implemented. Many customers tend to use traditional approach owing to its reliability. However, when there is no budget constraint, it is always better to go for superior solutions like VMware SRM.
Implementing a VMware solution needs a virtualized SAP environment and if a customer is still running SAP on physical servers and not planning virtualization, then VMware solution is immaterial. SAP Business One is a great product but you need a disaster recovery plan to ensure you are safe. Irrespective of what you choose, it won’t be incorrect to state that a company without a disaster recovery plan is heading toward a disaster.