-
- Service Provider
- Posts: 108
- Liked: 14 times
- Joined: Jan 01, 2006 1:01 am
- Full Name: Dag Kvello
- Location: Oslo, Norway
- Contact:
Two things I hoped was to be in VB&R 5
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.
"
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.
-
- Chief Product Officer
- Posts: 31773
- Liked: 7274 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Two things I hoped was to be in VB&R 5
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).dkvello wrote:As for Restore.. Restoring through FC would remove a big bottleneck.
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.dkvello wrote:AES-256 encryption, at the source
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.
-
- Veeam ProPartner
- Posts: 559
- Liked: 103 times
- Joined: Dec 29, 2009 12:48 pm
- Full Name: Marco Novelli
- Location: Asti - Italy
- Contact:
Re: Two things I hoped was to be in VB&R 5
Me too I've been asked by a customer to have the VBK file encrypted natively by Veeam Backup
Marco
Marco
-
- Service Provider
- Posts: 108
- Liked: 14 times
- Joined: Jan 01, 2006 1:01 am
- Full Name: Dag Kvello
- Location: Oslo, Norway
- Contact:
Re: Two things I hoped was to be in VB&R 5
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.
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.
-
- Chief Product Officer
- Posts: 31773
- Liked: 7274 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Two things I hoped was to be in VB&R 5
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?
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?
-
- Service Provider
- Posts: 108
- Liked: 14 times
- Joined: Jan 01, 2006 1:01 am
- Full Name: Dag Kvello
- Location: Oslo, Norway
- Contact:
Re: Two things I hoped was to be in VB&R 5
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.
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.
-
- Chief Product Officer
- Posts: 31773
- Liked: 7274 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Two things I hoped was to be in VB&R 5
Could you please elaborate this? Are you saying you want to be able to somehow open/verify what's inside of this container?dkvello wrote:since this is external to VB&R we can't actally know if what's inside the container is intact
-
- Service Provider
- Posts: 108
- Liked: 14 times
- Joined: Jan 01, 2006 1:01 am
- Full Name: Dag Kvello
- Location: Oslo, Norway
- Contact:
Re: Two things I hoped was to be in VB&R 5
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.
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.
-
- Chief Product Officer
- Posts: 31773
- Liked: 7274 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Two things I hoped was to be in VB&R 5
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 wrote: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.
-
- Service Provider
- Posts: 108
- Liked: 14 times
- Joined: Jan 01, 2006 1:01 am
- Full Name: Dag Kvello
- Location: Oslo, Norway
- Contact:
Re: Two things I hoped was to be in VB&R 5
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.
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.
-
- Chief Product Officer
- Posts: 31773
- Liked: 7274 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Two things I hoped was to be in VB&R 5
Yes, I am sure multiple servers will not be a problem, I was mostly inquiring about security side of things.
-
- Service Provider
- Posts: 108
- Liked: 14 times
- Joined: Jan 01, 2006 1:01 am
- Full Name: Dag Kvello
- Location: Oslo, Norway
- Contact:
Re: Two things I hoped was to be in VB&R 5
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.
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.
Who is online
Users browsing this forum: Google [Bot], Ivan239, Regnor and 88 guests