Atrocore Installer deleted all data from EFS and RDS including existing users

umangdesai-vonage · November 3, 2026, 8:34am

Our script is as below, it runs every time we enable a flag. Earlier also we had run it but this time it purged all data from file system and Database both.

In Values.modules we add all the modules list which we have purchased or would like to maintain. After that we run migrate command for the module to update the module to the latest version. As we create a modules.json.bckp_CURRENT_DATE backup file of this before running modules migration. But in this case, as all data was purged in atrocore-installer.phar self-update or atrocore-installer.phar update command, this backup file was never created. I wanted to ask what caused this and any behaviour we should modify?

Please let me know if you need any other information? Thanks in advance

          echo ">>> Updating installer"
          php /var/www/html/atrocore-installer.phar self-update

          echo ">>> Running composer update"
          php /var/www/html/atrocore-installer.phar update

          echo ">>> Current modules.json is backed up to /var/www/html/modules.json.bckp_CURRENT_DATE"
          cp /var/www/html/data/modules.json "/var/www/html/modules.json.bckp_$(date +%Y-%m-%d_%H-%M-%S)"
          echo ">>> Updating modules.json in EFS from helm chart values.yaml"
          echo '{{ .Values.modules | toJson }}' > /var/www/html/data/modules.json
          echo "New modules.json written to EFS:"
          cat /var/www/html/data/modules.json

          echo ">>> Running module migrations"
          {{- range .Values.modules }}
          echo "Migrating {{ . }}..."
          php /var/www/html/console.php "migrate {{ . | lower }} 0.0.0 99.99.99" || true
          {{- end }}

          echo ">>> Syncing database schema"
          php /var/www/html/console.php "sql diff --run"

          echo ">>> Clearing cache"
          php /var/www/html/console.php "clear cache"

          echo ">>> Migration complete — handing off to main container"

Logs

==> Updating installer
Updated from 1.0.3 to 1.0.6.
==> Running composer update
Loading composer repositories with package information
Cannot create cache directory /var/www/.composer/cache/repo/https—packagist.atrocore.com-packages.json-id-common/, or directory is not writable. Proceeding without cache. See also cache-read-only config if your filesystem is read-only.
Cannot create cache directory /var/www/.composer/cache/repo/https—repo.packagist.org/, or directory is not writable. Proceeding without cache. See also cache-read-only config if your filesystem is read-only.
Updating dependencies
Lock file operations: 0 installs, 12 updates, 0 removals
.
.
.
.
.
.
.
Writing lock file
Installing dependencies from lock file (including require-dev)
Creating restore point
Package operations: 0 installs, 12 updates, 0 removals
Cannot create cache directory /var/www/.composer/cache/files/, or directory is not writable. Proceeding without cache. See also cache-read-only config if your filesystem is read-only.
.
.
.
.
.
.
Package composer/package-versions-deprecated is abandoned, you should avoid using it. No replacement was suggested.
Package doctrine/cache is abandoned, you should avoid using it. No replacement was suggested.
Generating autoload files
49 packages you are using are looking for funding.
Use the composer fund command to find out more!
Deprecation Notice: Atro\Core\Templates\Repositories\Hierarchy::getInheritableFields(): Implicitly marking parameter $fieldsDefs as nullable is deprecated, the explicit nullable type must be used instead in /var/www/html/vendor/atrocore/core/app/Atro/Core/Templates/Repositories/Hierarchy.php:239
More deprecation notices were hidden, run again with -v to show them.
02.11.2026 12:05:45 | Copying system files
02.11.2026 12:05:45 | Updating list of used modules
02.11.2026 12:05:45 | Copying post-install & post-delete scripts for modules
02.11.2026 12:05:48 | Copying migration scripts
02.11.2026 12:05:56 | Copying frontend files
02.11.2026 12:05:57 | Done!
==> Current modules.json is backed up to /var/www/html/modules.json.bckp_CURRENT_DATE
==> Updating modules.json in EFS from helm chart values.yaml
New modules.json written to EFS:
[“Pim”,“Export”,“ExportHttp”,“Import”,“ImportHttp”,“OpenIdConnectSso”]
==> Running module migrations
Migrating Pim…
Migrating Export…
Migrating ExportHttp…
Migrating Import…
Migrating ImportHttp…
Migrating OpenIdConnectSso…
==> Syncing database schema
ALTER TABLE REDACTEDe[0;32m Done!e[0m
ALTER TABLE REDACTEDe[0;32m Done!e[0m
ALTER TABLE REDACTEDe[0;32m Done!e[0m
ALTER TABLE REDACTEDe[0;32m Done!e[0m
ALTER TABLE REDACTEDe[0;32m Done!e[0m
ALTER TABLE REDACTEDe[0;32m Done!e[0m
ALTER TABLE REDACTEDe[0;32m Done!e[0m
ALTER TABLE REDACTEDe[0;32m Done!e[0m
DROP TABLE REDACTEDe[0;32m Done!e[0m
DROP TABLE REDACTEDe[0;32m Done!e[0m
DROP TABLE REDACTEDe[0;32m Done!e[0m
DROP TABLE REDACTEDe[0;32m Done!e[0m
DROP TABLE REDACTEDe[0;32m Done!e[0m
DROP TABLE REDACTEDe[0;32m Done!e[0m
DROP TABLE REDACTEDe[0;32m Done!e[0m
DROP TABLE REDACTEDe[0;32m Done!e[0m
DROP TABLE REDACTEDe[0;32m Done!e[0m
DROP TABLE REDACTEDe[0;32m Done!e[0m
DROP TABLE REDACTEDe[0;32m Done!e[0m
DROP TABLE REDACTEDe[0;32m Done!e[0m
DROP TABLE REDACTEDe[0;32m Done!e[0m
.
.
.
.
.
DROP TABLE oidc_group_rolee[0;32m Done!e[0m
DROP TABLE oidc_groupe[0;32m Done!e[0m
DROP TABLE oidc_group_teame[0;32m Done!e[0m
DROP TABLE oidc_group_usere[0;32m Done!e[0m
ALTER TABLE auth_token DROP oidc_access_tokene[0;32m Done!e[0m
ALTER TABLE auth_token DROP oidc_refresh_tokene[0;32m Done!e[0m
ALTER TABLE auth_token DROP oidc_expires_ate[0;32m Done!e[0m
ALTER TABLE “user” DROP oidc_ide[0;32m Done!e[0m
==> Clearing cache
e[0;32mCache successfully clearede[0m
==> Migration complete — handing off to main container

alex.sapko · November 4, 2026, 2:20pm

Hello @umangdesai-vonage
We will investigate this issue

raoul.dzoukou · November 4, 2026, 3:08pm

Hi @umangdesai-vonage

Thank you for the detailed report, and we’re sorry about the data loss. We looked at the code and at the steps in your script, and we think the extra steps around the update caused this, not the update itself.

What most likely happened

migrate <module> 0.0.0 99.99.99 replays every migration. AtroCore does not keep a list of migrations that already ran. The command runs every migration file of the module between the two versions, so with 0.0.0 to 99.99.99 it replays the module’s entire migration history on your live database. Old migrations assume the schema of their own time, and some of them rewrite or drop data. With || true, any failure is hidden. This step is also unnecessary: the installer already runs exactly the migrations between the old and new version of each updated package.
sql diff --run removes everything the loaded metadata doesn’t describe. It compares the database with the metadata of the modules that loaded at that moment, and drops what is not described. If a module is listed but cannot be loaded, for example because of a PHP error in its code after the update, it is skipped, and its tables and columns are dropped. The oidc_group* tables and the OIDC columns in your log fit this: OpenIdConnectSso was in your list, but its metadata was not loaded.
Overwriting data/modules.json from Helm values. The list is generated from composer.lock during the update. Replacing it with a fixed list can leave out installed modules, and then their tables are treated as unused.

How to update

Please don’t add any steps around the update. Run only:

php atrocore-installer.phar update

It creates a restore point (files and a database dump) in backups/, runs composer update, rewrites modules.json from composer.lock, runs only the needed migrations, and refreshes the cache and translations.

After every update, check for PHP errors

Before you let anything touch the database schema, make sure all modules actually load:

Read the complete output of the update, and the log files in data/logs/, for PHP errors or warnings (fatal errors, “class not found”, incompatible declarations).
Also check the PHP error log of the CLI and of the web server. A module that fails to load while the application starts is not necessarily written to data/logs/.
Confirm that every module in data/modules.json loads, for example:
```
php -r 'require "vendor/autoload.php"; var_dump(class_exists("\\OpenIdConnectSso\\Module"));'
```
Replace the class with each module you use. Any false means that module is not loaded.
Run php console.php sql diff --show and read the result. If it lists DROP TABLE or DROP COLUMN for tables you expect to keep, do not run --run. Find the PHP error first.

Your own modules

If you maintain modules of your own, provide them through a Composer path repository and set the version explicitly. Composer then updates them like any other package, and their migrations run by version:

"repositories": [
  {
    "type": "path",
    "url": "modules/my-module",
    "options": { "symlink": false, "versions": { "vendor/my-module": "1.2.0" } }
  }
]

The module needs its own composer.json with extra.atroId and a PSR-4 autoload entry.

Recovering your data

Please check whether the backups/ directory in the project root survived. The installer creates a restore point there before the first write of every update. If your container doesn’t persist that directory, an RDS snapshot from before the update is the other option.

To help us confirm the cause, could you send us:

the content of data/modules.json after the update,
the PHP CLI version,
the result of the class_exists check above for each of your modules,
the complete update log and any PHP errors you find.