Disaster Recovery plan

Automate your Disaster Recovery plan

This article is focusing on how GrapheneDB API can transform your Disaster Recovery plan.
The GrapheneDB API allows for the automation of essential operations such as creating snapshots, failovers, and data restoration, providing a seamless and efficient process even in the face of the worst-case scenarios.

DR plan including database cloning

This Disaster Recovery example plan includes cloning database, which will create a snapshot and a database clone, and switching connection URL from origin database to a cloned database. Important to note is that in a case of a disaster like zonal outage, when you create a new database it will land in a healthy availability zone.

1. Get Access Token

   curl https://api.db.graphenedb.com/organizations/oauth/token \
   -d "client_secret"="SECRET" \
   -d "client_id"="ID" \
   -d "grant_type"="client_credentials"

2. Get Environments (to get environmentId)

   curl https://api.db.graphenedb.com/deployments/environments \
   -H "authorization: Bearer ACCESS_TOKEN" \
   -H "content-type: application/json"

3. Get Database ID

   curl https://api.db.graphenedb.com/deployments/environments/{environmentId}/databases \
   -H "authorization: Bearer ACCESS_TOKEN" \
   -H "Content-Type: application/json"

4. Clone Database

   environmentId: the ID of the Environment you want the cloned database to be deployed into.

   curl -X POST https://api.db.graphenedb.com/deployments/databases/graphneo/{databaseId}/clone \
   -H "Content-Type: application/json" \
   -H "authorization: Bearer ACCESS_TOKEN" \
   -d "{"name": "string", "environmentId": "{environmentId}"}"

5. Switch Connection URL

   databaseId: The ID of the origin database. Its connection urls will be switched to the target database.
   target database (databaseId): The ID of the target database.

   curl -X POST https://api.db.graphenedb.com/deployments/databases/graphneo/{databaseId}/connections/switch \
   -H "Content-Type: application/json" \
   -H "authorization: Bearer ACCESS_TOKEN" \
   -d "{"targetDatabase": "{databaseId}"}"

Finally, you can delete the origin database, however, this should be reviewed with caution and decided when the deletion can be done, to ensure that you don’t lose the snapshots related to origin database. You can do it manually like this, or with the API request.

curl -X DELETE https://api.db.graphenedb.com/deployments/databases/graphneo/{databaseId} \
-H "authorization: Bearer ACCESS_TOKEN" \
-H "Content-Type: application/json"

What if cloning doesn’t work, what would be my DR plan then?

Although not likely, an outage might also affect the ability of creating new snapshots, thus affecting the cloning operation, so there is another approach you can prepare and have a Disaster Recovery plan ready. This Disaster Recovery example plan includes creating a new database out of a Snapshot, and switching Connection URL from origin database to the new database. Keep reading below to find out the steps.

Important to take into account for this Disaster Recovery plan is that you should have a good snapshot policy enabled, and even combine policies to have a good frequency and retention. For example, good snapshot policy for this situation would be the Extra Frequency one, that creates a snapshot every 3 hours, with a retention of 2 days.

1. Get Access Token

   curl https://api.db.graphenedb.com/organizations/oauth/token \
   -d "client_secret"="SECRET" \
   -d "client_id"="ID" \
   -d "grant_type"="client_credentials"

2. Get Environments (to get environmentId)

   curl https://api.db.graphenedb.com/deployments/environments \
   -H "authorization: Bearer ACCESS_TOKEN" \
   -H "content-type: application/json" 

3. Get database ID

   curl https://api.db.graphenedb.com/deployments/environments/{environmentId}/databases \
   -H "authorization: Bearer ACCESS_TOKEN" \
   -H "Content-Type: application/json" 

4. Get Snapshot ID

   curl https://api.db.graphenedb.com/deployments/databases/graphneo/{databaseId}/snapshots/scheduled \
   -H "authorization: Bearer ACCESS_TOKEN" \
   -H "Content-Type: application/json" 

5. Create database from Snapshot

   snapshotEnvironmentID: The ID of the Environment, where the database is deployed from which the snapshot was taken.
   environmentID: The ID of the Environment where the new database will get deployed.

   All other configuration for the database like plan, version, etc. will be retrieved from the Snapshot itself, and cannot be changed.

   curl -X POST https://api.db.graphenedb.com/deployments/databases/graphneo/restore \
   -H "authorization: Bearer ACCESS_TOKEN" \
   -H "content-type: application/json" \
   -d "{"snapshotId": "string", "snapshotEnvironmentId": "{environmentId}", "environmentId": "{environmentId}", "name": "string"}"

6. Switch DNS

   databaseId: The ID of the origin database. Its connection urls will be switched to the target database.
   target database (databaseId): The ID of the target database.

   curl -X POST https://api.db.graphenedb.com/deployments/databases/graphneo/{databaseId}/connections/switch \
   -H "Content-Type: application/json" \
   -H "authorization: Bearer ACCESS_TOKEN" \
   -d "{"targetDatabase": "{databaseId}"}" 

Finally, you can delete the origin database, however, this should be reviewed with caution and decided when the deletion can be done, to ensure that you don’t lose the snapshots related to origin database. You can do it manually like this, or with the API request.

curl -X DELETE https://api.db.graphenedb.com/deployments/databases/graphneo/{databaseId} \
-H "authorization: Bearer ACCESS_TOKEN" \
-H "Content-Type: application/json"

What if someone deletes all the data, what can I do?

If we think of some of the worst case scenarios to happen, one of them could be that someone from your Organization deletes all the data. There could be two possible disasters here:

• Someone deleting the database.
• Someone deleting data with a request.

There are ways to prepare a Disaster Recovery plan to minimize data loss and reduce time of getting back to the operational state. Let’s talk about what are the actual Disaster Recovery plans for these scenarios.

Someone deleting the database

First thing to ensure that you assign roles to your Organization members, enabling you to provide controlled access to different areas of the Organization. Roles can greatly help by just providing minimum access possible to manage production databases. Assignment to Environment is done via the Environment Type.

If possible, good practice here would be to use clones of production databases in different Environments, for providing access to data to different users, while minimizing access to production Environment to only few Admins for example.

Someone deleting data with a request

For this scenario where someone deletes a data with a request, you should have a good snapshot policy enabled and in place, and even combine policies to have a good frequency and retention. For example, good snapshot policy for this situation would be the Extra Frequency one, that creates a snapshot every 3 hours, combined with Extra Retention policy, which has a retention of 3 years.

Scheduled Snapshots cannot be deleted and will disappear from the system when expired following the expiration date depending on the Policy. On-demand Snapshots can be used before executing dangerous operations to be able to reduce the RPO as much as possible in case of a problem.

This Disaster Recovery plan would include the restore of the snapshot into the same database.

1. Get Access token

   curl https://api.db.graphenedb.com/organizations/oauth/token \
   -d "client_secret"="SECRET" \
   -d "client_id"="ID" \
   -d "grant_type"="client_credentials"

2. Get Environments (to get environmentId)

   curl https://api.db.graphenedb.com/deployments/environments \
   -H "authorization: Bearer ACCESS_TOKEN" \
   -H "content-type: application/json"

3. Get database ID

   curl https://api.db.graphenedb.com/deployments/environments/{environmentId}/databases \
   -H "authorization: Bearer ACCESS_TOKEN" \
   -H "Content-Type: application/json"

4. Get Snapshot ID (example for scheduled snapshots)

   curl https://api.db.graphenedb.com/deployments/databases/graphneo/{databaseId}/snapshots/scheduled \
   -H "authorization: Bearer ACCESS_TOKEN" \
   -H "Content-Type: application/json"

5. Restore database from Snapshot

   databaseId: The ID of the target database
   snapshotEnvironmentID: The ID of the Environment, where the database is deployed from which the snapshot was taken.

   curl -X POST https://api.db.graphenedb.com/deployments/databases/graphneo/{databaseId}/restore \
   -H "Content-Type: application/json" \
   -H "authorization: Bearer ACCESS_TOKEN" \
   -d "{"snapshotId": "string","snapshotEnvironmentId": "{environmentId}"}"