# Data migration from embedded to external databases in BRIX On-Premises

> [HTML Version](embedded-to-external-database-enterprise.html)

You can migrate data from databases within a Kubernetes cluster to external storages using:

- External tools.

- **brix365-Backupper** utility. Read more in the [Data migration from embedded to external databases in BRIX On-Premises: customized utility](embedded-to-external-database-enterprise-backupper.md) article.

The main steps of data migration by external tools:

1. [Prepare to data dump creation](#preparation).

2. [Create a data dump](#dump).

3. [Restore data on external storage](#restore).

4. [Update BRIX On-Premises application parameters](#update-parameters).

````
начало внимание

````
After migrating databases to external storages, [system reactivation](activate_on_premise.md) is required.

````
конец внимание

## ````
Step 1: Prepare to data dump creation

1. First, install the** jq** package.

2. To access the databases within the cluster, forward the service ports:

````
kubectl port-forward postgres-0 5432:5432 --address 0.0.0.0  
kubectl port-forward mongo-0 27017:27017 --address 0.0.0.0

3. ````
Get and save passwords for connecting to the databases:

````
kubectl get secrets/brix365-db-connections -o json | jq '.data | map\_values(@base64d)'

## ````
Step 2: Create a data dump

1. Generate a data dump file for PostgreSQL using the **pg\_dump** utility:

````
pg\_dump -h localhost -p 5432 -U postgres brix365 -f /backup/<backup-postgresql-folder-name>

````
Enter the password obtained in the first step.

2. Generate a data dump file for MongoDB using the **mongodump** utility:

````
mongodump --host localhost --port 27017 --db brix365 -u brix365 --out /backup/<backup-mongodb-folder-name>

````
Enter the password obtained in the first step.

Read more about these utilities in the [External BRIX backup](dump_db.md) article.

## Step 3: Restore data on external storage

1. Restore from backup on empty databases and S3 storage. Clear them before restoration.

2. Restore PostgreSQL data using the **psql** utility:

````
psql -h <external\_db\_host> -p <external\_db\_port> -U <username> -d <database\_name> -f /backup/<backup-postgresql-folder-name>

````
Where:

- \[OBJECT\]. The host of the external database.

- \[OBJECT\]. The port of the external database.

- \[OBJECT\]. The user name of the external database.

- \[OBJECT\]. The name of the database on the external server.

3. Restore MongoDB data using the **mongorestore** utility:

````
mongorestore --host <external\_db\_host> --port 27017 --db <database\_name> -u <username> --dir=/backup/<backup-mongodb-folder-name>

````
Where:

- \[OBJECT\]. The host of the external database.

- \[OBJECT\]. The user name of the external database.

- \[OBJECT\]. The name of the database on the external server.

4. Restore the S3 storage data using the **mc** utility:

````
mc alias set <alias\_source> <s3-endpoint\_source> <access-key\_source> <secret-key\_source>  
mc alias set <alias\_destination> <s3-endpoint\_destination> <access-key\_destination> <secret-key\_destination>

````
Where:

- \[OBJECT\]. The short name (alias) for the source.

- \[OBJECT\]. The address of the S3-compatible source storage.

- \[OBJECT\]. The access key for the source.

- \[OBJECT\]. The secret key for the source.

- \[OBJECT\]. The short name (alias) for the destination.

- \[OBJECT\]. The address of the S3-compatible destination storage.

- \[OBJECT\]. The access key for the destination.

- \[OBJECT\]. The secret key for the destination.

Then copy the S3 storage from the source to the destination:

````
mc cp --recursive <s3-endpoint\_source>/bucket-name/ <s3-endpoint\_destination>/bucket-name/

````
Where:

- \[OBJECT\]. The short name (alias) for the source.

- \[OBJECT\]. The short name (alias) for the destination.

- \[OBJECT\]. The bucket name.

- \[OBJECT\]. Recursive copying of all objects and files.

5. After restoring the databases on external storage, [reactivate the system](activate_on_premise.md).

## Step 4: Update BRIX On-Premises application parameters

1. After restoring data on external databases, make sure that all tables for PostgreSQL or collections for MongoDB are migrated correctly.

2. To configure the BRIX On-Premises application to use external databases, change the database and S3 file storage connection settings in the \[OBJECT\] configuration file.

3. Update the BRIX application parameters using the \[OBJECT\] configuration file.

Updating parameters via the Internet

1. Identify the version of the chart from which the BRIX application was installed or updated:

````
helm show chart brix365/brix365

````
  
Example of how to execute the command:

**(embedded-to-external-database-enterprise-1.png)**

The chart version will be specified in the \[OBJECT\] string. Save this value for the next step.

2. Update the BRIX application parameters using the \[OBJECT\] configuration file. To do this, use the following command, specifying the installed chart version for the \[OBJECT\] key instead of \[OBJECT\]:

````
helm upgrade --install brix365 brix365/brix365 -f values-brix365.yaml --version <brix365-chart-version> --timeout=30m --wait \[-n namespace\]

````


Updating parameters without the Internet connection

  
Go to the folder with the downloaded BRIX chart and run the command:

````
helm upgrade --install brix365 ./brix365 -f values-brix365.yaml --timeout=30m --wait \[-n namespace\]

````
  
The parameter upgrade takes 10-30 minutes. Wait for it to complete.



4. Restart all services with the command:

````
kubectl rollout restart deploy \[-n namespace\]

5. ````
Verify the system is working correctly and stop old databases inside Kubernetes:

````
kubectl scale statefulset <db-type> --replicas=0 \[-n namespace\]

````
Where \[OBJECT\] is the name of the **StatefulSet**: \[OBJECT\], \[OBJECT\], or \[OBJECT\].