SAP Operations
SAP System Copy and Refresh Basics: A Practical Operations Runbook
A practical guide to planning, executing, and validating an SAP HANA on-premise system copy or refresh from production to a non-production environment.
A system copy creates a target SAP environment from a source system, while a refresh replaces target data with a newer source copy. In SAP HANA on-premise operations, the database copy is only one part of the work: interfaces, host identities, scheduled jobs, users, certificates, integrations, and business data handling also require controlled treatment.
Use a written runbook with named owners, approved downtime, recovery checkpoints, and validation evidence. The runbook should identify the source and target systems, database tenants, application servers, HANA hosts, operating-system users, network endpoints, and dependent services.
Copy and refresh purpose
A copy is useful when a new environment is required for testing, development, troubleshooting, or a controlled technical rehearsal. A refresh updates an existing non-production environment with a selected source snapshot while preserving the target system's intended role and configuration decisions.
A production-to-test refresh can improve test-data relevance, but it also transfers operational and personal data. Define the permitted data set, retention period, access group, and anonymization requirement before the technical work begins. The target must have a clear owner who accepts the resulting data risk.
Plan the source and target
Record the source system identifier, target system identifier, HANA system number, instance number, host names, tenant databases, storage locations, backup sets, and connectivity requirements. Confirm that the target has sufficient capacity for the selected copy and that the required software media, licenses, credentials, and encryption key material are available.
Review the target's current role before scheduling the refresh. List inbound and outbound interfaces, RFC destinations, webhooks, file exchanges, printers, batch schedules, monitoring integrations, and identity-provider connections. Prepare a disablement and re-enablement sequence so the refreshed target cannot accidentally send production messages or process live business events.
For lifecycle and landscape planning, coordinate the refresh with the SAP version check guide and review planned maintenance dependencies in the SAP maintenance planner guide. These checks help align the target software level and maintenance window with the wider landscape.
Prepare backups and controls
Take and verify the backups required to recover the source and target according to the approved recovery plan. Include database backups, configuration exports, relevant application files, interface configuration, certificates, and target-specific settings that must be restored after the refresh.
Protect HANA encryption material as part of the preparation. Data volume encryption, log volume encryption, and backup encryption are configured separately. Back up the root keys before the operation and back them up again after every change. A changed backup encryption root key that was not backed up makes the backup unrecoverable.
Define the change record, communication plan, technical checkpoints, abort criteria, and evidence requirements. A useful checkpoint records the timestamp, operator, command or tool action, result, and next decision.
Execute the technical copy
Use the documented procedure appropriate to the selected copy method, operating system, storage design, and SAP application stack. Keep source and target credentials, paths, host mappings, and database names explicit in the runbook. Preserve the target's required system identity and apply the approved target-specific configuration after the data movement.
For SAP HANA on-premise, verify the system database and tenant databases separately. HANA cockpit and SAP HANA database explorer are useful for checking database availability, services, alerts, users, and configuration after the copy. A whole-system stop or start affects the complete SAP HANA system and all tenants; a single tenant is managed separately from the system database when that is part of the approved procedure.
Capture logs from the copy tooling, operating system, database, and application layer. Do not close the technical step based only on a successful command return code; confirm that the expected databases, services, volumes, and application processes are available.
Reconnect the target safely
Keep external communication disabled until target identity and routing checks are complete. Update target-specific host names, virtual host mappings, certificates, RFC destinations, logical endpoints, file-transfer locations, email settings, and monitoring destinations according to the target design.
Review background processing before releasing users. Check scheduled jobs, event-driven processing, workflow queues, outbound IDocs or messages, integration middleware, and batch file directories. Release only the jobs and interfaces approved for the target environment.
Use the support package application guide when the refresh is combined with maintenance work, and use the EarlyWatch Alert operations guide when you need a structured post-operation review of system health and operational risks.
Anonymize copied data
Treat production-derived data as sensitive until the approved protection process is complete. Data anonymization should cover the fields and datasets defined by the organization's privacy assessment, including customer, supplier, employee, contact, authentication, and financial information where applicable.
Use an approved, repeatable method that preserves the relationships and formats required for testing while preventing unauthorized identification. Document the method, execution result, exceptions, and validation sample. Masking only a visible subset of records does not establish that the full target data set is protected.
After anonymization, test application behavior with representative scenarios. Confirm that users can perform the required business processes, that integrations receive safe test values, and that support teams understand which data has been transformed.
Validate the refreshed system
Validation should cover infrastructure, HANA, application processing, security, integrations, and business workflows. Record evidence rather than relying on informal confirmation.
- Confirm all expected HANA databases and services are online.
- Review HANA cockpit alerts and relevant database diagnostics.
- Verify storage, backup configuration, log handling, and encryption-key access.
- Test application login, authorization, and representative transactions.
- Confirm that target interfaces point to test endpoints and that prohibited production routes remain disabled.
- Check scheduled jobs, queues, batch files, printers, and outbound communication.
- Validate anonymization results with an approved sample and access review.
- Obtain acceptance from application, security, integration, and operations owners.
The system copy and refresh checklist can serve as the landscape reference for keeping these activities together in one operational sequence.
Close the operation
Close the change only after the target owner accepts the system and the evidence package is complete. Store the copy logs, backup identifiers, encryption-key backup confirmation, anonymization record, validation results, exception approvals, and final interface state.
Update the system inventory, monitoring ownership, support contacts, recovery documentation, and next refresh date. Record target-only changes separately from source-derived content so the next refresh team can decide what must be preserved, reapplied, or reviewed.
A repeatable refresh process reduces downtime and prevents the most damaging operational outcomes: accidental production communication, uncontrolled exposure of copied data, and an unrecoverable backup caused by missing encryption-key protection.