Layers of DrivePool / CloudDrive

[rbutler81]

Hi all, here's what I want to do:

 

I have 5 physical drives.

I placed them all into a DrivePool.

I created a local "CloudDrive" equal to the size of the DrivePool. I made it an encrypted CloudDrive. This CloudDrive's local location is in the DrivePool.

I'll be placing my files into the encrypted CloudDrive, which will in turn save them into the various physical drives that make up the DrivePool that the CloudDrive is in. 

 

Question 1: Does the option for "upload verification" matter when the CloudDrive is located on a local disc?

To note: I tried making a local CloudDrive with this option turned on and the UI would freeze / crash. It wasn't until I turned it off that I could even successfully create a local CloudDrive.

 

Question 2: What sort of performance hit should I expect?  I know that everything being copied to this local CloudDrive will be encrypted on the fly, and that it's only a logical drive on top of another logical drive that finally writes to physical drives. Big performance hit?

 

I'm eventually thinking of creating a *real* CloudDrive in Google and adding it and the local CloudDrive to yet, another DrivePool so that I can duplicate the local, physical drives to the cloud.

Good idea? Bad idea? Am I asking for trouble with respect to performance hits?

 

I have a 6th drive that's an SSD that I'm using as a cache drive for all of this too, just an FYI.

 

Am I foolish to trust my data to this encryption? Has there been instances of data loss due to unrecoverable data?

 

Thanks!

 

 

 

[Christopher (Drashna)]

1. Upload verification isn't necessary for local drives. Namely, it's making sure the file is uploaded properly.  Since we're using local access API, we should know regardless of the setting.  

    

   That said, "upload verification" isn't an option when creating a drive. 

   That said, integirty checking is.  And that shouldn't lock up the system/UI. 

    

   If you are seeing that, could you reproduce and run this:

   http://dl.covecube.com/Troubleshooter/StableBit.Troubleshooter.exe

    

2. The performance hit for encryption? That depends on the CPU and the instruction set included. 

   Specificially, we use the Microsoft CNG (Cryptography Next Gen) API, which is very fast, and leverages AES-NI and the like to speed this up even further. 

   Alex (the Developer) talks about this and more here: http://community.covecube.com/index.php?/topic/1269-full-drive-encryption/

    

    

   The biggest performance hit will be when accessing the drives. The actual drives, specifically. Slower drives will introduce more lag time, while faster drives will improve performance.  And this goes doubly for the cache. 

 

As for creating a disk on Google Drive and pooling that with the local CloudDrive disk, there shouldn't be a problem with that at all. 

 

The caveat, is that you may want a different drive for the cache, to seperate the IO load on the disks. 

 

 

 

Am I foolish to trust my data to this encryption? Has there been instances of data loss due to unrecoverable data?

 

The only data loss that we've had is when people have lost their encryption keys.  We don't have a way to recover these or the data on them.  Period.   

 

You lose the key, you lose the data. It's that simple.  

 

 

The other is if there is damage to the drive.  This can occur just like on a physical disk, and corrupt the data.  We've had a few people that have run into this.  That said, you can run data recovery on the drives, just like a normal disk.   This is because the underlying disk data is encrypted, not the volume.  normal recovery programs will work. 

 

 

That said, there is ALWAYS risk in using encryption. It increases the probability of something going wrong, because it's an additional step/layer.  

 

The question becomes, is it worth that risk?