For application teams (SAP Basis administrators, SAP application administrators, and SAP application owners), all infrastructure is usually just a commodity, especially storage. It wasn’t until I joined Pure that I began to realize that the infrastructure under the SAP platform could seriously start to change the game when it came to managing the complex SAP layer above it.
Save the Day with Snapshots
In this day and age, it’s usually not infrastructure problems that bring down SAP systems—it’s people. Snapshots can change the game when it comes to quickly recover from common, people-driven mistakes. They’re especially handy in a test environment where you don’t necessarily need full data protection and can get by with a crash-consistent snapshot. With Pure, you can schedule and retain snapshots for as long as you want. That means that if someone accidentally drops a Z-table, you just need to know the rough time frame when it happened and you can go back into your snapshots to find it. Likewise, you don’t need to overwrite the system to recover. Simply restore the snapshot to a separate system to recover the data, and you won’t disrupt anyone else who’s working in the test environment.
Simplify Data Conversions
Data is the lifeblood of your SAP deployment. Ensuring proper data consistency is paramount to a successful SAP platform. When going live with SAP—either a module or a whole new implementation—you almost always need to run data conversions to populate your SAP system from a legacy system. Getting an environment prepped and ready for these data conversions can be complicated as these “mock runs” are also usually considered a mock cutover for when you actually go to production.
As a result, you’ll need to oversee every mock run to ensure things fit within the agreed-upon downtime. Further complicating things, these data conversions are usually dependent on each other. That means you can’t import all your pricing data before you import your material, for example. So if something goes wrong with that material conversion and only 10% of materials make it through the ETL process, it will affect every object dependent on material as well. When this happens, you’ll also need to fix all the data that’s already flowed into the system to run the mock again, usually from a backup. This painstakingly long process will certainly throw off any chance of hitting the cutover window.
The good news? Snapshots can help you avoid all this hassle. By adding snapshots with instantaneous restore points throughout this process, you’ll not only save time to hit that cutover window but also ensure as much data as possible flows into the target environment. Mock runs usually turn those landscapes into test environments.
Avoid Extra Downtime
Most companies plan major upgrades to their SAP landscapes in advance—usually once a year. However, SAP releases patches for bug fixes on a constant basis. At times, you’ll need to apply patches to an SAP landscape more often, using a scheduled maintenance window, usually monthly or quarterly.
In most cases, depending on your business, weekends are the best time to take down an application suite for patching. You’ll be able to apply support packs and custom transports, and can do manual changes if needed based on what you find during the testing phases of the application. In most cases, you’ll have to do a full backup to protect the solution in case something goes wrong. And when something goes wrong (and things often do), it means restoring from the backup and trying again the following weekend.
Injecting snapshots into this process can save valuable time and help you avoid additional downtime if something goes wrong. For example, instead of waiting for a full backup to finish, you could take an application-consistent snapshot at the beginning of the process. Since you’re most likely already in a downtime window, an application-consistent snapshot is very easy to accomplish. If, and when, something goes wrong, you can be back up and running in seconds. And instead of relying on a serial process that needs to go all the way back to the beginning if something fails, you can simply perform a snapshot after each successful step to give yourself a save-point. As a result, you’ll be able to fix anything that went wrong within that same maintenance window.
Make Data More Manageable
“Where’s the data?” That’s the first question an ABAP developer asks when you report a bug in production. Having real business data in your dev/test environments is an absolute must to ensure that you’re recreating and fixing real business problems. After all, your users are your best testers.
However, moving all that data around in an SAP landscape is not easy. Tools like TDMS give you some capabilities to replicate data objects between landscapes, but they’re very complex to set up. A large dependency on custom objects also adds so much complication that they become projects in themselves. And they unnecessarily replicate data between landscapes.
Snapshots can help solve this problem. Simply take a snapshot of your SAP database (SAP HANA, Oracle, SQL Server, etc.) in an instant (no matter how large the database) and mount that data in another environment to have a fully functioning SAP system.
That said, there’s more to “refreshing” an environment than simply overwriting it with a completely new database. There are pre-processing steps such as exporting data that you don’t want to overwrite like RFC destinations or Users. Once the snapshot overwrites the entire database, you’ll need to import this data and run a BDLS. I’ve talked to people who have automated most of this process but can’t seem to get around the complexity in the middle.
The solution? Pure Storage snapshots. You can take them directly on storage volumes through a UI or use an OpenAPI if you’d like to enhance existing automation to also handle the database-copy procedures. You won’t be duplicating data at all as snapshots are completely deduplicated working “copies.” You’ll take up storage only once you start creating deltas between your source and target. Think of the time you can save by automating this process with Pure’s OpenAPI to take—and recover from—a storage snapshot.
Because every implementation is different, these are just a few of the uses for snapshots to help you get the most out of your infrastructure investment. What are some other ways snapshots can help your SAP platform? Use the comments below to share your ideas.
