How to migrate to this Helm chart

Migrating to this Helm-managed OpenAEV instance requires deploying a new OpenAEV instance using this Helm chart, and migrating the required persistent data from the existing instance.

The following components must be considered: * PostgreSQL (ma,datory migration) * MinIO / S3 (mandatory migration) * **Elasticsearch / OpenSearch (migration not required - indexes are recreated automatically) *

Preparing the migration

Before starting the migration: * Ensure that the components versions between your two instances are the same (OpenAEV Version, backend components, databases). * Ensure that your new PostgreSQL cluster and Minio / S3 buckets have enough capacity.

Stop all OpenAEV components

Before migrating any data, ensure that all OpenAEV components are stopped on both instances: * OpenAEV Front * Injectors * Collectors

Also ensure that RabbitMQ queues are completely empty/

This is required to guarentee that no write/delete actions occur duriong the migration, ensuring data consistency.

Migrating PostgreSQL

PostgreSQL contains authoritative OpenAEV data and must be migrated to the new environment.

The migration approach depends on your PostgreSQL deployment model(managed database, in-cluster PostgreSQL, etc.) The recommended method is to perform a logical backup/restore using pg_dmp and pg_restore

On the source PostgreSQL instance Perform a backup of the OpenAEV database:

pg_dump -Fc -h <source_host> -U <user> -d <database_name> -f openaev.dump

On the destination PostgreSQL instance Restore the database:

pg_restore -h <destination_host> -U <user> -d <database_name> --clean --if-exists openaev.dump

Notes * Ensure the destination database is empty or that --clean is used to remove exiting objects * Ensure database roles and permissions are correctly recreated if they are not included in your dump strategy.

Migrating MinIO / S3

Info

We recommand using the MinIO client for this step: see MinIO Client documentation.

On a server that has access to both the source and destination MinIO service and buckets:

Create aliases for both the source and destination MinIO service

mc alias set minio-src minio_endpoint minio_access_key minio_secret_key

mc alias set minio-dst http://storage-hl:9000 minio_access_key minio_secret_key

For more information, see the MinIO [documentation](https://docs.min.io/community/minio-object-store/reference/minio-mc/mc-alias-set.html#command-mc.alias.set) about aliases.

!!! info

    You can find the destination MinIO credentials in the Kubernetes secret `minio-credentials` where you deployed OpenAEV.

Synchronize the data between the source and the destination bucket

mc mirror --overwrite --remove --retry minio-src/your_bucket minio-dst/openaev

For more information, see the MinIO [documentation](https://docs.min.io/community/minio-object-store/reference/minio-mc/mc-mirror.html) about mirroring buckets.

Elasticsearch / Opensearch

Elasticsearch / Opensearch does not need to be migrated.

OpenAEV automatically recreates the required indexes during startup based on the data stored in PostgreSQL.

This means: * No snapshot/restore procedure is required * No manual index copy is required * No migration is required between Elasticsearch and Opensearch

Important note

When OpenAEV starts in the new environment, it will rebuild the indexes from PostgreSQL.

Start OpenAEV

Once PostgreSQL and MinIO / S3 migrations are complete, you can start the OpenAEV components in the new instance: * OpenAEV front * Injectors * Collectors

OpenAEV will automatically create and populate Elasticsearch / OpenSearch indexes during startup.