Backups

It is good practice to take backups of:

  • Your software installation - before/after significant changes in the configuration
  • The content held within the repository - regularly

Your company likely has a backup policy that you follow, additional considerations of what and when to back up include the following:

  • how critical the system and data is.
  • how often changes are made to either the software or data.
  • volume of data; capacity can occasionally be an issue, as can the time to perform the backup.
  • whether your backup can be made while users are online; and if possible, what is the performance impact.
  • the geographical distribution of users; that is, when is the best time to back up (to minimize impact)?
  • your disaster recovery policy; are there guidelines on where the backup data has to be stored (for example, offsite and specific medium).

Often a full backup is taken at regular intervals (for example, daily, weekly, or monthly), with incremental backups in between (for example, hourly, daily, or weekly).

CAUTION
When implementing back ups of your production instances, tests must be made to ensure that you can successfully restore the backup.
Without this testing, the backup is potentially useless (worst case scenario).
NOTE
For more information about backup performances, read the Back up Performance section.

Backing up your software installation

After installation, or significant changes in the configuration, create a backup of your software installation.

To do accomplish this task, back up your entire repository and then:

  1. Stop AEM.
  2. Back up the entire <cq-installation-dir> from your file system.
CAUTION
If you are operating a third-party application server, additional folders may be in a different location and must be backed up, too. See How to install AEM with an Application Server for information about installing application servers.
CAUTION
Incremental backup of the file data store is supported; when using incremental backup for other components (such as Lucene index), ensure that deleted files are also marked as deleted in the backup.
NOTE
Disk mirroring can also be used as a backup mechanism.

Backing up your repository

The Backup and Restore section of the CRX documentation covers all issues related to backups of the CRX repository.

For full details of making an online “hot” backup, see Creating an Online Backup.

Version Purging

The Purge Versions tool is intended for purging the versions of a node or a hierarchy of nodes in your repository. Its primary purpose is to help you reduce the size of your repository by removing old versions of your nodes.

This section deals with maintenance operations related to the versioning feature of AEM. The Purge Version tool is intended for purging the versions of a node or a hierarchy of nodes in your repository. Its primary purpose is to help you reduce the size of your repository by removing old versions of your nodes.

Overview

The Purge Versions tool is available as a weekly maintenance task. Before using for the first time, it must be added, then configured. After that it can be run on request, or on a weekly basis.

Purging Versions of a Web Site

To purge versions of a web site, proceed as follows:

  1. Navigate to the Tools console, select Operation, Maintenance, then Weekly Maintenance Window.

  2. Select + Add from the top toolbar.

    Add Version Purge

  3. Select Version Purge from the drop-down list in the Add New Task dialog. Then Save.

    Add Version Purge

  4. The Version Purge task is added. Use the card actions to:

    • Select - reveals additional actions in the top toolbar
    • Run - to run the configured purge immediately
    • Configure - to configure the weekly purge task

    Version Purge Actions

  5. Select the Configure action to open the Web Console for Day CQ WCM Version Purge Task, where you can configure:

    Version Purge Configuration

    • Purge paths
      Set the start path of the content to be purged; for example, /content/wknd.

      CAUTION
      Adobe recommends that you define multiple paths for each of your websites.
      Defining a path with too many children can significantly lengthen the time to perform the purge.
    • Purge versions recursively

      • Unselect if you want to only purge the node defined by your path.
      • Select if you want to purge the node defined by your path and its descendants.
    • Maximum number of versions
      Set the maximum number of versions (for each node) that you want to keep. Leave empty to not use this setting.

    • Minimum number of versions
      Set the minimum number of versions (for each node) that you want to keep. Leave empty to not use this setting.

    • Maximum version age
      Set the maximum version age in days (for each node) that you want to keep. Leave empty to not use this setting.

    Then Save.

  6. Navigate/return to the Weekly Maintenance Window window and select Run to launch the process immediately.

CAUTION
You can use the Classic UI dialog to perform a Dry Run of your configuration:
  • http://localhost:4502/etc/versioning/purge.html
Purged nodes cannot be reverted without restoring the repository. Take care of your configuration by always perform a dry run before purging.

Dry Run - Analyzing the Console

The classic UI provides a Dry Run option from:

  • http://localhost:4502/etc/versioning/purge.html

The process lists all the nodes that have been processed. During the process, a node can have one of the following statuses:

  • ignore (not versionnable): the node does not support versioning and is ignored during the process.

  • ignore (no version): the node does not have any version and is ignored during the process.

  • retained: the node is not purged.

  • purged: the node is purged.

Moreover the console provides useful information about the versions:

  • V 1.0: the version number.

  • V 1.0.1*: the star indicates that the version is the current (base) version and cannot be purged.

  • Thu Mar 15 2012 08:37:32 GMT+0100: the date of the version.

In the next example:

  • The Shirts versions are purged because their version age is greater than two days.
  • The Tonga Fashions! versions are purged because their number of versions is greater than 5.

global_version_screenshot

Working with Audit Records and Log Files

Auditing records and log files relating to Adobe Experience Manager (AEM) can be found at various locations. The following is provided to give you an overview of what you can find and where you can find it.

Working with Logs

AEM WCM records detailed logs. After you unpack and start Quickstart, you can find logs in:

  • <cq-installation-dir>/crx-quickstart/logs/

  • <cq-installation-dir>/crx-quickstart/repository/

Log file rotation

Log file rotation refers to the process that limits the growth of the file by creating a file periodically. In AEM, a log file called error.log is rotated once a day according to the given rules:

  • The error.log file is renamed according to the pattern {original_filename}.yyyy-MM-dd. For example, on July 2010 11th, the current log file is renamed error.log-2010-07-10, then a new error.log is created.

  • Previous log files are not deleted, so it is your responsibility to clean old log files periodically to limit the disk usage.

NOTE
If you upgrade your AEM installation, any existing log file that is no longer used by AEM remains on the disk. You can remove them without risk. All new log entries are written in the new log files.

Finding the Log Files

Various log files are held on the file server where you installed AEM:

  • <cq-installation-dir>/crx-quickstart/logs

    • access.log
      All access requests to the AEM WCM, and the repository, are registered here.

    • audit.log
      Moderation actions are registered here.

    • error.log
      Error messages (of varying levels of severity) are registered here.

    • ImageServer-<PortId>-yyyy>-<mm>-<dd>.log
      This log is only used if Dynamic Media is enabled. It provides statistics and analytical information used for analyzing behavior of the internal ImageServer process.

    • request.log
      Each access request is registered here together with the response.

    • s7access-<yyyy>-<mm>-<dd>.log
      This log is only used if Dynamic Media is enabled. The s7access log records each request made to Dynamic Media through /is/image and /is/content.

    • stderr.log
      Holds error messages, again of varying levels of severity, generated during startup. By default the log level is set to Warning ( WARN)

    • stdout.log
      Holds logging messages indicating events during startup.

    • upgrade.log
      Provides a log of all upgrade operations that runs from the com.day.compat.codeupgrade and com.adobe.cq.upgradesexecutor packages.

  • <cq-installation-dir>/crx-quickstart/repository/segmentstore

    • journal.log
      Revision journaling information.
NOTE
The ImageServer and s7access logs are not included in the **Download Full **package that is generated from the **system/console/status-Bundlelist **page. For support purposes, if you have Dynamic Media issues, append the ImageServer and s7access logs when you contact Customer Support.