Discussions related to using object storage as a backup target.
Post Reply
apolloxm
Enthusiast
Posts: 90
Liked: 1 time
Joined: Aug 27, 2021 12:29 am
Contact:

Veeam Capacity Immutable Days

Post by apolloxm »

Support ID:04947378. The ticket opened from Aug 4, until now, We didn't get a reasonable reply from your support team.Here is latest reply from support team. I also told to your support management team and got reply from your management team as following
"We are unable to provide time frames on when R&D will give us an answer, but we will make sure to update you with progress as soon as it comes along. Currently, the status of the situation is that we have lodged a request for R&D to review and they are reviewing it. There is currently no update or ETA, but we will make sure to keep you updated as soon as that changes."
I am feeling so bad about veeam support efficiency, 23 days can't get answer just for an issue that can be easily reproduced.

We set the immutability to 2 days with a full backup once a week, per your user guide, the immutability days should be 12 days, however, the testing result from your support team and my side is 17 days, that's not meet your user guide. Your level 2 engineer also told us that "Default immutable period: (minimum 7 days, maximum — 9999) as per link:https://helpcenter.veeam.com/docs/backu ... tml?ver=11 " Since linux immutable and capacity immutable are two kinds of products, this made us so confuse.


Below just latest response from your support team
"I have just received an update from the RnD team and they have shared the following information for the immunity period calculation;
Maximum length of a single chain (VBK + all dependent increments) + Immutability period + 10 days.
In your case, with immutability set to 2 and a full backup once a week, the full immutability period for the first full backup ends up being around 17 days, since by that time the immutability period for the latest incremental backup that depends on the first full backup will reach the expected 12 days.
The RnD team is still investigating and I am waiting for a confirmation on the next best course of action. I will request you to allow us more time for the action plan and will update you as soon as I have the next information"

Can someone help to speed up this process?We have no ETA for this issue, We don't know how to set the immutable days for our project. Thanks!
HannesK
Product Manager
Posts: 14287
Liked: 2877 times
Joined: Sep 01, 2014 11:46 am
Full Name: Hannes Kasparick
Location: Austria
Contact:

Re: Veeam Capacity Immutable Days

Post by HannesK »

Hello,
and welcome to the forums.

Hardened Repository is something else. It has nothing to do with capacity tier and S3 object-lock immutability.

First: can you please tell us what you try to achieve? Is a longer immutability preventing you from doing anything right now? Please keep in mind, that the value you set is the minimum or guaranteed immutable time you get. Assuming 12 or (17 days) immutability is wrong. On the second day it would be 11 days, then 10 days... until it's 2 days. And then everything that is still needed gets an immutable update again.

Second: 17 days is wrong. But I can confirm what you see... I checked it and it's tracked as bug #329762 that should be fixed in 11a (next update)

Best regards,
Hannes
apolloxm
Enthusiast
Posts: 90
Liked: 1 time
Joined: Aug 27, 2021 12:29 am
Contact:

Re: Veeam Capacity Immutable Days

Post by apolloxm »

Hello Hannesk,

Thanks for your reply! Our goal is only keep 1 or 2 VBK files in the Capacity with S3 object-lock immutability. Currently, our company have totally 33 TB data(for ONE VBK file) and we have 28 restore points as retention policy for performance tier. For the Capacity Tier, we want to have difference retention policy. for example set to 2 restore point with full VBK file. the reason why we want to keep 2 restore point with VBK file is
1.we are concerning about the size in the Capacity Tier that will cause the high cost.
2.Base on our testing, with copy mode, Veeam will offload the data to cloud directly after the backup job finished. with move mode, Veeam will start to offload the data to cloud 4 hours later. We just worry about the timeline of the Backup and Offload as our weekly full backup need to take 2 to 3days. with capacity tier, We thought Veeam can't be finished in time. so, this doesn't meet our requirement.

There is another solution that using the Backup Copy jobs. We can set the Backup copy jobs retention policy to keep 2 restore point. We trigger the Veeam Backup Copy Full Jobs every one week with powershell as the Veeam backup Copy doesn't support to trigger full file in the Veeam UI interface. if the data in the immutable status, then Veeam cannot delete the data. that is why we need to know how Veeam immutability period works, then we can easily to know how many data will be keep in the cloud.then we can know what is the cost if we offload the data backup to cloud. Thanks!
HannesK
Product Manager
Posts: 14287
Liked: 2877 times
Joined: Sep 01, 2014 11:46 am
Full Name: Hannes Kasparick
Location: Austria
Contact:

Re: Veeam Capacity Immutable Days

Post by HannesK »

Hello,
or 2 VBK
There is only one full in capacity tier (well, it's tons of small objects. Not that kind of VBK / VIB that is available on-prem). Veeam capacity tier is incremental forever. Full backups are space-efficient logical full backups. Please see the sticky FAQ
33 TB data(for ONE VBK file)
off-topic: I always recommend per-machine files for easier handling.
For the Capacity Tier, we want to have difference retention policy.
Copy means copy. Retentions are equal. Please avoid trying to "fix" that by setting immutability. For different retentions, let's see what V12 backup copy job brings (as of today, BCJ goes to a Veeam repository. For V12, we plan direct to object-storage)

Move only moves old data (inactive backup chain). Not sure how that could help. Copy sounds correct for me.

I cannot really comment on the last paragraph because backup copy jobs cannot work with S3. That means they are no option today if you want to go to object storage. Of course, you could use a Linux machine as Hardened Repository. But that's something else.

Best regards,
Hannes
Andreas Neufert
VP, Product Management
Posts: 6707
Liked: 1401 times
Joined: May 04, 2011 8:36 am
Full Name: Andreas Neufert
Location: Germany
Contact:

Re: Veeam Capacity Immutable Days

Post by Andreas Neufert »

Thanks for sharing this.
Capacity Tier with Object Storage do not work with specific backup formats like VBK files. It will upload the data blocks to the object storage as objects and after that for any new restore point we calculate what block was not uploaded but is needed for the restore point to be completed. So it is a incremental forever upload, no matter what image level backup you have in the Performance Tier.

As we have to drag the old blocks stored in objects along over time, we protect some of the blocks automatically up to 10 days longer to avoid IO costs on public storages. This process should not be considered in case of how long data is protected that you need. If you need 12 days immutability, then set the immutability setting as well to 12 and not lower.

Anyway if you want to offload only very specific restore points, you can maybe as you outlined create backup only with a specific frequency to the Scale Out backup Repository that offload the data to object storage. Avoid active full processing as it can force as well the offload of the full backup to the object storage.

But I would consider another approach. As the offload is incremental forever and we store data like this, I would consider the cost for this and if possible go with it.

In theory you have a change rate of below 5%... So the Data Amount is 1 Full + 6 Incrementals for a 7 day immutable retention. 1 Full + 7x 5% = 1.35x of the used data minus compression => In the end I guess less than 0,6x of your original used data.

You can use our VSE tool to calculate it upfrong.
https://vse.veeambp.com/
apolloxm
Enthusiast
Posts: 90
Liked: 1 time
Joined: Aug 27, 2021 12:29 am
Contact:

Re: Veeam Capacity Immutable Days

Post by apolloxm »

Hello Andreas Neufert,
Thanks for your reply! Can you explain more about "Avoid active full processing as it can force as well the offload of the full backup to the object storage." As I understanding, Offload is incremental forever , after we configured the SOBR with capacity, Veeam will start the process to offload to cloud. after that, If we run an active full for the backup jobs with copy mode, Veeam will only offload the incremental data to cloud instead of the active full. Am I right?
apolloxm
Enthusiast
Posts: 90
Liked: 1 time
Joined: Aug 27, 2021 12:29 am
Contact:

Re: Veeam Capacity Immutable Days

Post by apolloxm »

Andreas Neufert wrote: Aug 27, 2021 8:26 am Avoid active full processing as it can force as well the offload of the full backup to the object storage.
Hello Andreas Neufert, Can you explain more about this?Thanks!
Andreas Neufert
VP, Product Management
Posts: 6707
Liked: 1401 times
Joined: May 04, 2011 8:36 am
Full Name: Andreas Neufert
Location: Germany
Contact:

Re: Veeam Capacity Immutable Days

Post by Andreas Neufert » 1 person likes this post

This was not a correct statement. Even if you process active fulls, the upload is Incremental Forever.
apolloxm
Enthusiast
Posts: 90
Liked: 1 time
Joined: Aug 27, 2021 12:29 am
Contact:

Re: Veeam Capacity Immutable Days

Post by apolloxm »

HannesK wrote: Aug 27, 2021 8:13 am
I cannot really comment on the last paragraph because backup copy jobs cannot work with S3. That means they are no option today if you want to go to object storage. Of course, you could use a Linux machine as Hardened Repository. But that's something else.
Hello, Thanks for your reply!Base on our testing, Veeam Backup Copy jobs workwith backblaze s3 compatible storage and We run the powershell as following, everything looks fine, Is there any unknow issue for the Backup Copy jobs with S3 or do you have any official article mention about this?Thanks

Powershell Script

$jobs = Get-VBRJob | ?{$_.JobType -eq "backupsync"}
foreach($job in $jobs){
$jobsname=$job.name
Sync-VBRBAckupCopyJob -Job $job -FullBackup
apolloxm
Enthusiast
Posts: 90
Liked: 1 time
Joined: Aug 27, 2021 12:29 am
Contact:

Re: Veeam Capacity Immutable Days

Post by apolloxm »

Andreas Neufert wrote: Sep 02, 2021 9:02 am This was not a correct statement. Even if you process active fulls, the upload is Incremental Forever.
Thanks for your reply! That's make sense for us. Thanks again for your help
apolloxm
Enthusiast
Posts: 90
Liked: 1 time
Joined: Aug 27, 2021 12:29 am
Contact:

Re: Veeam Capacity Immutable Days

Post by apolloxm »

HannesK wrote: Aug 27, 2021 6:00 am Second: 17 days is wrong. But I can confirm what you see... I checked it and it's tracked as bug #329762 that should be fixed in 11a (next update)
Hello, If 12days or 17 days wrong, We have 28 restore points, We just want to make the capacity immutable for 14 days or 28 days, how many days should I set to? 4 days or 18 days?
Andreas Neufert
VP, Product Management
Posts: 6707
Liked: 1401 times
Joined: May 04, 2011 8:36 am
Full Name: Andreas Neufert
Location: Germany
Contact:

Re: Veeam Capacity Immutable Days

Post by Andreas Neufert »

If you want to have 14days immutability, set it to 14 days.
If you want 28 days immutability set it to 28 days.
There is a background process that set the immutability of some of the object to additionally up to 10 days plus, but these are not relevant for restore points and are just a helper to save costs in public cloud as all IOs (Immutability flag updates of objects are IOs) are extra IO that need to be payed there. But this do NOT mean that you get 10 additional days Immutability.
apolloxm
Enthusiast
Posts: 90
Liked: 1 time
Joined: Aug 27, 2021 12:29 am
Contact:

Re: Veeam Capacity Immutable Days

Post by apolloxm »

Per your user guide said "When you configure immutability for capacity tier, keep in mind that an additional period of up to 10 (by default) days will be automatically added to the immutability expiration date. This period is called Block Generation. For example, if you set your immutability period to 30 days, 10 days will be added, and total immutability period will be up to 40 days. "
https://helpcenter.veeam.com/docs/backu ... ml?ver=110

That's make user confusion.
Andreas Neufert
VP, Product Management
Posts: 6707
Liked: 1401 times
Joined: May 04, 2011 8:36 am
Full Name: Andreas Neufert
Location: Germany
Contact:

Re: Veeam Capacity Immutable Days

Post by Andreas Neufert »

I know this is very confusing I agree. It is up to 10 days but can be as well one or zero. So it should not be counted for your Immutability.
Will ask the team to update this and make it more clear.
apolloxm
Enthusiast
Posts: 90
Liked: 1 time
Joined: Aug 27, 2021 12:29 am
Contact:

Re: Veeam Capacity Immutable Days

Post by apolloxm »

Thanks! How about this? Base on our testing,Veeam Backup Copy jobs workwith backblaze s3 compatible storage and We run the powershell as following, everything looks fine, Is there any unknow issue for the Backup Copy jobs with S3 or do you have any official article mention about this?Thanks

Powershell Script

$jobs = Get-VBRJob | ?{$_.JobType -eq "backupsync"}
foreach($job in $jobs){
$jobsname=$job.name
Sync-VBRBAckupCopyJob -Job $job -FullBackup
HannesK
Product Manager
Posts: 14287
Liked: 2877 times
Joined: Sep 01, 2014 11:46 am
Full Name: Hannes Kasparick
Location: Austria
Contact:

Re: Veeam Capacity Immutable Days

Post by HannesK »

Veeam Backup Copy jobs workwith backblaze s3 compatible storage
I'm not sure what setup this should be. Backup copy jobs can only point to (scale-out) repositories. There is no way to point them directly to object storage (S3).

As Andreas said: configure the amount of days you require. All the rest is just cost optimization by the software (well, and right now applying a minimum time which will be changed back in 11a as I mentioned in my first answer).
apolloxm
Enthusiast
Posts: 90
Liked: 1 time
Joined: Aug 27, 2021 12:29 am
Contact:

Re: Veeam Capacity Immutable Days

Post by apolloxm »

Yes,let me clarify our environment. Our Backup copy jobs just point to scale-out repositories. Our local SMB share NAS Server work as performance tier, Back Blaze just work as Capacity Tier. We set the normal retention policy to 2 restore points and disabled the GFS configuration.To avoid the increment file be created, We set the periodic copy to 100 days. We just run the task schedule every 7 days.So every week, Backup copy full jobs will be triggered automatically by powershell. We enabled the copy and move mode together, So, after the local backup copy job finished, Veeam will start offload the currently week data to Backblaze.

In the local side, We just have 1 full backup copy files, in the cloud side, We will have 1 full backup copy files. Am I right?


Powershell Script

$jobs = Get-VBRJob | ?{$_.JobType -eq "backupsync"}
foreach($job in $jobs){
$jobsname=$job.name
Sync-VBRBAckupCopyJob -Job $job -FullBackup
HannesK
Product Manager
Posts: 14287
Liked: 2877 times
Joined: Sep 01, 2014 11:46 am
Full Name: Hannes Kasparick
Location: Austria
Contact:

Re: Veeam Capacity Immutable Days

Post by HannesK »

@apolloxm is it possible, that the question has nothing to do with immutability? If yes, then I would split the topic as I'm confused now.

If you want to avoid increments to be created, then you need "active full". I don't see that in your script, so I expect it doesn't do what you like (but I did not try it out).

Because of "copy", you will have two restore points in the cloud (tons of objects instead of two files). From a space usage perspective in the cloud it will be one full and one increment.
apolloxm
Enthusiast
Posts: 90
Liked: 1 time
Joined: Aug 27, 2021 12:29 am
Contact:

Re: Veeam Capacity Immutable Days

Post by apolloxm »

@Hannesk, Sync-VBRBAckupCopyJob -Job $job -FullBackup this is the script to create an active full.
Post Reply

Who is online

Users browsing this forum: jigar.thakker and 8 guests