Questions on direct backup to Object storage

[ithark]

Hi Guys,

We are using Veeam 12 to backup (forever forward incremental) directly to the Object storage (AWS S3) with a retention of 31 days with immutability (30 days) enabled. I am struggling to understand certain concepts here.
1) We are choosing forever forward incremental so that it saves the cost both on the storage and also on the API calls since a weekly full will increases the cost multifold. Is this correct?
2) How does forever forward incremental actually work on the object storage? How does the oldest incremental merge with the first full backup given that everything is in blocks?
3) For the immutability, we are thinking about changing the policy so that we set the immutability to 5 days and change the registry value of ImmutabilityGenerationDays to 31 days so that we have a total immutability of 36 days but the extended API calls are happening only once every month. Is this an acceptable approach? What's the downside of this approach?
4) To further reduce the API calls, we are thinking about increasing the block size from the default 1 MB to 4 MB. I know this would increase the incremental size but in number, does this increase the size 4 folds?

I am sorry that I am asking a lot of questions but I just want to understand certain concepts better before we can actually implement them in our environment.

[Mildur]

Hello Karthik

1) We are choosing forever forward incremental so that it saves the cost both on the storage and also on the API calls since a weekly full will increases the cost multifold. Is this correct?

There will be some API calls to extend immutability for objects used in a weekly GFS restore point. But it won't take more space. Direct To Object storage is always forever incremental as long as you don't schedule active full backups.

2) How does forever forward incremental actually work on the object storage? How does the oldest incremental merge with the first full backup given that everything is in blocks?

There is no merge. There are no backup files.
Blocks of a restore point are split in unique objects. Those objects are then offloaded to object storage. Each Restore Point references to the required objects in object storage to be able to fully restored.
When you start a restore, Veeam will read objects required to restore a single file or entire machine from the chosen restore point.

3) For the immutability, we are thinking about changing the policy so that we set the immutability to 5 days and change the registry value of ImmutabilityGenerationDays to 31 days so that we have a total immutability of 36 days but the extended API calls are happening only once every month. Is this an acceptable approach? What's the downside of this approach?

Changing defaults should only be done if necessary. The possible values for that key are 0 to 30.
But it should work without any downsides.

4) To further reduce the API calls, we are thinking about increasing the block size from the default 1 MB to 4 MB. I know this would increase the incremental size but in number, does this increase the size 4 folds?

We see 2x larger incremental backups with higher block size. Please remember, changing the block size on existing jobs will require active full backups. And Active Full backups won't repurpose already offloaded objects. It will be a full offload.

If you want to truly safe money with public object storage providers, then I suggest you start looking at providers like Wasabi which only bill you storage usage and no API or egress traffic.

Best,
Fabian

[ithark]

Hi Fabian,
Thanks for the detailed explanation.
I still don't get point 2 of how the forever incremental works. Is there a reference to a KB or to an admin guide where this is mentioned with some examples?
Regards,
Karthik

[Mildur]

Hi Karthik

Let me check if we have a KB or explanation in the user guide.
Maybe this example already is ok for you:

1. Initial backup uploads the restore point as objects 1 + 2 + 3 + 4 + 5
--> First Restore Point references to object 1 + 2 + 3 + 4 + 5

2. New Data in your protected VM is added
An incremental backup session runs. New data is uploaded as object 6
--> Second Restore Point (incremental) references to object 1 + 2 + 3 + 4 + 5 + 6

3. Existing Data is changed in the VM.
An incremental backup session runs. The changed data is uploaded as object 7 and replaces previously protected data in object 2.
--> incremental Restore Point (Incremental) references to object 1 + 3 + 4 + 5 + 6 + 7

4. Existing Data is changed in the VM.
An incremental backup session runs. The changed data is uploaded as object 8 + 9 and replaces previously protected data in object 3 + 5.
--> incremental Restore Point (Incremental) references to object 1 + 4 + 6 + 7 + 8 + 9

5. Retention removes old data after some time. First 2 restore points are deleted from the configuration database and metadata.
--> We will delete object 2, because it's not used in any newer restore point. 1 + 3 + 4 + 5 + 6 + 7 + 8 + 9 will be kept, because they are required by the newest two restore points.

You just have to ignore for object storage the concept of backup files. There are no backup files on object storage.
We don't have to build a new VBK file. And we don't upload any VIB files.

Each restore point is build together from several of this objects. Veeam's configuration database and metadata will keep record of which objects belong to what restore point. One object can belong to multiple restore points if the protected data from the source VM didn't changed between two backup sessions.

You will find those objects with backup data in the CloudStg folder on your object storage bucket:
https://helpcenter.veeam.com/docs/backu ... ml?ver=120

Best,
Fabian

[ithark]

Thank you Fabian.
That explains the concept.
Appreciate your help.