7.4 Repository Maintenance: Revision Cleanup, Compaction & Purge Tasks
Key Takeaways
- Oak maintenance depends on the NodeStore: SegmentNodeStore revision cleanup compacts segment data, while DocumentNodeStore revision garbage collection removes obsolete document revisions.
- Data Store Garbage Collection uses mark and sweep to remove unreferenced binaries; age settings are safety controls and must not be presented as one universal mandatory value.
- In AEM 6.5, the Operations Dashboard schedules Revision Cleanup and Lucene Binaries Cleanup daily, while workflow purge, Data Store GC, audit purge, and version purge are weekly tasks.
- JCR versions are stored below /jcr:system/jcr:versionStorage, not /var/version; workflow instances and audit records are separate growth areas under /var.
- AEM as a Cloud Service has no customer Maintenance Card: Adobe owns Data Store GC, while customers configure supported version, audit, and workflow purges through source-controlled deployment mechanisms.
7.4 Repository Maintenance: Revision Cleanup, Garbage Collection & Purges
Quick Answer: Repository growth has several independent causes. Oak revision cleanup reclaims obsolete NodeStore data, Data Store Garbage Collection removes unreferenced binaries, and application purge tasks remove old workflow, audit, or JCR version records. The correct procedure depends on the storage topology and hosting model. AEM as a Cloud Service does not expose the AEM 6.5 Maintenance Card to customers.
Separate the Storage Layers
Do not treat every cleanup operation as compaction. Oak commonly separates:
- NodeStore data: Nodes, properties, revisions, and commit history.
- Data Store or Blob Store data: Large binaries referenced from repository nodes.
- Application histories: JCR versions, workflow instances, and audit records created by AEM features.
- Indexes: Lucene index data that has its own lifecycle and cleanup behavior.
Deleting a page or asset can add a deletion revision first. Physical storage is reclaimed later by the maintenance process appropriate to each layer.
Revision Cleanup Depends on the NodeStore
For SegmentNodeStore/TarMK, online revision cleanup compacts reachable data into newer segment generations and removes eligible old segment generations. AEM 6.5 exposes Revision Cleanup in the daily maintenance window. Offline compaction is exceptional work and should be performed only with an appropriate runbook or Adobe Support guidance.
For DocumentNodeStore, updates produce document revisions. Revision Garbage Collection removes old revision data that is no longer needed. Oak uses a configurable maximum age, commonly 86,400 seconds by default, so recent revisions remain available for cluster and checkpoint safety. Do not describe DocumentNodeStore revision GC as TarMK segment compaction; they solve analogous growth problems with different storage algorithms.
Data Store Garbage Collection
Large binaries can live in a File Data Store or cloud Blob Store separately from the NodeStore. After the last repository reference is removed, the binary may remain until Data Store Garbage Collection runs.
The process is conceptually mark and sweep:
- Mark: Enumerate binary identifiers referenced by live repository state.
- Sweep: Compare stored binaries with the marked set and remove eligible, unreferenced entries.
Implementations use age or retention settings to avoid deleting newly written binaries before their repository references are visible. A 24-hour value appears in Oak defaults and examples, but it is a configurable safety setting, not a universal exam rule that every AEM Data Store GC must enforce. Run GC during low load and avoid overlap with backups in AEM 6.5.
AEM 6.5 Operations Dashboard
The Operations Dashboard is available at /libs/granite/operations/content/maintenance.html. Its documented default grouping is:
| Window | Typical built-in tasks |
|---|---|
| Daily | Revision Cleanup; Lucene Binaries Cleanup |
| Weekly | Workflow Purge; Data Store Garbage Collection; Audit Log Maintenance; Version Purge; optional project and ad-hoc task purges |
The default daily window is 2:00–5:00 a.m. The weekly window runs for an hour on Saturday by default. Administrators can change windows and can run tasks manually. A task that exceeds its window can suspend and resume later, depending on the task.
Version Purge
JCR version histories are exposed below /jcr:system/jcr:versionStorage. They are not stored below /var/version. Version purge works against selected content paths and retention criteria such as maximum age and numbers of versions to retain. Preview and choose conservative retention values before deleting history. The current content state remains separate from historical versions.
Workflow and Audit Purges
Completed workflow instances can accumulate below /var/workflow/instances. Purging completed or terminated instances reduces repository growth without deleting active work. Audit data below /var/audit is controlled by audit-log purge rules. These purges remove feature data; they are not substitutes for NodeStore revision cleanup, which later reclaims obsolete storage representation.
AEM as a Cloud Service Responsibilities
AEM as a Cloud Service does not provide the customer-facing Maintenance Card. Responsibility is divided:
- Adobe-managed: Data Store Garbage Collection and infrastructure-level repository maintenance.
- Customer-configurable: Version purge and audit-log purge through a source-controlled MaintenanceTasks YAML file deployed by a Cloud Manager config pipeline.
- Customer-configurable: Workflow purge scheduling through supported project configuration committed to Git.
- Not normally required: Lucene Binaries Cleanup is disabled because the Cloud Service architecture does not use it in the same way as AEM 6.5.
A MaintenanceTasks configuration must include all required fields. After a version-purge or audit-purge node has been deployed, Adobe documents that it must remain declared; removing it causes the config pipeline to fail. AEM Guides customers should not configure version purge.
Troubleshooting Decision Table
| Symptom | Investigate first |
|---|---|
| TarMK repository disk grows despite deletions | SegmentNodeStore revision cleanup status and maintenance window |
| DocumentStore revision data grows | Revision GC schedule, age, checkpoints, and logs |
| Blob storage grows after asset deletion | References, backups, and Data Store GC status |
| Millions of completed workflows | Workflow purge policy and active-versus-completed status |
| Excessive page or asset histories | Version purge policy for the intended content paths |
| Audit tree growth | Audit log purge rules and required retention |
Keep these processes distinct. Running version purge does not directly sweep binary storage, and Data Store GC does not remove workflow instances or audit nodes.
Why does a Data Store Garbage Collection implementation use a minimum-age safety setting before deleting an apparently unreferenced binary?
Why can Oak storage continue to grow after content is updated or deleted?
In the AEM 6.5 Operations Dashboard, which repository maintenance task is typically scheduled in the Weekly Maintenance Window rather than the Daily Maintenance Window due to its intensive I/O footprint?
An AEM administrator discovers that Oak search query performance has slowed down significantly, and the repository contains over 4 million nodes under /var/audit. Which maintenance task should be configured to resolve this issue?