online backup with delay parameter using script and backup notifications

[msina]

Hi,

First of all is it ok to set BackupDelay to "0" and run the online backup ?

Also how can i pass the Backupdelay in the curl command.?

curl -u admin:pwd -X POST http://localhost:4502/system/console/jmx/com.adobe.granite:type=Repository/op/startBackup/java.lang....

Finally how can i get the backup notifications?

regards

Sina

[arunpatidar]

Hi,

You can't pass backup delay in curl command but you can set backup delay from http://localhost:4502/system/console/jmx/com.adobe.granite%3Atype%3DRepository 

For backup notification check AEM Backup Notifications

Delay

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.

Thanks

Arun

[Jaideep_Brar · Accepted solution]

You can use the below-mentioned curl commands. In the example below, it is set to 1

curl -u admin:admin -X POST http://<host>:<port>/system/console/jmx/com.adobe.granite:type=Repository/a/BackupDelay?value=1

curl -u admin:admin -X POST http://localhost:4509/system/console/jmx/com.adobe.granite:type=Repository/op/startBackup/java.lang....

**Please note that you will need to run both commands together(Setting the delay first and then backup) in order to start the backup with desired backup delay value.

I also suggest testing the commands on Dev/Staging environment before moving to production.

You can verify the delay timing in logs as shown below :-

*INFO* [Backup Worker Thread] com.day.crx.core.backup.crx.Backup Finished copying everything except datastore from stage #1 in 5m : 9.43s with delay 1 ms copied 1.582 gb, skipped 0 bytes.

[msina]

Thanks a lot.It was very helpful.