V9 release date?

[csinetops]

Is there a estimated release date for version 9?

I attended Veeamon last week ( it was awesome) and see a lot of useful features in V9 for a backup rework project we are in the middle of that would solve lots of pain points for us.

If I have a general idea ( a week, a month etc) on a V9 release date, I could make some better informed decisions on holding off on writing our procedure for V9.

Thanks!

[JaxIsland7575]

I have not seen the official word on when it is coming out, but you can register your email to be notified here: http://go.veeam.com/v9#emc

I understand your struggle, I am also struggling through some tape issues that looks like v9 is going to fix.

I also agree that VeeamOn was amazing!

[Vitaliy S.]

It is scheduled to be available later this year, and yep, VeeamON was awesome!

[csinetops]

Good deal, I just need a plan in place by year end so timing on that should work nicely.

[kjstech]

I also need a plan by year end. Budgeted for EMC Data Domain and read horror stories on restore performance. A vague post said V9 has some features to help. Need to know if I am continuing to commit to Data Domain or if I'm to look elsewhere like Exagrid.

[Gostev]

I can confirm significant performance improvement with Data Domain and v9 (in a few times).

That said, it is important to understand that no inline dedupe device will ever be able to provide you with the performance and latency of raw storage behind ExaGrid's landing zone, even when integration is polished to perfection.

However, ExaGrid has its own drawbacks, such as lack of in-storage synthetic full backup processing (via metadata updates, without having to re-hydrate and physically move data blocks within the storage).

[nikpolini]

in-storage synthetic full backup

Can you elaborate some more? Would this be available on other Devices such as Dell DR series? Any thing on the roadmap of integration using Dells OST stuff?

[kjstech]

I just wish Veeam made a backup appliance that worked perfect. Seems there are many solutions out there but each one has its on caveat.

[Gostev]

Can you elaborate some more?

Simply put, it provides for 10 times faster synthetic full backup creation and transformation performance, because actual data blocks already sitting in the storage device do not need to be touched in the process.This is available with our EMC Data Domain and HP StoreOnce Catalyst (as of v9) integrations only.

Unfortunately, we do not publish our roadmap.

Our partners can surely provide you with pre-built Veeam backup appliance that works perfect, for example one based on CISCO C3160 general purpose server is extremely popular lately (and for a good reason).

[kjstech]

Are your partners listed on your website? What OS would you put on a CISCO 3160? Just like a Windows OS or something else like a NAS type OS like FreeNAS or its enterprise version?

I just want this to be an easier process. With EMC it is, they look at our environment, logs, current equipment / assets, and they say this is what you need, and here is the licences and a second one to replicate over the WAN. Its very turn-key. Everything sounds so good, almost too good, too easy, then I find posts on here about very poor restore times.

Then you look at something like Exagrid and it sounds like its the solution. However WAN replication is not clear to me, nor are the terms you specify in the post. Specifically you write "However, ExaGrid has its own drawbacks, such as lack of in-storage synthetic full backup processing (via metadata updates, without having to re-hydrate and physically move data blocks within the storage)."

I have no idea what that statement even means. Not even sure what a re-hydrate is. I just want to rack mount a device here and in another location, give them some IP addresses, carve out some storage and point my backups to it. I want it to be a day job not a months worth of work.

[kjstech]

Guys since my post veers a little off from V9 release date, I created a new topic on the storage questions I have here: http://forums.veeam.com/veeam-backup-re ... 31199.html

[scott.anderson]

It is scheduled to be available later this year, and yep, VeeamON was awesome!

Financial (who's, as a lot of countries don't have the same financial year as the US!) or calendar year?

Personally I wish ICT vendors would just stick to the calendar year. if its the end of the year everyone knows its December that way!!!

[dellock6]

We stick to calendar year at Veeam

[scott.anderson]

Cool so within the next 6 weeks we will get v9 then

[jmarsack]

Specifically you write "However, ExaGrid has its own drawbacks, such as lack of in-storage synthetic full backup processing (via metadata updates, without having to re-hydrate and physically move data blocks within the storage)."

I have no idea what that statement even means. Not even sure what a re-hydrate is. I just want to rack mount a device here and in another location, give them some IP addresses, carve out some storage and point my backups to it. I want it to be a day job not a months worth of work.

In case others wonder the answer to this question, "in-store synthetic full" in brief, means that rather than reading the entirety of all of the incremental backup data on the destination store, and re-hydrate the data (re-inflate the compressed and deduplicated blocks) and then writing it all back as a single full backup. The "in-store synthetic full" means that the native storage solution looks at the data internally and processes the blocks as it rests without disturbing the data (i.e not having to re-hydrate and send it over the wire back to the backup proxy and then send it all back again). Its like taking your money to the bank and then asking the teller (who now holds your money) for the full balance of your account rather than requesting all of the money back from the teller and then counting it by hand yourself and then handing it back again. This shifts the work of making synthetic fulls over to the destination storage array, rather than having it all managed by the near-side backup. It is FAR more efficient this way!

[ekisner]

Here's to hoping we get a late Christmas present from Veeam!

I have to imagine it's close to release, I'm sure I speak for many of us when I say we await it with baited breath.

[DaveWatkins]

I'm hopeful too, since I'm holding off deploying at all since I'm going to have to do active full backups to get the per vm backup chains anyway

[namiko78]

How will you enable per vm backup chains on your backup copy job repository?

[ekisner]

While per-vm backup chains is a definite improvement from the old functionality, I might suggest that individual jobs for each VM remains more functional regardless due to the fact that I can easily control whether a job runs at all (or change the settings for a specific job). For example if I'm going to do a large data migration, I can disable the job so that I don't get a multi-terabyte snapshot from the data migration during the backup window. Then just either run the job after it finishes, or wait for the next window.

And if you do it that way you can deploy now and get your backups rolling sooner

Edit:
Disable the job for the affected VM(s) and let the other VMs run as intended

[Gostev]

I have to imagine it's close to release, I'm sure I speak for many of us when I say we await it with baited breath.

v9 was released a few weeks ago and all of our partners already have it... general availability is scheduled for later this month.

[ekisner]

Woo! Happy day! Thanks Gostev.

[DaveWatkins]

While per-vm backup chains is a definite improvement from the old functionality, I might suggest that individual jobs for each VM remains more functional regardless due to the fact that I can easily control whether a job runs at all (or change the settings for a specific job). For example if I'm going to do a large data migration, I can disable the job so that I don't get a multi-terabyte snapshot from the data migration during the backup window. Then just either run the job after it finishes, or wait for the next window.

We're planning to use VMWare tags to put VM's in jobs so we'll still have multiple VM's per job. Removing the tag from the VM and adding it again after migration should give us the same level of control and hopefully all from the VMWare side of things without having to touch the Veeam server at all.

[Grod]

v9 was released a few weeks ago and all of our partners already have it... general availability is scheduled for later this month.

No they don't. We're a gold partner and none of my colleagues have been sent the email you mentioned in another thread with the download link. I can't find it anywhere on the partner portal either.

[foggy]

Hi, Graeme. Please check your spam folders and contact your Veeam sales representative to check the e-mail address that is registered with Veeam.

[foggy]

How will you enable per vm backup chains on your backup copy job repository?

After enabling the per-VM setting on repository, backup files will continue to be created for the entire set of VMs, until you perform an active full. For backup copy job, you will be able to do this with the help of the new active full functionality.

[foggy]

While per-vm backup chains is a definite improvement from the old functionality, I might suggest that individual jobs for each VM remains more functional regardless due to the fact that I can easily control whether a job runs at all (or change the settings for a specific job).

You wouldn't want to go this way in an environment with hundreds of VMs...

[muk]

v9 was released a few weeks ago and all of our partners already have it... general availability is scheduled for later this month.

Dear Veeam,

Jokes aside, I have heard this same story in November where apparently it was going to be available as RTM Nov/Dec and released to the public in late December.
I unfortunately do not work at Veeam but I suspect you do. I believe I speak for everyone here when I say we need a concrete release date for this version!

[nielsengelen]

No they don't. We're a gold partner and none of my colleagues have been sent the email you mentioned in another thread with the download link. I can't find it anywhere on the partner portal either.

I noticed you have opted out of our e-mails. This is the reason why you didn't get an e-mail. Please contact your local Veeam contacts.

[foggy]

Jokes aside, I have heard this same story in November where apparently it was going to be available as RTM Nov/Dec and released to the public in late December.
I unfortunately do not work at Veeam but I suspect you do. I believe I speak for everyone here when I say we need a concrete release date for this version!

RTM was released in December and will soon be available publicly, please be patient.

[dellock6]

You wouldn't want to go this way in an environment with hundreds of VMs...

Agree.
In a large environment, I think a good solution (listed by also other customers) can be the combined use of vsphere tags + scale-out backup repository + per-vm chains. In this way you do not need actually any specific job other then splitting VMs in groups (so same tag protected by one job) for different RPO or application processing.

Tagging is also a great way to migrate to per-vm chains imho, as in a large environment if you just enable per-vm and run an active full, on day1 every vm of a job will have an active full, and depending on the size this can be an issue.

With tags you can plan for a smoother migration: just create one single tag like "per-vm backup", and enable per-vm chains on repositories. So far, nothing changes.
Then, you create or clone a backup job, with the exact same configuration of the previous one. The difference is that you use the tag as the dynamic container for including VMs in the new job, and at the same time as an exclusion of VMs in the existing job.
Then, few VM per day are going to be tagged.
What happens each day is that the VM is not backed up anymore by the old job, and a full backup is created by the new job.
Because the VM has the same morefID, the retention is preserved and you see all the restore points belonging to this VM, old restore points in the previous job and the new ones in the new job.

In this way, you spread the load of the active full over multiple days, and you can move many VMs to the new configuration little by little. Once the new retention point is reached, you simply delete the old backups.