Backup and Restore backup-and-restore
There are two ways to back up and restore repository content in AEM:
- You can create an external backup of the repository and store it in a safe location. If the repository breaks down, you can restore it to the previous state.
- You can create internal versions of the repository content. These versions are stored in the repository along with the content, so you can quickly restore nodes and trees you have changed or deleted.
General general
The approach described here applies for system backup and recovery.
If you need to backup and/or recover a small amount of content, which is lost, a recovery of the system is not necessarily required:
- Either you can fetch the data from another system via a package
- or you restore the backup on a temporary system, create a content package and deploy it on the system, where this content is missing.
For details, see Package Backup below.
Timing timing
Do not run backup in parallel with the datastore garbage collection, as it might harm the results of both processes.
Offline Backup offline-backup
You can always do an offline backup. This requires a downtime of AEM, but can be quite efficient in terms of required time compared to an online backup.
In most cases you will use a filesystem snapshot to create a read-only copy of the storage at that time. To create a offline backup perform these steps:
- stop the application
- make a snapshot backup
- start the application
As the snapshot backup usually takes only a few seconds, the entire downtime is less than a few minutes.
Online Backup online-backup
This backup method creates a backup of the entire repository, including any applications deployed under it, such as AEM. The backup includes content, version history, configuration, software, hotfixes, custom applications, log files, search indexes, and so on. If you are using clustering and if the shared folder is a subdirectory of crx-quickstart (either physically, or using a softlink), the shared directory is also backed up.
You can restore the entire repository (and any applications) at a later point.
This method operates as a 鈥渉ot鈥 or 鈥渙nline鈥 backup so it can be performed while the repository is running. Therefore the repository is usable while the backup is running. This method works for the default, Tar storage based, repository instances.
When creating a backup, you have the following options:
- Backing up to a directory using AEM鈥檚 integrated backup tool.
- Backing up to a directory using a filesystem snapshot
In any case, the backup creates an image (or snapshot) of the repository. Then the systems backup agent should take care to actually transfer this image to a dedicated backup system (tape drive).
crx-quickstart" directory and backup the datastore separately.AEM Online Backup aem-online-backup
An online backup of your repository lets you create, download, and delete backup files. It is a 鈥渉ot鈥 or 鈥渙nline鈥 backup feature, so can be executed while the repository is being used normally in the read-write mode.
When starting a backup you can specify a Target Path and/or a Delay.
Target Path The backup files are usually saved in the parent folder of the folder holidng the quickstart jar file (.jar). For example, if you have the AEM jar file located under /InstallationKits/AEM, then the backup will be generated under /InstallationKits. You can also specify a target to a location of your choice.
If the TargetPath is a directory, the image of the repository is created in this directory. If the same directory is used multiple times (or always) to storing backup,
- modified files in the repository are modified accordingly in the TargetPath
- deleted files in the repository are deleted in the TargetPath
- created files in the repository are created in the TargetPath
- it requires additional disk storage during the backup process (temporary directory plus the zip file)
- the compression process is done by the repository and might influence its performance.
- It delays the backup process.
- Up to Java 1.6 Java is only able to create ZIP files up to a size of 4 gigabytes.
Delay Indicates a time delay (in milliseconds), so that repository performance is not affected. By default, the repository backup runs at full speed. You can slow down creating an online backup, so that it does not slow down other tasks.
When using a very large delay, ensure that online backup does not take more than 24 hours. If it did, discard this backup, as it may not contain all binaries.
A delay of 1 millisecond typically results in 10% CPU usage, and a delay of 10 milliseconds usually results in less than 3% CPU usage. The total delay in seconds can be estimated as follows: Repository size in MB, multiplied by delay in milliseconds, divided by 2 (if the zip option is used), or divided by 4 (when backing up to a directory). That means a backup to a directory of a 200 MB repository with 1 ms delay increases the backup time by about 50 seconds.