Applies to: Kyvos Enterprise Kyvos Cloud (SaaS on AWS) Kyvos AWS Marketplace
Kyvos Azure Marketplace Kyvos GCP Marketplace Kyvos Single Node Installation (Kyvos SNI)
Prerequisites
To create a back up of the data stored in S3 buckets, Kyvos uses the following features of AWS:
Cross-Region Replication
Versioning, along with their lifecycle configurations
Replication configurations.
To back up data, Kyvos needs a separate destination bucket in a region other than that of the source bucket.
Cross-account destination bucket replication provisioning should not be provided.
CRR should be enabled on the source bucket only (or its subset).
CRR requires the source and destination buckets with versioning enabled.
Setting up replication bucket
Create a destination bucket where you want to set up a Disaster Recovery (DR) cluster.
Enable versioning on both Source and Destination S3 buckets.
Create Lifecycle rules.
On Source bucket enable Replication and perform the following steps:
Source section
Provide replication rule name.
In Source choose a rule Scope as Limit the scope of this rule using one or more filters.
Provide the prefix as kyvos working directory, such as: user/engine_work
Destination section
Choose a bucket in this account.
Provide IAM roles for copying data from bucket one to two. Refer to the AWS document for details.
In Additional replication options, select the Delete Marker Replication option.
NOTE: You must manually copy the existing data after enabling Replication.
Setting up DR in RDS (Postgres)
Refer to the AWS document for configuring DR in RDS.
Kyvos uses manual backup for cross-region replication. The manual backup option is ensuring by our scripts which is insuring by Kyvos scripts.
Restoring data in case of a disaster
To restore data in case of a disaster, perform the following steps.
Log in to your AWS account.
Select the new region where you have replicated your S3 data.
Go to CloudFormation and deploy the new DR template of Kyvos.
Provide all the required parameters in the template.
Bucket Name should be the same as Replication Bucket.
IAM role of Lambda and EC2 should be the same as original deployment.
Provide Existing RDS, that should be restored before deploying the DR template.
CIDR for VPC creation should same as the original deployment.
Points to remember
When using this solution, keep the following in mind:
If DR happened, then you cannot move to the Original installation. The DR cluster will be the Primary cluster and you must set up the replication bucket again.
Once the deployment is complete, you MUST change the S3 bucket name in all the datasets, as the raw data bucket is also changed due to DR.
If the primary deployment was on a private network (tunneling established between Customer and Kyvos AWS VPC), then you must do the same procedure again after DR deployment.
Once the deployment is complete, you need to wait for Cuboid replication on all the query engines for executing queries.
Once the deployment is complete, you must enable TLS and SSL again in Kyvos.
If any additional IPs were allowed in the Security group of primary installation, you MUST configure the same in the DR Security Group too.
Once the DR deployment is complete, you need to create the custom URL and DNS mapping again.
You need to manage the Glue tables and source data after the DR deployment.
Post DR deployment steps
After completing the DR deployment, perform the following:
Ensure the license has been uploaded and verified from both Kyvos and Kyvos Manager UI.
NOTE: You will need a new license will be required as the Kyvos production license is mapped with instance ID.Verify user can log in to the Kyvos Manager portal.
Verify the desired number of BI Servers and Query Engines are available on Kyvos Manager Portal.
Verify user can log in to Kyvos Portal.
Verify all the users are imported into Kyvos.
Verify access rights of the imported users.
Verify the desired number of BI Servers and Query Engines are up and running.
Verify validation and preview operation on datasets created on S3 files.
Verify validation and preview operation on datasets created on HCatalog.
Verify validation and preview operation on datasets created on Snowflake.
Verify all data has been recovered (check if all entities are available).
Verify job history of entities.
Verify build cubes are browsable.
Verify all the Query Engines can serve queries.
Verify cuboids are replicated locally on Query Engines disks.
Verify only incremented data is processed in incremental builds.
Verify Live query analysis is working.
Verify Historical query analysis has all the data prior to the disaster also.
Verify Audit logs have all the data prior to the disaster also.
Verify completed jobs on Activity Monitor has all the data prior to the disaster.