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).
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:
- Stop AEM.
- Back up the entire
<cq-installation-dir>
from your file system.
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:
-
Navigate to the Tools console, select Operation, Maintenance, then Weekly Maintenance Window.
-
Select + Add from the top toolbar.
-
Select Version Purge from the drop-down list in the Add New Task dialog. Then Save.
-
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
-
Select the Configure action to open the Web Console for Day CQ WCM Version Purge Task, where you can configure:
-
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.
-
-
Navigate/return to the Weekly Maintenance Window window and select Run to launch the process immediately.
- http://localhost:4502/etc/versioning/purge.html
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.
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 renamederror.log-2010-07-10
, then a newerror.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.
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 toWarning
(WARN
) -
stdout.log
Holds logging messages indicating events during startup. -
upgrade.log
Provides a log of all upgrade operations that runs from thecom.day.compat.codeupgrade
andcom.adobe.cq.upgradesexecutor
packages.
-
-
<cq-installation-dir>/crx-quickstart/repository/segmentstore
journal.log
Revision journaling information.