It’s an umbrella term that doesn’t quite explain everything going on here.
Firstly from a backup process:
When we backup data, let’s say from a VM. The proxy will fetch a block, based on the block size (256KB/512KB/1MB/4MB/8MB) configured within the job. Once we have this block, we compress and dedupe, then save this as a blob within S3/object storage of your choice (I’ll just call it S3 from now on). Let’s focus on this single blob we’ve saved.
With block storage, we either referenced that block until we did an active full again, or a synthetic full. With a synthetic full, if we used block cloning we carried on referencing that block, but otherwise we took a copy of it.
Within object storage we don’t have active/synthetic fulls (unless you specifically want active fulls on an archive tier of a SOBR). This means that until that block changes, every backup subsequently will reference this blob.
From an immutability perspective, we check if that blob is still the latest “version” of data (was it needed by the latest backup, or did the block change) if the block hasn’t changed, we periodically update the immutability retention of that block, because our latest backups require it, and we require immutability for X number of days. If the block has been updated, we don’t update the immutability duration, we let that immutability duration expire when specified, and then we can perform lifecycle management on the blob (delete when no backups require it anymore)
and here is the Link! https://www.veeam.com/blog/veeam-backup-replication-s3-immutability-block-generation.html
