One Backup strategy defines how data is backed up, with what frequency, where the backups are stored, and how they are restored in the event of an emergency. The objective is to achieve the two central key figures RPO (Recovery Point Objective — maximum tolerable data loss) and Regional Transport Office (Recovery Time Objective - maximum allowable downtime) to be met.
Context
A typical mid-market strategy includes: (1) Full Backup the Database once daily within a maintenance window, (2) Transaction log backups on SQL or Log-backups on HANA every 15-30 minutes, to enable point-in-time recovery, (3) File backup the SAP B1 attachment directories, Crystal Reports templates, B1if configurations, and Coresuite/VFS installation folders, (4) Configuration backup from SLD settings, license file and HANA/SQL system objects. Backups should ideally be kept geographically separate (e.g. local plus a second site or cloud target) and organised according to the 3-2-1 principle: three copies, two media types, one offsite location. Archiving add-ons such as CKS.DMS have their own archive databases which must also be backed up depending on the configuration; with an integrated archive database, backup management is simplified but creates large data volumes. Regular restore tests are part of the strategy – a backup that has never been restored is not a verified backup.
Demarcation
A backup strategy is not a high availability solution: for failover within minutes, HANA System Replication, SQL Always-On or cloud HA clusters are needed, not backups. Nor does it replace the Archiving obligation after GoBD — Accounting documents and emails must be archived in a tamper-proof and audit-proof manner, and that is not the same as a database backup. Compared to a pure tenant copy, the backup is the backbone in an emergency; the tenant copy is a working tool for tests and upgrades.
ReAct and RLEF: How Artificial Intelligence Learns from Real Mistakes — and What Automated Bank Reconciliation in SAP Business One Has to Do with It
SAP B1 10.0 FP2608: Service Layer AI as a transactional layer
Process Reward Models: Why a correct result does not yet prove a correct method
Test-Time Compute Scaling: Why a Smaller AI Model Can End Up Winning — and What Supplier Comparison in SAP Business One Has to Do With It
RLHF and reward models: AI hype or what the approval process in SAP Business One has to do with it
