diff --git a/openmetadata-docs/content/deployment/upgrade/backup-metadata.md b/openmetadata-docs/content/deployment/upgrade/backup-metadata.md
index dc055a6eacc..8195782d2dd 100644
--- a/openmetadata-docs/content/deployment/upgrade/backup-metadata.md
+++ b/openmetadata-docs/content/deployment/upgrade/backup-metadata.md
@@ -43,6 +43,7 @@ Instead, we have created a utility that will just dump the necessary data.
 The requirement for running the process is that the target database should have the Flyway migrations executed.
 
 The backup utility will provide an SQL file which will do two things:
+
 1. TRUNCATE the OpenMetadata tables
 2. INSERT the data that has been saved
 
@@ -124,14 +125,14 @@ We can do a test locally preparing some containers:
 
 1. `sh docker/run_local_docker.sh` to start the `docker compose` service.
 2. `docker run -p 9000:9000 -p 9001:9001 minio/minio server /data --console-address ":9001"` to start minio, an object
-  storage S3 compatible. 
-3. Connect to [http://localhost:9001](http://localhost:9001) to reach the minio console and create a bucket 
-  called `my-bucket`
+   storage S3 compatible.
+3. Connect to [http://localhost:9001](http://localhost:9001) to reach the minio console and create a bucket
+   called `my-bucket`
 4. Finally, we just need to prepare the environment variables as:
-    ```
-    export AWS_ACCESS_KEY_ID=minioadmin
-    export AWS_SECRET_ACCESS_KEY=minioadmin
-    ```
+   ```
+   export AWS_ACCESS_KEY_ID=minioadmin
+   export AWS_SECRET_ACCESS_KEY=minioadmin
+   ```
 
 An example CLI call will look as:
 
@@ -152,3 +153,65 @@ Uploading dir1/dir2/openmetadata_202201250823_backup.sql to http://localhost:900
 If we now head to the minio console and check the `my-backup` bucket, we'll see our SQL dump in there.
 
 <Image src="/images/deployment/backup/minio-example.png" alt="minio"/>
+<br/>
+<br/>
+
+# Restore Metadata
+
+## Introduction
+
+SQL file which is generated using Backup metadata CLI
+can restore using Restore metadata CLI.
+
+## Requirements
+
+The restore CLI needs to be used with `openmetadata-ingestion` version 0.12.1 or higher.
+
+## Restore CLI
+
+After the installation, we can take a look at the different options to run the CLI:
+
+```commandline
+> metadata restore --help
+Usage: metadata restore [OPTIONS]
+
+  Run a restore for the metadata DB.
+
+  We can pass as many connection options as required with `-o <opt1>, -o
+  <opt2> [...]` Same with connection arguments `-a <arg1>, -a <arg2> [...]`
+
+  If `-s` or `--schema` is provided, we will trigger a Postgres Restore
+  instead of a MySQL restore. This is the value of the schema containing the
+  OpenMetadata tables.
+
+Options:
+  -h, --host TEXT       Host that runs the database  [required]
+  -u, --user TEXT       User to run the restore backup  [required]
+  -p, --password TEXT   Credentials for the user  [required]
+  -d, --database TEXT   Database to restore  [required]
+  --port TEXT           Database service port
+  --input PATH          Local backup file path for restore  [required]
+  -o, --options TEXT
+  -a, --arguments TEXT
+  -s, --schema TEXT
+  --help                Show this message and exit.
+```
+
+### Output
+
+The CLI will give messages like this `Backup restored from openmetadata_202209301715_backup.sql` when backup restored completed.
+
+### Trying it out
+
+An example CLI call will look as:
+
+```commandline
+metadata restore -u openmetadata_user -p openmetadata_password -h localhost -d openmetadata_db --input openmetadata_202209301715_backup.sql
+```
+
+And we'll get the following output:
+
+```commandline
+Restoring OpenMetadata backup for localhost:3306/openmetadata_db...
+Backup restored from openmetadata_202209301715_backup.sql
+```