Deleting from hot storage and managing full backups

[imscavok]

I have added my organization, and an Azure Storage account with a hot container, and an archive container. The archive appliance appears to be working no problem, and I'm able to do a Data Backup, a Backup Copy and retrieve from the copy, and a Data restore. Everything I need technically appears to be functional.

Where I'm having issues might be more related to best practices for managing backups, which I can't claim any expertise in.

I want to do a monthly full backup of all of my M365 stuff, and weekly incremental backups. I want to minimize the time any data is being stored in the hot container. It is very expensive, and it is very unlikely we will ever even need to recover files in a way that the built-in M365 tools can't support.

First question: Is there a way to have it delete the data from the hot container when the backup copy is complete? If not, what is the best way to minimize the time data is kept in hot storage? I see I can set a retention policy on the backup repository, but I have no idea how long it will take to complete the backup and I assume it will often depend on bandwidth throttling from Microsoft. Is there risk if the retention policy is exceeded before the backup copy is done?

Second question: Is there a way to put full backups in a job? From the documentation it appears that the first backup for a particular job is full backup and all subsequent backups for the job are incremental. So maybe the right question would be, is there a way to put new jobs on a schedule? If not, do people just have a reminder to start a new job on the 1st or whatever, or is it better to just use incremental backups indefinitely?

[Mildur]

Hello Andrew

Correct, we do 1 fullbackup and then only incremental backups. There is no way to create regurlar full backups.

May I ask, why „doing regular fullbackups“?
Fullbackups from Microsoft 365 will take a long time and there is the chance of being throttled by Microsoft. Happens often for data on Sharepoint and may happen for mailbox data too.

Way to go is to set the retention to a lower value on the primary backup repository and a higher on the backup copy. I would keep at least 2-4 weeks, just to have the capability for faster restores. Restoring from a Copy in Azure Archive will take more time. If you want to safe costs, I recommend to evaluate other services like Wasabi where the costs are lower. No API or egress costs.

Best,
Fabian

[imscavok]

How does the retention policy work with incremental backups? If I set it to 2 weeks and I do weekly incremental backups, does it only keep the incremental parts in the hot storage? E.g. if I needed to do a recovery, I'd have to do a full restore anyway because it would need the initial full backup plus all previous incrementals? Or does it reset the retention timer for everything in that job so it would indefinitely stay in the hot container?

[Mildur]

We don't have a "backup files" concept in Veeam Backup for Microsoft 365 with a VBK and VIB files. Even if we do only incremental backups, each new backup works as a full backup regarding the restore.

When the retention scheduler removes old restore points, it just removes the data from the repository which was only used by the outdated restore point. Data used in other restore points will stay in the repository.
https://helpcenter.veeam.com/docs/vbo36 ... tml?ver=70

Best,
Fabian

[imscavok]

So say I have a 500GB full backup, each daily restore point is 1GB, and I set my retention period to 14 days. After 6 months, the disk space used would still be around 514GB? And with how it functions, there's no way to put the initial full backup with the bulk of the data into a cold storage and only have the incremental backups in the hot storage?

If there's a file that's created after the initial full backup, it won't be recoverable after 14 days? Or does it permanently merge into the backup as the oldest recoverable restore point? The documentation you linked seems to contradict itself on this. Under snapshot-based retention, it says "The Version 3 is the latest and if no more versions will be created for the Item 1, it will be kept in Backup 1 storage along with initial versions of Item 2 and Item 3" which leads me to believe the latest version of files will be kept indefinitely beyond the retention period just not recoverable to specific points in time.

But under Removing Restore Points, it says "Once the latest restore point is out of the retention scope and, therefore, can safely be removed, the item A — the parent item of the latest restore point A2 — will be removed as well (Example 2)." which makes me think the item itself is deleted from the backup and would be entirely unrecoverable.

[Polina]

Hi Andrew,

1) With the following tool, you can estimate sizing and costs based on your expected numbers: https://calculator.veeam.com/vb365. It provides rough estimates but gives an idea of what to expect. When calculating sizing in object storage, this tool uses the max possible compression rates, which may vary in reality depending on the backed-up data.

And with how it functions, there's no way to put the initial full backup with the bulk of the data into cold storage and only have the incremental backups in the hot storage?

No, that's not possible. We provide backup copy functionality though, and, for example, you can set shorter retention on your primary repository (i.e. hot tier) and longer for backup copies (i.e. in a lower-cost object storage tier).

2) The latest version will remain in the repository for as long as it remains in production and is part of a consistent 'snapshot' state.