Wasabi target best practice

[costasppc]

Hello,

We are testing Wasabi as backup destination.
I have a question regarding the job configuration. Is it better to create jobs for local disks along with copy jobs to wasabi or different jobs for local storage and wasabi?

Best regards

K

[Mildur]

Hi Kostas

I recommend 1 backup and 1 copy job. If you use two backup jobs, you will put load on your production environment twice.

There are also other considerations regarding application aware processing and database server. Having two backup jobs do application aware backups for a MSSQL server may break transaction log backups (if you use them).

Best,
Fabian

[costasppc]

Thank you very much for your answer, so I will create the jobs as you suggested.

Best regards

K

[mtv]

I have followed this best practice and make backup copy job to Wasabi.

After retention (30 days) has expired, I've noticed, that in Wasabi console storage utilization is still rising and nothing is deleted. Wrote to their's support and they answered that they don't see any demands from Veeam side for deleting and that is because backup copy is doing only incrementals and i must run at least once monthly full backup to purge data and make changes with the retention periods.

But in backup copy there is no option to schedule full backup - only right click and Active full button.

What can i do because i cannot imagine manually doing this?

[mtv]

Of course doing (as wasabi) suggested additional full (beside existing synthetic once per week) on main job is not (best) options since it will reflect also to NAS and ocupied storage there...

Would GFS on copy job to Wasabi help solve this problem?

[Andreas Neufert]

To optimize IO, the blocks that we store in object are kept up to 10 days longer. So you will see that deletion will start after retention end date + 10 days.

[mtv]

thank you! So no need for full backups (in connection with the deletion from wasabi as they tell me)?

[Andreas Neufert]

No, this is even not possible. We write incremental forever data blocks in separate objects and just link restore points together from these blocks. The delete of blocks/objects that do not belong to any restore point will start when the immutability period is over, which is retention + 10 days.

[mtv]

By those +10 days you don't mean block generation? Because imutable period is set much lower than retention and it (immutability) is already expired including block generation time.

My settings are from 1st day:

- Immutability 20 days
- Retention 30 days

Today we are on 38th day day since first backup copy and no delete calls from Veeam to Wasabi as their helpdesk established

[Mildur]

Hello MTV

For immutable backups on object storage, please use this formula:

- immutability period + retention + block generation = actual object storage retention

For your specific scenario, actual object storage retention for a single object is 60 days:
- 20 days + 30 days + 10 days = 60 days

Best,
Fabian

[mtv]

Thank you!

Huh I didn't expect this because the backup whose retention (30 days in my case) expired had already been deleted from the local VBR. Does this mean that i will still paying for them (60 days to Wasabi) but I can't use them (anything older than 30 days is no longer available in VBR)?

Isn't it better then to set retention to 1 and immutable to 30 and have all immutable for 30 days (now 20 days) and billing for 41 days by provided formula (now 60 days)?

Regards,

M

[Mildur]

Hi MTV,

We are currently working on optimizing storage usage for immutable backups.

In the meantime, you should configure your settings according to your needs.
If you want to be able to restore from the last 30 days, then set a retention policy of 30 days.

You can use our calculator to estimate the required size for Object Storage: Veeam Backup & Replication Calculator..

Best,
Fabian

[mtv]

Thank you Fabian! I'm glad we've cleared that up. Will do as suggested (30 days retention).

PS: is there any ETA for new version with mentioned optimization?

Regards

[Mildur]

Hi mtv

No ETA or information to share about potential enhancements for now.

Best,
Fabian

[mtv]

one more question - what about GFS (like couple of monthly GFS's) if it is outside retention (for retention we established that actual retention in terms of deleting / billing = immutability period + retention + block generation)?

Regards

[Mildur]

Hi mtv

GFS backups in "direct copy to object storage" scenarios are immutable for the entire retention time.
Please use our calculator as shared in my previous comment to get an estimation about the storage usage.

Best,
Fabian

[Drew Schlussel]

Make sure you are only required to support 30-day retention - as a Veeam customer, that is something you can request via an email to support@wasabi.com

[mtv]

I have patiently wait for those 60 days (30 immutability period + 20 retention + 10 block generation) and voila - all old restore points in Veeam were deleted in a batch leaving only 30 days and newer (as retention is set),
BUT NOT in Wasabi even after two days since deleting form VBR console – local backup is 1.8 TB but in wasabi is 2.9 TB and keeps rising.
And yes i have 30-day retention in Wasabi as a Veeam customer – so they told me; which is probably irrelevant in this case because deleted items should be visible also in wasabi dashboard if they have been deleted before wasabi’s set retention, but they are not there.

I found also that Veeam is again accumulating restore points older than 30 days (they are not deleted every day) and will probably keep them up to 60th day and delete them in batch?

But the main case is why Wasabi is not mirror of VBR console in sense of number restore points and backup size?! Is there also some strange delay and I must wait for another period?

[veremin]

Could you please clarify your configuration? Do you have a local backup job along with a backup copy job directed to Wasabi? What are the retention settings for each? Additionally, what are your immutability settings?

From your description, it’s not entirely clear what is being deleted and from where.

Generally, as Fabian noted, the restore points are removed from the UI immediately after their retention period has expired, however, after this removal they will remain in object storage for the duration of the immutability period combined with the generational period.

Thanks!

[mtv]

We have backup of 8 VM locally to NAS and via copy job to Wasabi (and also second copy to rotated drive).
Retention of copy job is 30 days and immutability of Wasabi repo is 20 days. First backup to Wasabi was 3.12.2024, and today, on 12.2.2025 the oldest backup visible in VBR 12.3 console is 9.1.2025 and it is NOT deleting every day (before 9.1.2025 there were all backups from first backup 3.12.2024 onwards and on / around 9.2.2025 we have seen that backups from 3.12.2024 to 9.1.2025 were deleted in one day). Backup size in object storage on VBR is 1,87 TB (before deleting on 9.1. was approx. 2.5 TB).

In Wasabi, storage utilization is exactly 3.0 TB and it is still raising daily.

In the past, when we first noticed difference between VBR object backup size and Wasabi console bucket utilization their help told us – mail below and demand full backup what was performed without success and later declined by Andreas Neufert on post above on 10 Jan 2025, 09:10

(“the amount of deletions that occurred is substantially lower than expected. Having said that, when a Full backup job is run, Veeam will integrate the vib (incremental) jobs and merge to create a new restore point. This operation will remove duplicate data, data that is no longer required, or extend a short retention period for another 30 days that must be part of the restoration point. With your current setup, a full backup job monthly once is required and is necessary to perform all mentioned actions above. Otherwise, you would simply have incremental forever.«)

[MaartenA]

Could it be related to wasabi storage policy?
https://docs.wasabi.com/docs/how-does-w ... olicy-work

See you need to wait 90 days with the Pay as you go or 30 days with the commited before you will see lower Numbers on the wasabi side.

[mtv]

They assured me (wasabi helpdesk), that they set 30 days storage policy (for Veeam users) - which is long gone and also i think that deleted items inside this period are visible in dashboard in "Deleted storage" window. I have only 4GB inside.

[veremin]

Am I correct in understanding that the backup copy job is set to immediate copy mode and copies backups daily? Also, considering that the expired backups aren't being deleted daily, it leads me to think that you might have long-term GFS retention configured. If so, could you please share the settings for it? If not, could you let me know the date on which the full backup was created? Thanks!

[mtv]

Yes, we have immediate copy 3 times / day on working days and 1 time on weekends. GFS (6 monthly) just on main backup job to NAS, but not on copy job to Wasabi (no GFS on Wasabi).
An intermediate full backup (as Wasabi help desk suggested; but Andreas Neufert declined as solution) was on 9.1.2025 and later again on 2.2.2025 (each size aprox 300GB) and both are still visible in VBR Console in Object Storage Backup Properties and included in Backup size 1.89 TB today (Yesterday was 1.87 as already mentioned)

[mtv]

@veremin do you need any other data from me to give an epilogue to the problem?

[veremin]

Honestly, it's rather difficult to understand the nature of your setup and the cause of your problems through forum correspondence.

I believe that by periodically creating full backups manually, you were causing the retention process to behave like a forward forever incremental mode with periodic fulls, where the merge procedure is not used, and where a certain amount of time must pass before the previous chain segment is deleted (until the required number of increments is built from the fresh full backup, or until the entire previous chain segment exceeds the set period of X days - since we cannot delete the full backup immediately after it expires because there are still unexpired increments depending on it).

That's why you observed that points are removed from the UI only after some time, and that the whole backup chain segment is removed at once.

Thanks!

[mtv]

Thank you! I hope that your predictions will come true because now the only constant is that the wasabi archive is only linearly growing every day from day one and nothing is deleted, and as a result, costs and dissatisfaction are increasing. Since so far the predictions of your colleagues who have previously handled the case have not come entirely true (our input data was always the same), it would be helpful to have information on when - which day or in how many days the deletion will occur so that we don't speculate and check daily for free.

[ericschott_OF]

You might try out Object first's sizer to see if that provides insight. You can select copies to go to wasabi

https://objectfirst.com/backup-storage-calculator/

[pirx]

Thank you! I hope that your predictions will come true because now the only constant is that the wasabi archive is only linearly growing every day from day one and nothing is deleted, and as a result, costs and dissatisfaction are increasing. Since so far the predictions of your colleagues who have previously handled the case have not come entirely true (our input data was always the same), it would be helpful to have information on when - which day or in how many days the deletion will occur so that we don't speculate and check daily for free.

Same problem here, Wasabi bucket is constantly growing.