Initial Setup of Encrypted Cloud Drive

Previously we wrote about Using lsyncd for Continuous Data Protection and Using rclone for remote storage in order to create an inexpensive, robust, and portable (across cloud providers) system for an encrypted cloud drive. If you have a lot of data, there are some tricks for faster setup.

One thing to keep in mind is that encryption can slow down file transfers a bit and sometimes using rclone is slower than the native cloud software. The end result is that your initial setup of an encrypted continuous data protection system might feel … not very fast.

One way to speed things the first time is to setup a local-to-local encrypted mount and run all your data through that. Then you can move the encrypted local data using the native cloud client (e.g., the Dropbox client, pCloud client, Google Drive client, or whatever you prefer). See below for details.

For example, imagine you are using pCloud, and you want to move the directory name /home/me into the cloud with encryption. You could first setup a local-to-local mount via something like the following:

Setup the local-to-local rclone config as follows:
- Enter the command rclone config
- Choose n for new remote
- Choose a name like localencryption
- Choose crypt for storage
- Choose /tmp/local-ciphertext or whatever path you desire for the remote
  - Note that this “remote” is just storing your data in encrypted form on the local path /tmp/local-ciphertext.
- Choose desired encryption settings, passwords, etc.

Mount the new encrypted local rclone “remote” via:

      rclone mount localencryption: /tmp/local-plaintext

Copy your data into the local mount:
- You can just use the cp command on linux:
```
          cp -r /home/me /tmp/local-plaintext
```
- You could also use rsync (in multiple different ways as described below) instead of the above. For example, you could do something like:
```
          rsync -avz -P /home/me /tmp/local-plaintext
```
  - The benefit of rsync is that it can be more verbose so you see what is going on, see how fast the transfer from plaintext to ciphertext is happening, and with the -P flag it can be easier to resume if something goes wrong.
  - Also, rsync will allow you to specify an --exclude-from argument if you want to avoid certain files.
- Another way to use rsync is
```
          rsync --size-only -rvt --delete -P \
              --exclude-from=excludes.txt \
              /home/me /tmp/local-plaintext
```
  - The --size-only may be useful since the local mount may not preserve ctime and so you want rsync to use the file size to determine differences (at least the first time around).
  - The -rvt instead of -avz is so that your local mount does not try to de-reference symbolic links or preserve owner/group/permissions which can sometimes cause problems for the mount.
- You may need to wait a while for the cp or rsync to finish before moving onto the next step. When things are finished your /tmp/local-plaintext directory will look like it contains a copy of your /home/me directory while your /tmp/local-ciphertext directory will contain the encrypted versions.
Copy your encrypted data to your cloud drive:
- You can just use the cp command on linux:
```
          cp -r /tmp/local-ciphertext /my/cloud
```
  where /my/cloud represents your cloud drive for Dropbox, pCloud, Google Drive or whatever directory your native cloud software is going to push into the cloud. On Windows, you might want to use something like robocopy via
```
          robocopy /e /z "c:\temp\LocalCipherText" "p:\my\cloud"
```
  since robocopy is more robust than regular windows copy.
- The key point is that you are moving the encrypted /tmp/local-ciphertext directory so that the native cloud client is only seeing your encrypted data and not the original.
- You could also use rsync instead of the above. For example, you could do something like:
```
          rsync -avz -P /tmp/local-ciphertext /my/cloud
```
  - One reason to use rsync here is if you have either a lot of files or a lot of data. In either case, your cloud native software client might balk at suddenly sending a lot of data into the cloud and being able to kill, resume, see what is going on, etc., is convenient.

software