All About SAP ILM Snapshot

An ILM Snapshot captures data without archivability checks and without deleting anything from the database. It’s designed for system decommissioning and Retention Warehouse scenarios where you must preserve open or still-relevant data for audits after shutdown. Snapshots go to a certified ILM store, default to Unknown retention, and you later assign a real expiration date once the business context allows it.

What Is an ILM Snapshot?

In SAP ILM, you have three actions:

1. Archiving – write & (later) delete, respecting archivability.

2. Destruction – irreversibly delete when rules say so.

3. Snapshot – write copies of data to the ILM store without archivability checks and without scheduling deletion.

Think of Snapshots as a freeze frame: you preserve exactly what you need for future access or audits when the productive system is going away but the business isn’t “fully closed” (e.g., you still have open items).

When to Use Snapshots

• System shutdown / carve-out / decommissioning where normal archiving can’t finish (open business remains).

• Retention Warehouse projects needing read-only access to historically correct data, including data that failed archivability.

• Compliance/Audit requirements to keep complete periods even if some processes remain open.

If the productive system stays live and traditional archiving fits your retention design, you usually don’t need Snapshots.

How Snapshots Behave (Compared to Archiving)

Aspect	Snapshot	Archiving
Archivability checks	Skipped (open objects allowed)	Enforced
Database deletion	No (keeps DB unchanged)	Yes (after write phase)
Retention at write	Unknown (protects from deletion)	Set per rule
Typical use case	Decommissioning / audit continuity	Steady-state data lifecycle

Where Snapshots Live

All ILM-managed files reside in your BC-ILM–certified store. Internally, Snapshots are organized under the SN path (distinct from standard archive files, print lists, or ArchiveLink add-ons). You can inspect them via the ILM Store Browser (launched from SARA → Archive Administration).

How Retention Works With Snapshots

• IRM (Information Retention Manager) still evaluates your rule to pick where to store the file.

• Because the business is not “closed,” IRM cannot set a real expiry date—so the file’s retention is Unknown.

• Unknown acts as a safety lock—the file cannot be destroyed until you later decide an expiration.

When you’re ready (e.g., after fiscal close or legal clearance), you assign the expiration using ILM_CHANGE_RET.

The Essential Transactions

• SARA – Run ILM actions; monitor runs and access File Administration.

• ILM_CHANGE_RET – Find Snapshot runs/files with Unknown retention and set a real expiration (today or a future date).

• ILM_DESTRUCTION – Remove test snapshots, duplicates, or files you’ve deliberately set to expire.

Step-by-Step: A Clean Snapshot Workflow

1) Plan & Select

• Define scope: business objects, periods, company codes.

• Verify your ILM store is BC-ILM certified and reachable.

• Align with legal/compliance: why Snapshot (vs. archive), how long it must remain, who will approve later destruction.

2) Create the Snapshot (SARA)

• In SARA, choose your archiving object and run with Action = ILM Snapshot.

• Use a clear variant (selection criteria, comments).

• Execute & monitor the job. The result appears in File Administration with a Snapshot icon.

3) Validate in ILM Store Browser

• Open store browser from SARA; navigate to the SN segment.

• Check resource metadata: URI, size, creator, timestamp, and IRM attributes (“stickers”).

4) Assign Expiration When Ready (ILM_CHANGE_RET)

• Start ILM_CHANGE_RET; list runs/files with Unknown retention.

• Set expiration to Today (test/cleanup) or a future date (production policy).

• Run in Test first, then Productive; keep logs.

5) Optional Cleanup (ILM_DESTRUCTION)

• For test snapshots, duplicates (same selection, keep the newest), or orphaned master/context snapshots, run ILM_DESTRUCTION after setting appropriate expiration.

Converting Existing Files Into Snapshots

Sometimes you’ve already archived master data or context files and later realize Snapshot semantics are more appropriate (e.g., for faster reads or changed DDIC structures). Use ILM_CHANGE_RET → File Conversion:

• Convert to Snapshot for selected runs.

• Optionally choose “With Conversion” to refresh structure mappings for better reading performance.

• Monitor via background jobs; validate in the store browser.

Operational Tips & Guardrails

• Document your variants: Always include descriptive comments so auditors understand the intent and scope.

• Separate test vs. prod: Prefix test runs (e.g., ZSNAP_TEST_*) and clean them up quickly.

• Watch store capacity: Snapshots can be large (they skip archivability filters). Plan storage and lifecycle.

• Segregate duties: The person who sets Unknown → Expiration should follow your governance workflow (approval trail).

• Index & access: Ensure your Retention Warehouse or reporting solution knows where to find and interpret snapshot files.

• Don’t forget master/context: Keep context snapshots aligned with transaction snapshots for complete reads.

Common Pitfalls (and Fixes)

• “We ran Snapshot but can’t destroy it later.”You likely never set an expiration. Use ILM_CHANGE_RET to assign one, then apply ILM_DESTRUCTION per policy.

• “Open items made the archive fail—now what?”That’s the Snapshot use case. Run Snapshot for that scope so decommissioning stays on track.

• “Store says file is protected.”That’s Unknown retention doing its job. Assign a date intentionally—don’t bypass it.

• “Performance reading old runs is slow.”Consider Convert to Snapshot with With Conversion to update structures for faster read-out.

Sample Runbook Excerpt (Paste into your SOP)

1. Pre-checks: ILM store OK, rule assigned, business sign-off received.

2. SARA: Action = ILM Snapshot, run with approved variant, monitor to green.

3. Validate: Store Browser → confirm file in SN, capture metadata screenshot.

4. Record: Save run ID, variant, and selection parameters in the decommissioning log.

5. Post-close: ILM_CHANGE_RET → set expiration per policy (test = today, prod = policy date).

6. Cleanup (if any): ILM_DESTRUCTION on expired test/duplicate/orphaned files.

7. Audit pack: Attach job logs, store metadata, and approval records.

FAQ

Is a Snapshot a replacement for Archiving?No. It’s a specialized tool for decommissioning/audit continuity, not a steady-state lifecycle.

Can Snapshots be destroyed?Yes—after you set a real expiration in ILM_CHANGE_RET and your policy permits it.

Do Snapshots change my database?No. They do not delete from the database; they create a copy in the ILM store.

Can I access Snapshot data in Retention Warehouse?Yes—Snapshots are designed to be read later, including open items at the time of shutdown.

Wrap-Up

Use Snapshots when you must preserve in-flight or non-archivable data for audit-ready access after decommissioning. Store them safely (Unknown retention by default), then assign expiration intentionally when the compliance window allows it. With a disciplined runbook—SARA → Store Browser → ILM_CHANGE_RET → (optional) ILM_DESTRUCTION—you’ll keep shutdowns clean, compliant, and defensible.