-
- Veeam Legend
- Posts: 251
- Liked: 136 times
- Joined: Mar 28, 2019 2:01 pm
- Full Name: SP
- Contact:
Quick VUL question.
Are File to Tape, and File to object considered 2 seperate licenses?
Example, backing up 1.5TB in a file to tape job, and 1.5TB in a job to Wasabi. Is that going to use 6 VULS on the same files?
Seems like that happened and I was a bit surprised. Thought it was calculated based on source data.
If I create multiple jobs of the same source data does it keep using licenses? Lets say I had 2 file to tape jobs, at 2 sites, of the same source data.
Thanks
Example, backing up 1.5TB in a file to tape job, and 1.5TB in a job to Wasabi. Is that going to use 6 VULS on the same files?
Seems like that happened and I was a bit surprised. Thought it was calculated based on source data.
If I create multiple jobs of the same source data does it keep using licenses? Lets say I had 2 file to tape jobs, at 2 sites, of the same source data.
Thanks
-
- Chief Product Officer
- Posts: 31964
- Liked: 7435 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Quick VUL question.
Yes, this is by design. Each primary job will always be licensed irrespective of any other primary jobs. There's no logic to try and match similarity of data sources between different primary jobs (the prospect of doing this was investigated in early as this but deemed too complex and error-prone to implement). And since it's overall a very rare scenario to backup the same data twice with different primary jobs, it was an easy decision not to go there.
In the end I think this ended up the right decision though from the perspective of Veeam's support costs: having a File to Object job running successfully does not automatically guarantee that File to Tape jobs protecting the same data will also be running with no issues, considering they target the whole different storage infrastructure type, thus potentially causing its own support issues. And support costs is a big factor for us because we have 100% in-house, enterprise-grade support team which is thus quite expensive. For example, an average fully loaded cost of a support case is actually comparable to net to Veeam value from selling those 3 VULs in question.
In the end I think this ended up the right decision though from the perspective of Veeam's support costs: having a File to Object job running successfully does not automatically guarantee that File to Tape jobs protecting the same data will also be running with no issues, considering they target the whole different storage infrastructure type, thus potentially causing its own support issues. And support costs is a big factor for us because we have 100% in-house, enterprise-grade support team which is thus quite expensive. For example, an average fully loaded cost of a support case is actually comparable to net to Veeam value from selling those 3 VULs in question.
-
- Veeam Legend
- Posts: 251
- Liked: 136 times
- Joined: Mar 28, 2019 2:01 pm
- Full Name: SP
- Contact:
Re: Quick VUL question.
I understand the decision, but then this is also true for 2 separate file to tape jobs at 2 sites.
3 VUL's? I'm looking at 100's of TB to PB's going forward, which would also get renewed every 5 years. That would cover the cost of a few support guys
I need to have File to tape data backed up in 2 spots incase a tape breaks, or a site goes down, I was thinking Wasabi/Tape might have been a viable option, but it looks like neither that, or 2 libraries will work unfortunately. Too bad as we could totally eliminate TSM and go full Veeam if this worked.
With insane retention requirements and growing data, tape seems to be the best inexpensive way I can do this. Sure, I can create unlimited VM's, copy files to them, run a regular backup, backup copy to tape, then delete the VM. It's a hassle to restore a 30TB VM for a few files though and this way causes too much of a headache. I did do it for a few hundred TB already to free up space on a SAN, but is not sustainable and I eventually have to restore them and get them archived properly. Even if it "never" needs to be accessed again.
File to tape with a secondary target using an additional tape library could be an option if you guys had that feature. I'd be just as comfortable using a job at each location running file to tape of the same files. then deleting the files. Somehow the jobs would have to be aware they are backing up the same folders though, so a secondary location might be easier from a license perspective as it's 1 job.
3 VUL's? I'm looking at 100's of TB to PB's going forward, which would also get renewed every 5 years. That would cover the cost of a few support guys

I need to have File to tape data backed up in 2 spots incase a tape breaks, or a site goes down, I was thinking Wasabi/Tape might have been a viable option, but it looks like neither that, or 2 libraries will work unfortunately. Too bad as we could totally eliminate TSM and go full Veeam if this worked.
With insane retention requirements and growing data, tape seems to be the best inexpensive way I can do this. Sure, I can create unlimited VM's, copy files to them, run a regular backup, backup copy to tape, then delete the VM. It's a hassle to restore a 30TB VM for a few files though and this way causes too much of a headache. I did do it for a few hundred TB already to free up space on a SAN, but is not sustainable and I eventually have to restore them and get them archived properly. Even if it "never" needs to be accessed again.
File to tape with a secondary target using an additional tape library could be an option if you guys had that feature. I'd be just as comfortable using a job at each location running file to tape of the same files. then deleting the files. Somehow the jobs would have to be aware they are backing up the same folders though, so a secondary location might be easier from a license perspective as it's 1 job.
-
- Chief Product Officer
- Posts: 31964
- Liked: 7435 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Quick VUL question.
For 100s of TB there's much better solution than VUL, and that is to use Capacity-based licensing. It's significantly cheaper right out of gate (up to 2x depending on the volume) plus unlike with VUL, our Sales have much more flexibility with discounting this part of the license for special use cases and/or to account for product quirks 

-
- Veeam Legend
- Posts: 251
- Liked: 136 times
- Joined: Mar 28, 2019 2:01 pm
- Full Name: SP
- Contact:
Re: Quick VUL question.
While backing up with 2 primary jobs isn't common, It's the only way with tape. TSM does it's own replication so It gets written to multiple libraries. I like Veeam more, and it's about 95% of the way there, but paying double for VUL's for the same source isn't going to work, especially with the large amount's I'll need to store forever pretty much. (100 years on lots of our data)
Tape copy job, think about it!
Tape copy job, think about it!

-
- Veeam Legend
- Posts: 251
- Liked: 136 times
- Joined: Mar 28, 2019 2:01 pm
- Full Name: SP
- Contact:
Re: Quick VUL question.
I have quotes for Capacity-Based licenses already, but wont that be the same issue? If I have to create a primary tape job at both sites, would that not use up double the licenses?
Perhaps I'll talk to our Veeam Sales guy again.
Perhaps I'll talk to our Veeam Sales guy again.
-
- Chief Product Officer
- Posts: 31964
- Liked: 7435 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
-
- Veeam Legend
- Posts: 251
- Liked: 136 times
- Joined: Mar 28, 2019 2:01 pm
- Full Name: SP
- Contact:
Re: Quick VUL question.
That is close, but I'd like it to work more like a backup copy job.
Like the ability to add a secondary destination on another library. It could write at the same time, or after the primary job is complete.
I can't schedule that, and it wouldn't work like an incremental job just copying the changed data that the primary job writes.
That is a great feature for migrations to a new library though.
Like the ability to add a secondary destination on another library. It could write at the same time, or after the primary job is complete.
I can't schedule that, and it wouldn't work like an incremental job just copying the changed data that the primary job writes.
That is a great feature for migrations to a new library though.
Who is online
Users browsing this forum: No registered users and 2 guests