The system copy
We take over your SAP system copies as a service
Security-conscious companies usually keep their mission-critical IT infrastructures redundant anyway. Storage systems are usually secured in disk arrays by multi-level raid, spatially separated from each other and networked by a storage area network (SAN). Connected to this are at least two computers, also spatially separated. One of these acts as a backup system.
Even if the target system is not used for production in an update scenario based on a system copy, it is of central importance for developers and thus also the software lifecycle of the production system. That's why you should avoid upgrade downtime in both the production source system and the non-production target system. Production system downtime depends primarily on the method you use to create the image of the production data to be used in the target system. This image must be a transferable database image - for example, a database export, a backup copy, or an array-based reconciliation. To eliminate downtime in the production system and minimize the impact on application performance-regardless of the size of the production data reconciliation-you can use, for example, HP StorageWorks System Copy for SAP (HP System Copy), which has a disk array-based replication capability. Downtime in the target system depends on the following factors, among others: The time required to restore production data reconciliation in the target system The amount of pre- and post-processing in the target system With HP System Copy, images of production data can be created in minutes, with each step between shutdown and reboot of the target system occurring automatically. However, after the reboot, the target system is not immediately ready for use, as additional steps must first be performed (see description below).
SAP system clone and copy
Shutting down and copying virtualized systems, such as VMware instances, requires just a few mouse clicks. VMware is suitable for running multiple training, development and test environments on one physical system. Larger productive systems, on the other hand, are not so easy to virtualize. If users have to shut down the productive system during the copy, the runtime of the operation or the unavailability of the productive system becomes a critical factor.
SAP upgrade: Before a very extensive SAP upgrade, you may want to test the run and analyze any errors that occur, especially if the development and test systems are not allowed to be down for too long. In that case, it's best to do this on a system copy.
With "Shortcut for SAP Systems" any tables can be saved and restored. This is especially useful in the context of an SAP system copy - quite a few tables are system-specific and must exist unchanged in the system after a system copy.Shortcut for SAP Systems uses R3trans - a utility from SAP that is essentially used in the Transport Management System (TMS) environment. With "Shortcut for SAP Systems" it is now also available outside the TMS and enables completely new and diverse application possibilities. Among others in the environment of a system copy. R3trans works database independent. I.e. even in the case of a system refresh from an SAP system with an Oracle DB to a system with HANA, the backup and restore process works!
The use of a comprehensive dashboard will then also be included.
Until now, it has been common practice to create test systems as a client or system copy of the production system on a specific date.