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

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

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

- External tools. Read more in the [Data migration from embedded to external databases in BRIX On-Premises](embedded-to-external-database-enterprise.md) article.

- **brix365-Backupper** utility.

The main steps of data migration using **brix365-Backupper** utility:

1. [Back up databases](#backup).

2. [Update BRIX application parameters](#update-parameters).

3. [Restore databases](#restore).

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

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

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

## ````
Step 1: Back up databases

1. Install the **brix365-Backupper** utility and set up its configuration. Read more about it in the [Back up and recover databases](database-backup-and-recovery.md#install-elma365-backupper) article.

2. Back up the BRIX application databases:

````
brix365-backupper backup <<db-type>>

````
Where \[OBJECT\] is the name of the database that you want to back up. Value options:

- \[OBJECT\] specifies MongoDB.

- \[OBJECT\] specifies PostgreSQL.

- \[OBJECT\] specifies S3 storage.

- \[OBJECT\] specifies all databases (MongoDB, PostgreSQL, S3).  
  
To specify two databases, you can combine the `mongo`, `postgres`, and `s3` values by separating them with commas. For example,` postgres,s3` or `mongo,postgres`.

## Step 2: Update BRIX application parameters

1. Since the **brix365-Backupper** utility gets the database path settings from the \[OBJECT\] configuration file, [specify the values of external storages in this file](change-settings-enterprise.md#connection-kb).

2. 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:

````
root@brix-node1:~#  
root@brix-node1:~# helm show chart brix365/brix365  
apiVersion: v2  
appVersion: 2023.6.7  
description: Brix365 full application chart  
name: brix365  
type: application  
version: 2023.6.7

````


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.



## Step 3: Restore databases

1. Restoring from backup should be done to empty databases and S3 storage. So clean them with the \[OBJECT\] key.

2. Restore the databases from the last backup:

````
brix365-backupper restore <<db-type>>

````
Where \[OBJECT\] is the name of the database for which you want to get a list of backups. Value options:

- \[OBJECT\] specifies MongoDB.

- \[OBJECT\] specifies PostgreSQL.

- \[OBJECT\] specifies S3 storage.

- \[OBJECT\] specifies all databases (MongoDB, PostgreSQL, S3).  
  
To specify two databases, you can combine the `mongo`, `postgres`, and `s3` values by separating them with commas. For example,` postgres,s3` or `mongo,postgres`.

3. [Reactivate the system](activate_on_premise.md).