An SAP data-archiving runbook turns an approved archiving design into a controlled production operation. It defines what operators check, execute, reconcile and retain as evidence—from preprocessing through deletion and historical access. It does not decide which data should be archived; that work belongs in the strategy and assessment phases.
Before the run: establish the control envelope
Begin only after the archiving object, retention basis, selection scope, dependencies and access requirements have been approved. An archiving object is the technical and business unit that groups the programs, tables and rules used to archive related data. Transaction SARA (Archive Administration) is the principal operating interface for ADK-based archiving in SAP systems, but the actions it offers depend on the selected object.
For broader concepts and design decisions, use the SAP Data Archiving Guide and SAP Data Archiving overview. This runbook begins at the point where a tested object and approved run scope are ready for execution.
Production prerequisites
- Confirm the correct system, client, archiving object and approved selection variant.
- Verify required authorizations, including object-specific permissions and
S_ARCHIVEwhere applicable. - Confirm residence, retention and legal-hold controls have been evaluated under the organization’s policy.
- Verify prerequisite and dependent objects, business statuses, closing activities and object-specific Customizing.
- Check archive-file location, content repository or storage integration, capacity, connectivity, immutability requirements and backup arrangements.
- Confirm the retrieval method, information structures and business validation scripts have been tested.
- Set the run window, job resources, spool settings, monitoring owner, stop criteria and escalation contacts.
- Record baseline counts, control totals, database volume and unresolved exceptions.
Use separate, controlled variants for each approved population. Avoid expanding selections during a live run without change approval. If readiness gaps remain, address them through an archiving assessment before deletion is authorized.
Step 1: review the archiving object in SARA
Enter the object in SARA and review its available actions, programs, Customizing, database tables and logs. Confirm whether it supports preprocessing, write, delete, postprocessing, read, reload or storage actions. Check the object’s application documentation for eligibility rules and dependencies; the presence of a button in SARA is not proof that the run is ready.
Capture the object name, variants, planned job names, run owner, ticket or change reference, expected population and expected archive destination in the run record.
Step 2: execute preprocessing when the object requires it
Preprocessing can identify eligible business objects, evaluate residence time and application checks, record rejection reasons or set a status that prepares records for archiving. It does not apply to every object, and its effects are object-specific. Schedule the approved variant, start the job and monitor the job log, application log and spool.
Do not proceed merely because the job is green. Compare selected, eligible and rejected populations with the approved expectations. Classify unexpected rejections such as open status, missing predecessor archiving or failed customer checks. Some preprocessing changes business-object status, so recovery may require an object-specific reset or postprocessing program—not a manual database update.
Step 3: run the write phase
The write program selects eligible data and creates one or more archive files. In standard ADK processing, the write phase does not itself mean that the corresponding database records have been removed. Schedule the write job with the approved variant and resource settings, then monitor job status, spool, application logs, file creation and runtime.
Verify that every expected file has a successful write status and is associated with the correct object and run. Reconcile written business objects, data objects or relevant control totals against the pre-run scope. Investigate partial files, cancellations, authorization failures, capacity problems and selection anomalies before enabling deletion.
Step 4: verify and store the archive files
Confirm the files are readable, complete and protected before database deletion. Where the design uses an external content repository or storage system, verify successful transfer and repository availability rather than assuming that local file creation equals durable storage. Storage may occur before, during or after deletion depending on Customizing and the object.
Record file identifiers, sizes, creation status, storage status and repository references. Test a representative read using the supported application display, archive read program or access mechanism. A copied file without its metadata, directory information or supported access path may not provide usable business history.
Step 5: authorize and execute deletion
The delete program reads successfully written archive files and removes corresponding records from the operational database. Treat deletion as a controlled gate. A second person or designated control owner should confirm successful writing, storage verification, reconciliation results and hold compliance before release.
Select only the approved archive files, schedule the delete job and monitor its logs. Some objects and configurations can start deletion automatically after writing; document that setting and ensure the control is placed before the write job. Never substitute direct table deletion for the supported object program.
After completion, reconcile deleted records to written records and explain any difference. Confirm expected database reduction only after normal database and storage behavior is considered; physical space reclamation may not immediately equal the logical rows removed.
Step 6: build or update access structures
If users rely on the Archive Information System, activate and populate the required archive information structures in accordance with the object design. Information structures index selected fields from archive files and enable supported searches, but they do not automatically reproduce every transaction, report or relationship.
Test representative searches, document display, authorizations and response time. Where operational reporting spans active and archived data, validate the approved reporting solution described in modern archived-data reporting. Retain test results and named business acceptance.
Step 7: reconcile and close the run
Reconciliation should prove both technical completion and business completeness. Compare pre-run, written, rejected, deleted and accessible populations. Use object-appropriate controls such as document counts, monetary totals, date ranges, company codes, attachments and parent-child relationships. Resolve or formally accept exceptions.
Close the run only when evidence includes:
- approved variants, scope, change record and operator approvals;
- preprocessing, write, storage, delete and information-structure job logs;
- archive-file inventory and repository confirmation;
- before-and-after counts and control totals;
- exception analysis and disposition;
- retrieval, reporting and authorization test results;
- business and control-owner sign-off.
Monitoring, failures and recovery
Monitor background jobs, application logs, spool output, archive-file status, storage transfers, repository health and information-structure build status. Trend throughput, failures, rejected populations, retrieval performance and database reduction across recurring runs.
If preprocessing or writing fails, preserve the logs and determine which packages or files completed before restarting. Do not blindly reuse variants or repeat a run: duplicate processing protections and recovery behavior differ by object. If storage verification fails, block deletion. If deletion partially fails, retain the archive files, identify successfully processed files or packages and follow the supported restart procedure. If an information structure fails, the archive file may remain intact even though indexed access is incomplete; rebuild only through supported tools.
Reload is not universally available and should not be treated as the primary recovery plan. Recovery depends on valid archive files, metadata, storage availability, backups and object-specific functions. Define and test these procedures before production. Common design and operating risks are summarized in Challenges in SAP Data Archiving.