Add support for encrypted backups in online restores.#5226
Conversation
parasssh
left a comment
There was a problem hiding this comment.
Reviewable status: 0 of 14 files reviewed, 2 unresolved discussions (waiting on @manishrjain and @martinmr)
a discussion (no related file):
The same key should be used for re-encrypting the restored data.
graphql/admin/endpoints_ee.go, line 72 at r1 (raw file):
""" Path to the key file needed to unencrypt the backup. This file should be accessible
unencrypt -> decrypt
Also, the the same key in the file is used to re-encrypt the restored data.
martinmr
left a comment
There was a problem hiding this comment.
Reviewable status: 0 of 14 files reviewed, 2 unresolved discussions (waiting on @manishrjain and @parasssh)
a discussion (no related file):
Previously, parasssh wrote…
The same key should be used for re-encrypting the restored data.
This doesn't apply to online restores. The data has to be encrypted with the key used to start the cluster, which can be different. Online restores don't create a new db, they used the db used by the running alpha service.
graphql/admin/endpoints_ee.go, line 72 at r1 (raw file):
Previously, parasssh wrote…
unencrypt -> decrypt
Also, the the same key in the file is used to re-encrypt the restored data.
Done.
The second part is not true for online restores. The data will be encrypted with the same key used to start the cluster. This key doesn't necessarily have to be the same. I've added a note in the comment saying this.
parasssh
left a comment
There was a problem hiding this comment.
Reviewable status: 0 of 14 files reviewed, 3 unresolved discussions (waiting on @manishrjain, @martinmr, and @parasssh)
a discussion (no related file):
Makes sense.
manishrjain
left a comment
There was a problem hiding this comment.
Reviewable status: 0 of 14 files reviewed, 3 unresolved discussions (waiting on @manishrjain, @martinmr, and @parasssh)
Fixes DGRAPH-1233
This change is