Add: Doc for restore CLI (#7837)

* Add: Doc for restore CLI

* Add: Restore cLI page move to Backup CLI page

* Fix: Change based on comments
This commit is contained in:
Milan Bariya 2022-10-03 12:34:27 +05:30 committed by GitHub
parent 4307c7c4aa
commit 3a9f1197da
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -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
```