Recommended Sequence of CQ Maintenance Operations

The following is the sequence recommended by Adobe CQ Engineering. A sample RHEL 6.3 shell script that invokes these operations using curl is available for download here.

ONCE PER DAY
BACKUP

1) Backup
OPTIMIZATION

2) Tar Index Merge (performed automatically by CQ)
3) Tar PM Optimization (performed automatically by CQ)

This defragments the repository Tar files and re-claims disk space. There are three operations involved:

a) Default Workspace
This is located at /crx-quickstart/repository/workspaces/crx.default/ and is configured in repository.xml within the following XML node



b) Versioning Workspace
This is hidden from the GUI, is located at /crx-quickstart/repository/version and is configured in repository.xml within the following XML node



c) Tar Journal at /crx-quickstart/repository/tarJournal
Tar PM Optimization of the two workspaces can be scheduled separately in repository.xml . In PRODUCTION “author” instances that have been running for quite some time, the Versioning Workspace tends to be bigger and take much longer to finish. The schedule is controlled by the autoOptimizeAt parameter. See below.



I recommend that you schedule the Tar PM Optimizations of the Default and the Versioning Workspaces to NOT run concurrently. Also, make sure the window is large enough for the operation to finish. You can determine this by checking the CQ error.log Log entries pertaining to the Tar PM Optimization will stop long before the scheduled time window expires.

5) Consistency Check (see script here)
6) Traversal Check (see script here)

If your repository is large, you can choose to start ConsistencyCheck() and TraversalCheck() at a level lower than at the top (/ which represents the root of the hierarchical Java Content Repository). E.g. /content/dam/MySite1Assets for Start Path.

In addition, the following CQ Knowledge Base article discusses ways to prevent repository inconsistencies from occurring. Here are links to the sample (v5.6) repository.xml, workspace.xml and start.bat (Windows). Please note that these settings do slow down CQ startup times, the bigger your repository, the longer the startup.

ONCE PER WEEK
1) Datastore Garbage Collection (see this)

This removes orphaned files in the datastore that are no longer referenced from within the repository, and re-claims storage wasted by those. The bigger the data store, the longer this operation will take. See this for a model to predict this.