A /lock directory for storing instance "state" files cause issue during online backup

[porwat]

1. /content/cq/author contains/aem-compose and /var/lock inside

   aem-compose/
   `-- var
   `-- lock
       |-- create.yml
       |-- init.yml
       `-- start.yml

2. I use online backup to backup /content/cq/author instance directory. It is initiated by: curl -sL -w "%{http_code}" -X POST -u "admin:admin" "http://127.0.0.1:4502/libs/granite/backup/content/createBackup/content/items/backupform.html" -d "_charset_=utf-8&target=/content/backups/cq_backup&delay=0"

3. Backup fails with error:

19.05.2023 19:34:14.714 *WARN* [] [Backup Worker Thread] com.day.crx.core.backup.crx.Backup Backup failed with error
java.io.IOException: can't write to /content/backups/cq_backup/aem-compose/var/lock
    at com.day.crx.core.backup.crx.FileUtil.copy(FileUtil.java:197)
    at com.day.crx.core.backup.crx.FileUtil.copy(FileUtil.java:179)
    at com.day.crx.core.backup.crx.FileUtil.copy(FileUtil.java:179)
    at com.day.crx.core.backup.crx.FileUtil.copy(FileUtil.java:179)
    at com.day.crx.core.backup.crx.FileUtil.copy(FileUtil.java:179)
    at com.day.crx.core.backup.crx.Backup.copyFiles(Backup.java:438)
    at com.day.crx.core.backup.crx.Backup.startStage(Backup.java:392)
    at com.day.crx.core.backup.crx.Backup$1.run(Backup.java:254)

Workaround: Backup succeded when I changed /var/lock to /var/state

The same happens when I try to create any directory named /lock in /content/cq/author, with random files inside. Changing directory owner or privileges no matters.

[krystian-panek-vmltech]

This looks more like AEM bug than AEMC one as the AEM code when packing archive has a problem with dir named 'lock'. If sb could confirm that AEM has a problem only with that particular dir name we could change it in AEMC but this is unfortunately breaking change which i am usually trying to avoid.

[wimsymons]

I have the same issue.

So I decided to take a closer look.

The AEM backup implementation does not allow /lock folders.

The class com.day.crx.core.backup.crx.Backup sets these EXCLUDE_PATTERNS: [./lock, ./listener.properties, ./lock.properties, ./cluster_node.id, ./cq.pid, ./repository/cache, ./repository/cache/., ./repository/index, ./repository/index/., ./repository/datastore.*]

This actually blocks implementation of #128 as well.

It will be faster to change AEMC than AEM, which would only be from a certain Service Pack as well. Or move aem-compose a level up, so it is no longer next to crx-quickstart.

[krystian-panek-vmltech]

Sure thing. I will rename lock dir if you are interested.

[wimsymons]

Yes I am.

As I just started using this tool, which I find amazing by the way, I tried to execute a backup using the current implementation. That worked, but when I performed a restore, I could not start the instance again.

Bundles would not start and the command eventually timed out.

It was a first attempt, so maybe I did something wrong, I'll have another go in the coming days.

Doing an online backup using the UI was my second attempt to solve this.

[krystian-panek-vmltech]

Thanks for the feedback ;)

Here is a potential fix for you. https://github.com/wttech/aemc/pull/259/files

Tomorrow I will test it. Tell me if it looks enough good to cover your case properly.

Greetings, Krystian

[krystian-panek-vmltech]

closing as fixed in 1.7.7; @wimsymons could you confirm that the fix helps you?:)

[wimsymons]

Hi Krystian,

Just tested 1.7.7.

Had to figure out how to update aemc-cli and how to update the lock folders. For the first, I changed the VERSION property at the top of the aemw script. For the second, I executed sh taskw restart.

After that, it all worked perfectly. I could successfully create an online backup without any error.

Thanks for such a swift response and release 👍

Kind regards

Wim

[krystian-panek-vmltech]

Cool. No problem. Greetings 😎🙂