Two things I hoped was to be in VB&R 5

[dkvello]

From a competitors own v5 announcement:

"
Additional new features in vRanger Pro 5
•Fibre restore

New features in vReplicator 5
•AES-256 encryption, at the source
"

As an off-site DR provider the last one has been a stumblingblock for some time.
As for Restore.. Restoring through FC would remove a big bottleneck.

[Gostev]

As for Restore.. Restoring through FC would remove a big bottleneck.

Are you sure about this one? Have you actually tried to restore a thin disk through vStorage API? We had fibre restores implemented back in v4 in 2009, but decided not to enable this capability at all for now, because with current version of vStorage API, direct SAN restore performance of thin disks is pure nonsense (the issue is architectural on VMware side, which we did report them 2 years ago). Our network restores are at least 20x faster (I am not joking or anything, the speed is that abysmal - about 2 MB/s). In addition, this brings vCenter server to its knees by creating overwhelming amount of vCenter block-level tasks (you will see them spamming in vSphere Client).

AES-256 encryption, at the source

You do realize that vReplicator is only able to do this because it still does not support ESXi (and thus has the luxury of having agents on both ends)? Having said that, we do support encryption of network traffic for replication (SSL) - with Veeam Backup installed in target site and using vStorage API network mode. And, we are currently working on improving replication architecture, so with the next version we will allow for traffic encryption even when replicating to ESXi.

But anyway... for future occasions, please do not "hope" to see features delivered, but instead come here and ask us to add them, explaining the need. Until you and a few more people ask, we are unlikely to implement any feature. You know, Veeam is about "listening to you, building the tools you need". If you do not speak out, we will listen to someone else and give priority to other commonly requested features.

[m.novelli]

Me too I've been asked by a customer to have the VBK file encrypted natively by Veeam Backup

Marco

[dkvello]

I'll quit hoping

Restoring TB's of data in an off-site recovery situation (yes, I know vPower solves this in most cases) through Gigabit Ethernet isn't pleasurable.
Several 8GB FC links would be nice, but You guys know the limits of the VMware API's much better than me.

As for encryption...

Several customers wan't hosted, off-site DR replicas of their environment.
But, the transport isn't the problem (VB&R supports it, but we usally use encrypted tunnels anyways).
They want the off-site copy to be protected from unauthorized access i.e. They want the VBK's to be natively encrypted and Password protected so that only they can unlock it in a Restore/DR case.
We only host the VBK's and provide the HW infrastructure. They wan't to be the ones to unlock the VBK.

[Gostev]

Hmm... you referenced Replicator, so I thought you are talking about Replication specifically. And because replicas are stored in the native VMDK format on target, they cannot really be encrypted. So, I wrongly assumed you are talking about network traffic encryption.

I definitely see why backup file encryption is needed. Customers cannot trust all those hosting provider's administrators who has direct access to data. Can you clarify how those backup files are delivered to the client? Do they backup directly to provided target? Or do they RSYNC backup files?

[dkvello]

at the moment we have to back up locally into a Truecrypt container at the customer site.
then we rsync the container to our site.
the customer has the encryption keyfile and password to the container.
since this is external to VB&R we can't actally know if what's inside the container is intact.

Native encryption would save a lot of pain.
also, having rsync integrated in VB&R so that it would handle the offsite .VBK replication wouild be even better.

[Gostev]

since this is external to VB&R we can't actally know if what's inside the container is intact

Could you please elaborate this? Are you saying you want to be able to somehow open/verify what's inside of this container?

[dkvello]

No, If VB&R had native encryption I wouldn't have to encapsulate the .VBK/.-VBR files in an encrypted TrueCrypt container.

The problem now is that allthough I can see that the TrueCrypt container has rSynced successfully to our site, I'm prevented from checking that the contents are OK/recoverable since I don't have access to the customers certificate/password.

It's Like this:

At the customer site there is a chain of scripts that start the different backup-jobs.
There is a large x Terrabyte truecrypt container (just a file in windows) on D:

1) The first script mounts the x Terrabyte TrueCrypt container (wich is encrypted with a combo of password and certificate) as drive T:

2) It then does a quick test of T: to see that it mounted properly

3) The script then runs a sequence of tailored VB&R jobs that back up to T:

4) When all is done, T: is unmounted so as to free locks on the

5) An rSync job replicates the large truesync container from D: to our site.


The container can't be open on our side unless the customer provides the certificate/keyring file and it's password/passphrase, thus I won't know the true state of what's inside the container on our side.

I just have to trust that the .VBK inside isn't dammaged/corrupted and that the rSync has worked.


Now, if VB&R could encrypt the .VBK's itself I would only have to replicate the VBK without any ellaborate schemes.
If VB&R had rSync functionality for offsite (changed block level) replication of it's .VBK's then the Customers VB&R server could do the whole job and check that the .VBK on our side was intact without us needing the certificate/password.

[Gostev]

If VB&R had rSync functionality for offsite (changed block level) replication of it's .VBK's then the Customers VB&R server could do the whole job and check that the .VBK on our side was intact without us needing the certificate/password.

Performing check locally on your side would require customer's VB&R server to inject backup password to some local VB&R agent installed on your side, and the agent will do verification. Password will be kept in memory (not stored on disc), so intercepting it is will be quite challenging (although still possible with process debugger). Is this acceptable?

[dkvello]

if agent on our side could handle multiple external VB&R servers it would do.
So the agent would have to differentiate between different external VB&R servers in some way and be able to handle incoming jobs in parallell.

[Gostev]

Yes, I am sure multiple servers will not be a problem, I was mostly inquiring about security side of things.

[dkvello]

Security-wise this will suffice (a rhyme).
Not all customers have these specific demands, but we have several customers wich demands that only they can unlock the externally replicated .VBK
But as long as they choose us to host their off-site replica there will allways be a certain level of trust involved. Since we implement the solution we also need to test it every now and then.