Version 5

[RJI]

We are currently evaluating Veeam backup 4.1 but need a copy of fixes or enhancements currently scheduled for v5. Is there an ETA for it yet?

Richard

[rowdy]

You know you are going to get the 'Blizzard'-answer (Starcraft 2 anyone?)

It's done when it's done and it will always contain some exciting new features.

Between the lines however, I believe to have picked up that a future version will (also) contain forward increments, so it's easier to send them over a WAN to another location every day. If you want to move the backups off-site every day now, you will have to transfer (for example) 50 GiB every day, because the incrementals are 'backwards'. With forward incrementals, you transfer 50 GiB once and every day (for example) around 500 MB.

Please note that this all is my personal opinion and not that of VeeAm, nor has this feature been officially confirmed by VeeAm.

[Gostev]

Rowdy, I can see you have great experience dealing with software vendors
I usually say either Soon™ or When it is done™

You are correct about the option for forward increments, this will be one of the features for v5.

Richard, based on your evaluation of 4.1, do you agree that our product has best functionality and value on the market today? Or does it still lack some functionality that is critical for you, and you wanted to see if it will be available in v5? Can you tell me what is this functionality? Always interested to hear feedback!

Unfortunately, our official position is not to disclose the roadmap at this point. I have provided detailed explanation of our position in the following post.

Thank you.

[Techserv]

For me, If Veeam 5 could do email level backups of Exchange 2010 so that individual emails can be restored just like files that would be amazing!

[RJI]

Two things we require in v5 that I don't believe are in v4.1.

1) VM copy being able to exclude volumes from a copy operation.

2) Thin to Thin replication.

Yes I think this product would fit our uses best out of the ones we have tried.

Thanks,

Richard

[Gostev]

Richard, yes both of these enhancements are planned for v5. Thank you!

[withanh]

Is v5 what's coming next, or are you doing a point release (i.e. 4.2 or 4.5) first?

[Gostev]

Yes, it is v5... we are planning to start gradually rolling out information about the new release in the coming weeks. Get ready for some truly breakthrough innovations.

[fgw]

performance of veeam backup during backup operations is fine for me. have seen raw read bandwidth of up to 200MB/s on our HP eva4400 san environment with backups running to local raid0+1 disks on the backup server.

and this is still without optimized multipath cnfiguration. i'm currently reconfiguring the systems in regards of multipath and am curious what performance i will see when this is set up as i think it should be.

anyway, what i would like to see is the ability to do restores dircetly to san without the need to run through networkinterfaces on the esx servers. this is a real pain rigth now as we all know restore is THE timesensitive task ...

don't know if it is even possible to do restores directly to san and if this feature is already available via vmware api.

[fredbloggs]

Just thought I'd raise a request about features I would like, and from reading the posts seem to be scoped for some future release.

Believe on the roadmap
1. Forward incrementals for more tape / wan friendly replication
2. VSS level backups of VMs without direct network or RPC connectivity between the backup server and the VM
3. Exchange mailbox level backups (whilst haven't seen this specifically mentioned, it has been noted in virtually every post by Gostev that this is a popular request)
4. Thin to Thin replication


Don't know if these are planned
1. Any Exchange backup should ensure that the database is consistent before flushing the logs, warning if not.
2. Would be nice if there was a way for the backup server (windows in my situation) to be able to replicate and know what to replicate to a server across a WAN instead of running a heavy rsync job
3. Would be nice if like VRanger we could specify all the jobs to run at the same time but to only backup y number of VMs at any one time based upon host, vmfs volume, cluster etc.
4. Deduplicated restore would be good, though haven't seen this mentioned anywhere
5. When restoring being able to specify which datastore you want which vmdk's to restore to
6. A report that can tell you the protection policy for specified VMs, specifically notifying if any VM's in a cluster are not backed up
7. Improvements in scheduling of replications, whilst it'd be nice to say replicate every hour I'd like to be able to say except during 11 - 3pm for example
8. Replicate vmdk's on a VM to different LUNs
9. If there is a snapshot already in place on the VM, then don't run the Veeam snapshot. I have seen this corrupt data in certain situations
10. Indexing of backup contents. Whilst I realise this will increase any backup time, it'd be nice to be able to say I need to restore this file from this VM and for Veeam backup to say I have this file in these backup files (same with the Exchange items possibility

Apart from that, think you guys are on the money with all of these and i'm sure you have many other great features that I don't know I need yet but will love.

Cheers

[Gostev]

Thank you all for your feedback.

Some comments and questions:
- What exactly do you mean by 4?
- 7 is actually in the product today.
- 9 does not make sense to me as using existing snapshot would make the product backup old VM state (at the time when the existing snapshot was taken). The product would keep backing up this same old state until the snapshot is removed.

[fredbloggs]

Thanks

4. I'll try and explain this. What I mean is that we have a deduplicated vbk of 5 VMs the vbk is say 1/5th the size (extreme example) than it would be if I had 5 x VBK's, if I want to restore all those VMs then I would end up copying the required contents for each VM individually and therefore copying 5 times as much data from the backup store to the VM store. Whilst i can't think of any way that you can reduce the amount of writing to the target store (though if you can please do ), a deduplicated restore would only read the data once from disk before sending it out to the required vmdk's. Sometimes the backup store is the bottleneck.

Hopefully that explains that a little better

7. Ok, I'll tell my colleague, he's been looking for this

9. We have a product that takes regular windows vss snaphots of file servers and backs this data up to a central store. Users are able to perform user level recovery of files from this backup store. We have found in the past if during one of these VSS snapshot backup periods if Veeam runs a backup (VSS) aware then data has become corrupt. Personally I haven't seen this but my colleagues have. This is a request they have passed on. I do have veeam backing up a DPM server (though not the vmdk's with the data) and haven't found this issue

Cheers

[rogersillars]

We've been using v4.0 and v4.1 after v3 and is a huge improvement! We're running both replication jobs (DR site) and backup jobs (local site for longer term recovery). The setup is fantastic but has a few minor pains. We have off site replication for 3 days to a live ESX server (power on and away we go) and backup for around a month. The only tape we use now is once per month for archiving.

I'd like to see the following:
1) A wait for job to finish option on the command line (you can get around this by using both PowerShell and the EXE but would be better to just use PowerShell)
2) A retry x times after x options from the command line
3) A destination option for each VM rather than job
One of the pains I have is that ESX is limited to 2TB disks. We have a DR site that has a 5TB array but we have to split it up because of VMFS. Because of this, and the size of our VMs we have to run multiple jobs in order to set the destination (only for each job, not each VM). We have 11 Replication jobs and 11 Backup jobs which isn't really required. One benefit of this is that we run a replication, once that is done the backup is run so we can have multiple jobs running at the same time and not conflicting with each other.

The only other thing I have had problems with is every now and then the backup fails and we can't remove the snapshot. It turns out that the VM's disk is still attached on the Veeam appliance. In order to fix you have to remove this from the appliance, create another snapshot and then delete all snapshots. For some VMs this is a real pain such as our SQL or Exchange servers as they take ages to recover.

[dkvello]

Have You considered using extents to bypass the <2TB limitation on VMFS on Your DR site ?

[rogersillars]

Hi. Yes I have but everything I have ready suggests not to do it. However nothing I have read suggests why. Any ideas?

[Gostev]

As far as I know all those negative opinions about using extents come from in VMFS-2 times. VMFS-3 has addressed pretty much all issues with using extents.

[Gostev]

As far as I know, all those concerns about extents were related to VMFS-2 only... VMFS-3 has most of them addressed.

[rogersillars]

Thanks Anton. I'll ask on another forum, it really would make it easier.

[pentana]

The reasoning for not using extents is because if one of the extends gets corrupted or fails, you lose the whole datastore, as opposed to using separate VMFS datastores.

As the following states, VMFS3 can now use a 64TB LUN rather than the 2TB limitation for the VMFS filesystem itself. This needs to use vSphere though.
The 2TB file limit still stands however with a 8MB block size. Although I imagine if you have a 2TB vmdk something is wrong
http://en.wikipedia.org/wiki/VMware_VMFS

[Gostev]

The reasoning for not using extents is because if one of the extends gets corrupted or fails, you lose the whole datastore, as opposed to using separate VMFS datastores.

Actually, from what I know, in VMFS-3 you only loose whole datastore if you lose the first (original) extent. This makes it no worse than "standard" single volume/LUN config. Loosing LUNs backing other VMFS extents will not cause whole datastore loss - the file system will still be accessible.

[rogersillars]

Thanks everyone, I’ve done a bit more research. It appears that ESX supports a maximum LUN size of 2TB, if you want more space then you use Extends. In my case I have a standalone DR server with a 6x 1TB DAS array so when I setup one large LUN for ESX it didn't even display it in the setup. So I setup 2x 1.9TB and 1x 700GB (ish). From my initial research Extends=bad. However after my more recent research that appears to be with VMFS v2, not VMFS v3. So in my case if I lose one array it is highly likely that it would be that multiple disks have failed and it would take out my other arrays also as they are on the same physical disks. When I get a chance I’ll kill the last two data stores and use extends to add the space to the first one. Then it would be much easier to manage and be more flexible.