An application snapshot in Oracle EPM Cloud is a complete, point-in-time backup of an EPM application — capturing the application’s full state: dimension metadata, Essbase data across all cubes, Planning configuration, business rules, data forms, security assignments, and application settings. Unlike an LCM export (which captures artefacts but not data), a snapshot captures the complete application state and can be used to restore the application to exactly the state it was in at the time of the snapshot — including all data values. Snapshots are the primary rollback mechanism in Oracle EPM Cloud: before a major deployment, before a close cycle, and after a significant data load, a snapshot provides the ability to restore the application if the subsequent operation produces incorrect results.
Snapshot Operations
Snapshots are created through the EPM Cloud interface or through EPM Automate (exportSnapshot command). Oracle EPM Cloud also creates automatic daily snapshots — typically retaining the last 60 days — which serve as the baseline disaster recovery for the environment. Application-specific snapshots created through EPM Automate can be retained on external storage by downloading them from the EPM Cloud file system using EPM Automate’s downloadFile command.
Restoring from a snapshot (importSnapshot command) replaces the entire application with the snapshot’s state — including all data. This is a destructive operation: any data or metadata changes made after the snapshot are lost. Partial restores — restoring only the data for a specific entity or period while retaining metadata changes made after the snapshot — are not natively supported by the snapshot mechanism. Partial restore scenarios require data export and re-import operations targeted at the specific scope that needs to be restored.
Design Considerations
Snapshot frequency and retention must be designed to meet the organisation’s recovery time objective (RTO) and recovery point objective (RPO) for the EPM application. For a close cycle environment where a month’s worth of planning data is at risk, a snapshot taken before each major batch operation — data loads, business rule executions, metadata changes — provides granular rollback capability. For less frequently changed environments, daily automatic snapshots may be sufficient.
What Goes Wrong in Practice
The specific snapshot-related failure that produces the most severe recovery situations is discovering during a rollback scenario that the most recent snapshot predates the data loss event by more than an acceptable interval — because snapshots were created before the close cycle began but not during the close cycle’s intermediate stages. If a calculation error is introduced by a business rule midway through a multi-day close cycle, the rollback point is the pre-close snapshot — requiring the entire close cycle’s data entry and calculation work to be redone. Creating snapshots at each significant stage of the close cycle — after data load, after each major calculation run, after approval submissions — provides recovery points that limit the redone work to the most recent stage.
How Loop Wise Solutions Handles This
We include a snapshot schedule in the operational runbook for every EPM close cycle — specifying which stages trigger a snapshot, the naming convention for each snapshot, and the download procedure for archiving snapshots to external storage beyond Oracle’s 60-day retention window. Snapshot creation is an explicit step in the EPM Automate close cycle script, not an afterthought.
Answers before you ask.
A complete backup of the EPM application at a point in time — metadata, data, security, and configuration. Because it captures the whole state, a snapshot can restore or clone an environment, making it the primary rollback and disaster-recovery mechanism when data is corrupted or a deployment fails.
Directly. EPM Cloud takes a daily maintenance snapshot, but retention is limited, so relying solely on the automatic one bounds how far back you can recover. Exporting and retaining snapshots externally, especially before major changes, extends the recovery window. The policy you set determines whether you can recover from an issue discovered days later.
Before any significant change — a metadata deployment, a large data load, an upgrade, or a risky rule run — so you have a known-good state to restore. Taking a snapshot before and after key close steps is also common. This turns a potentially unrecoverable mistake into a straightforward rollback.
A snapshot is the complete application state used for backup and full restore; an artifact bundle is a selective export of chosen artefacts for targeted promotion. You restore a snapshot to recover or clone an environment; you deploy a bundle to move specific changes. Using a snapshot where a bundle is needed would overwrite the target.