I understand why Veeam would need to manage the tiering to "Archive" due to the data being dehydrated, but why can't I use Lifecycle Management to tier old backups from "hot" to "cool"? Both "hot" and "cool" are equally accessible and the data does not need to be "rehydrated" before it can be retrieved from "cool."
Is this just because Veeam doesn't want to be responsible for people configuring rules incorrectly, or will automatically tiering old data from "hot" to "cool" actually break something?
From what I understand, a Lifecycle Management rule will not change the location of a blob, it will just tag the blob as "hot" or "cool" so unless I'm missing something, Veeam should never even notice.
This is what I'm referring to: https://helpcenter.veeam.com/docs/backu ... le&ver=110
-
- Novice
- Posts: 3
- Liked: never
- Joined: Dec 22, 2018 12:48 am
- Full Name: Demetrius Weaver
- Contact:
-
- Product Manager
- Posts: 14843
- Liked: 3086 times
- Joined: Sep 01, 2014 11:46 am
- Full Name: Hannes Kasparick
- Location: Austria
- Contact:
Re: Why is using Lifecycle Management rules in Azure not supported for Veeam repositories?
Hello,
the main idea is to ensure, that objects can be accessed at similar speed and availability. Otherwise the software would need features, that somehow can deal with "delayed" data, which adds complexity.
I have not heard, that customers would want to move between hot and cool, because of the small price difference. Also, the minimum charge for 30 days plus the API costs should make it economical useless to do lifecycle management between hot and cool. Yes, we also don't want to be responsible for broken lifecycle rules. It just makes it complicated with no obvious benefit.
What backup retention do you have configured? Asking the other way around: did you test lifecycle policies between hot and cool and did they save you costs?
Overall I like to say: instead of trying to deal with Azure pricing, I would look at a cheaper alternative. Wasabi & Backblaze are popular in the community, but also other object storage providers are an option.
Best regards,
Hannes
the main idea is to ensure, that objects can be accessed at similar speed and availability. Otherwise the software would need features, that somehow can deal with "delayed" data, which adds complexity.
I have not heard, that customers would want to move between hot and cool, because of the small price difference. Also, the minimum charge for 30 days plus the API costs should make it economical useless to do lifecycle management between hot and cool. Yes, we also don't want to be responsible for broken lifecycle rules. It just makes it complicated with no obvious benefit.
What backup retention do you have configured? Asking the other way around: did you test lifecycle policies between hot and cool and did they save you costs?
Overall I like to say: instead of trying to deal with Azure pricing, I would look at a cheaper alternative. Wasabi & Backblaze are popular in the community, but also other object storage providers are an option.
Best regards,
Hannes
Who is online
Users browsing this forum: No registered users and 9 guests