Archive Tier save backups as standalone fulls

[popjls]

Just regarding this functionality....

If your backups that sit in the Archive Tier comprise of "fulls" only (Full Yearlys or Full Monthlys hypothetically)... does this tickbox still need to be ticked? or is this redundant?

[Mildur]

If you tick this option, every Full in the archive tier are stored with their own objects. The objects won‘t be shared with other fulls, if they have the same data.
It‘s like disabling Deduplication.

Without the option, veeam will only offload unique objects/blocks to the archive tier snd will reuse already offloaded unchanged data from the earlier fulls.
With the option, each full will be offloaded completely in their entire size.

Ticking the option gives you a more reliable option to Archive your fulls. But more Storage is needed of course. If one object in the object storage is deleted, only one Full Backup will be affected, not all of them.

[popjls]

Ok so what if you already have fulls in the archive tier and tick the box after they have already been uploaded? Does Veeam suddenly know that it needs to be a standalone full and will mark it as such or will it try to upload the entire "full" archive again?

I don't see how a full can be shared with another full though? Doesn't that defeat the purpose?

[Mildur]

Ok so what if you already have fulls in the archive tier and tick the box after they have already been uploaded?

The new fulls will be standalone fulls, older fulls will not be reprocessed.

I don't see how a full can be shared with another full though? Doesn't that defeat the purpose?

In an object storage, there are no files. There are objects.
On the Onpremise Backup Server, Veeam takes the vbk file and breaks it down into many small blocks.
This blocks will be of offloaded as objects to the object storage (capacity tier). You don‘t have a vbk in the object storage.

Now, between two fulls, it is possible that a folder with data on your vm wasn‘t changed. That can be the windows folder or some file data like movie files or photos. This part of the backup won‘t change between two fullbackups. They stay the same.

Veeam will not offload again this unchanged blocks in the vbk to the capacity tier. Why should veeam do that. The blocks are already there in the object storage from this part of the backup data.
It‘s like FastClone with Synthentic Fulls on a xfs or refs backup repo.

Now for the archive tier, With this option, you can control this behaviour for the archive tier. Should veeam offload the entire object again for this data or should it be reused from the previous fullbackup like in the capacity tier.

The option is there to decide for you, if you want to have more reliable backups for archival purposes, Backups that don‘t need to rely on older objects in the object storage. If you need to retain 10 yearly GFS, you properly don't want to be dependent on old objects for every year. The wrong object goes missing, you loose all 10 yearly Restore Points.

[popjls]

The new fulls will be standalone fulls, older fulls will not be reprocessed.

Hmm not ideal..... So what if the only full you have in there is a Yearly? That can't be dependant on anything can it if it's the first and only one in the Archive correct? So does this affect the capacity tier further up the chain too? Ie is it only copying the changed blocks from capacity to archive? I'm guessing yes to that.

Thanks for the clarification on the whole object vs vbk flat file makes sense but..

The option is there to decide for you, if you want to have more reliable backups for archival purposes

Kind of feel it needs to be the default option not an opt in.. at least not tucked away in the very last stages of the setup, which someone may clearly miss I see the cost benefit with the way veeam does it but like you said, a single loss will equate to a lot of backups going bye bye.

[Mildur]

Hmm not ideal..... So what if the only full you have in there is a Yearly? That can't be dependant on anything can it if it's the first and only one in the Archive correct?

That’s correct. If it‘s the only full in the archive, then there is nothing else there to have a Dependance
With the option on, the next gfs restore point will depend on the already offloaded blocks.

So does this affect the capacity tier further up the chain too? Ie is it only copying the changed blocks from capacity to archive? I'm guessing yes to that.

The option is only for gfs restore points in the archive tier.
Capacity tier will always be „only unique blocks“ and not standalone full backups.

[Gostev]

Kind of feel it needs to be the default option not an opt in.. at least not tucked away in the very last stages of the setup, which someone may clearly miss I see the cost benefit with the way veeam does it but like you said, a single loss will equate to a lot of backups going bye bye.

Truth be told, this option is there mostly to meet compliance checkbox requirements created 30 years ago. AWS S3 is extremely reliable storage and "single loss" can simply never happen because AWS stores each object multiple times. The only realistic data loss scenario is accidental deletion by user or due to a bug in Veeam, but for that there's immutability.

[Mildur]

Thanks anton for the insight. Never thought of this in that way

[popjls]

With the option on, the next gfs restore point will depend on the already offloaded blocks.

Just to be clear you mean with the tick box unchecked correct? I've ticked it now so it will be a standalone.

That's cleared it up in any case thank you both. I'm not worried about S3 losing data, i'm more concerned with my side having an issue with the chain or the config or something and not being able to go back all those years.

[Mildur]

Just to be clear you mean with the tick box unchecked correct?

Yes sorry. You are right.

Option unchecked —> „the next gfs restore point will depend on the already offloaded blocks.“

[Gostev]

i'm more concerned with my side having an issue with the chain or the config or something and not being able to go back all those years.

There's no chain either way, as every archived backup is a full backup regardless of this option. The only difference is whether you upload and store all of its blocks, or you don't upload again (and storage again) the blocks which are already present in the bucket.

[popjls]

There's no chain either way, as every archived backup is a full backup regardless of this option.

So for safety or best practice - which is the preferred option? If there is no chain or worry about data loss why offer the option (apart from the cost?) ? Just curious.

[Gostev]

I have already answered this question in my previous response.

[popjls]

Yes but for best practice? Unchecked or checked?

[Gostev]

As a best practice, you should always stick with the default setting. These values represent our recommendations.