but will not take the created restore points into account when estimating the SLA compliance for the policy. That is why it is recommended that data protection windows do not overlap in one SLA template.
I would recommend to remove these sentences
25 Matching Annotations
- Apr 2025
-
tw-preview.dev.amust.local tw-preview.dev.amust.local
-
-
tw-preview.dev.amust.local tw-preview.dev.amust.local
-
SLA Templates
I suppose link should be named 'Temporary Snapshots'
-
Since Veeam Backup for Microsoft Azure runs retention sessions for the related SLA-based backup policies as soon as it finalizes the backup window in all protected regions, it is recommended that you estimate how long it may take Veeam Backup for Microsoft Azure to complete these retention sessions first (the larger the infrastructure, the longer the retention sessions run) before you configure a backup window. Otherwise, Veeam Backup for Microsoft Azure may encounter throttling issues when trying to remove obsolete data from backup repositories.
probably I'm wrong, but for me from this description it's not clear that we don't recommend to use backup window 24 hours
-
TipIn large environments, it is recommended that you configure separate windows for backups and snapshots to optimize backup performance and decrease the load on your infrastructure.
where does this TIP come from?
-
in all protected regions
'in corresponding protected regions'
-
restore points
I suppose it should be 'snapshots'
-
read from processed Azure VMs.
not sure if we should change it, but I would like to clarify 'read from snapshot of processed VMs'
-
restore points
I suppose it should be 'snapshots'
-
-
tw-preview.dev.amust.local tw-preview.dev.amust.local
-
all
I would change 'all' to 'corresponding', because retention starts per source region
-
full
it's actual for incremental RPs too: if there is no todays RP archive will create a temporary RP
-
-
tw-preview.dev.amust.local tw-preview.dev.amust.local
-
daily
please remove 'daily', snapshot window specified for any kind of snapshots
-
- Mar 2025
-
tw-preview.dev.amust.local tw-preview.dev.amust.local
-
can neither remove data from Microsoft Azure using any cloud service provider tools nor request the technical support department to do it for you
cannot remove data before it's immutability will be expired
-
cannot remove data manually
cannot remove data before it's immutability will be expired
-
it is recommended that you estimate how long it may take for Veeam Backup for Microsoft Azure to complete a retention session first, and then configure a backup window
I would re-phrase it to: don't setup backup window = 24 hours and keep some time to run retention
-
as it finalizes the backup window in all protected regions,
retention performed per source regions, it does not wait for all regions.
-
Otherwise, Veeam Backup for Microsoft Azure will not be able to run retention sessions.
I would re-phrase it, because a lot of CX already scheduled policies at 12 AM and retention works for them..
-
supports only entire VM restore
disks restore and FLR also available for archive
-
Standard_F2s_v2 with 2 CPUs and 4 GB RAM for regular backup
it's our default for simple configuration, correct. but in advanced config there are 2 more sizes, not sure if it should be mentioned here
-
Standard_B2s with 2 CPUs and 4 GB RAMStandard_B2ms with 2 CPUs and 8 GB RAM
- I would mark B2s as very beginner level.
- should not we mention other sizes from Bug 819403
-
-
tw-preview.dev.amust.local tw-preview.dev.amust.local
-
In This Section
there is no bullet for Permissions Changelog
-
To attach virtual disks to worker instances when performing image-level backup.
what does it mean? is not it from VB4AWS UG? worker does not attach any source VM's disks for backup and we have separate bullet for worker: "To create and manage worker instances." which should cover worker data-disk creation
-
-
tw-preview.dev.amust.local tw-preview.dev.amust.local
-
Microsoft.ServiceBus
VB does not use it anymore, not sure it should be mentioned
-
-
tw-preview.dev.amust.local tw-preview.dev.amust.local
-
to , se
the purpose is missed. I know that these perms are needed for config key to lock failed workers from removing.
-
- Jul 2022
-
helpcenter.veeam.com helpcenter.veeam.com
-
Standard_E2_v4, 2 CPU 16 GB RAM
Standard_E2_v5, 2 cpu, 16Gb ram by default
-
Standard_F2s_v2, 2 CPU, 4 GB RAM
correct
-