Closed garbados closed 2 years ago
Here is an example output of the script:
# Encrypting an existing decrypted database
Writing 1000 docs...
Setting up the encrypted copy...
Loading docs into encrypted copy...
Preparing to export to new database...
>> DESTROYING ORIGINAL <<
Replicating encrypted copy over original...
Setting up new database to use original as encrypted copy...
Loading docs from encrypted copy...
Verifying that all expected contents have been copied over...
Final DB has 1000 decrypted documents in it.
OK!
Encrypting 1000 in place took 2153ms.
Latest output of the script:
# Encrypting an existing decrypted database
You can encrypt a database "in-place" by copying its contents
over to a transient replica, encrypting documents as you go.
Once the replica is finished, empty the original and replicate
the replica onto it. After that, the original will be encrypted.
First, we'll load some docs into our unencrypted original,
to mimic the documents you already have in yours.
Writing 1000 docs...
Setting up the transient encrypted copy...
Encrypting docs and load them into the transient copy...
Saving the export string needed for decryption...
>> EMPTYING ORIGINAL <<
Replicating encrypted transient copy to populate emptied original...
In order to decrypt documents, both a password and an export string are required.
So, we set up the now-encrypted original with the export string from the
transient copy. Then you will be able to decrypt documents.
Using the saved export string to set up decryption with new original...
Loading docs from original into the new decrypted database...
Verifying that all expected contents have been copied over...
New decrypted database has 1000 documents in it.
Encrypting 1000 in place took 2072ms.
This PR adds a new example that demonstrates how to encrypt a database "in-place." This process has a few steps:
This example closes https://github.com/garbados/comdb/issues/27 by demonstrating a solution to encrypting a database in-place.
NOTE: THE DATABASE BEING ENCRYPTED WILL BE UNAVAILABLE DURING THIS PROCESS. READS DURING THIS PROCESS MAY RETURN UNEXPECTED DATA, AND WRITES MAY BE LOST. DO NOT USE THE DATABASE DURING THE ENCRYPTION PROCESS.