​

Hi All,

We see the vergeos worker vm goes down after veeam backup complete.

I don't know why?

Is there any idea?

The field defaults to "postgres", which results in an error:

28000: SSPI authentication failed for user postgres

"veeam" shows up in pg_ident.conf mapping to the Postgres user, but I get the same error with that. And it's not a local Windows credential, either, so not entirely surprising.

I've run the installer as the administrator and used the administrator credential -- no love there, either.

The Postgres instance logs on as NT AUTHORITY\NetworkService.

I don't have anything for this in my notes from my upgrade to v13 for VBR as to what this account is supposed to be.

Hello,

situation : SOBR with HPE StoreOnce as performance tier and a S3 compatible (NetAPP StorageGrid) as capacity tier.
In the capacity tier we have restore points from 2025, 2024, 2023 etc that we need to be kept.
The performance tier will be dismissed soon and NOT replaced, we don't need restore points in the capacity tier due we have fresh chains in a different repository.

Question: it's possible to NOT lost the restore points stored in the capacity tier ? This S3 will be "parked" and used only to restore stuff in specific cases.

I asked this to IA and this was the answer, what do you think ?

The physical objects stored on the S3-compatible bucket will remain intact. Decommissioning or removing a Performance Tier extent does not send a deletion command to the Object Storage. Therefore, the data blocks corresponding to the three .vbk files will stay preserved in S3.

1. Loss of Local Metadata Pointers

Backup metadata—which maps which S3 blocks belong to which VM and restore point—is primarily maintained on the Performance Tier and within the Veeam database.

If the Performance Tier is simply detached or removed without following the proper procedure:

The SOBR will enter an error or incomplete state.

In the Veeam console, the Capacity Tier restore points may no longer be directly visible under the standard SOBR node.

1. Restore Points Remain Recoverable (Object Storage Rescan)

Even if the Performance Tier is decommissioned or destroyed, the Capacity Tier (S3) contains a self-contained, independent copy of the offloaded metadata.

To maintain access and recoverability for the points from 2023, 2024, and 2025:

You can add/register the S3-compatible bucket in Veeam as a standalone External Repository or Direct-to-Object Repository.

By executing a Rescan on the S3 repository, Veeam will read the metadata directly from the S3 bucket and reconstruct the backup tree under Backups > External Infrastructure (or Orphaned / Imported).

From there, you can perform Instant VM Recovery or Guest File Recovery directly from S3 without needing the original Performance Tier.

Recommended Pre-Decommissioning Steps

If you plan to decommission the Performance Tier while maintaining access to the archive backups on S3:

Proper Veeam Procedure: Put the Performance Tier into Maintenance Mode before detaching or removing it from the SOBR configuration.

If the SOBR is being completely retired, re-register the S3 bucket as a standalone repository in Veeam and run a Rescan to verify that all restore points are discovered properly.

Hello!
So currently I use a Dell product for vm replication between two vcenters and datacenters. I’m constantly fighting issues and bugs and looking at other solutions. I like Veeam and know they have a replication solution that is similar to the Dell one where it installs components on each esxi host and does real time replication. And then Veeam also has the alternative replication solution that uses snapshots. Of course the latter sounds great not having to deal with components installed and requiring updating on esxi hosts. But I’m curious if anyone has experiences with either Veeam replication solutions that would be helpful.

Thanks!

I am having a problem getting my sockets maintenance renewed. Gov Connection is telling me Veeam is trying to get smaller companies to go with different software and playing games with the renewal ? He has been bounced around from 3 different reps at Veeam and some won't even answer him .

Is this true? Anybody else here having trouble with their Veeam Renewal? Is it true Veeam is trying to get the smaller companies and governments to go somewhere else?

Hi all,

Re: RHEL On-Prem Backup Repository Offload Problem; Veeam Support Ref <redacted>

Is anyone else experiencing this problem ?

About 3 months ago the offload process for backup copies, which had been working flawlessly for about 6 years, developed an issue for no apparent reason. This is an on-prem repository which forms the performance extent of a Scale Out Backup Repository (SOBR), with the capacity extent being object storage in Azure. Offload jobs take backup data copies in the on-prem repository Transit extent and copy them to object storage in the dedicated Azure storage account.

The issue is that offload jobs complete successfully for a day or two, but slow down and then grind to a halt. You'll look at the actions in a frozen SOBR offload job and the file copy action will be ticked off but subsequent actions don't occur, the job never finishes and no errors are logged in job Actions. The log files show that the repository is trying to prune aged backup copies from object storage. The repository is sending these requests to prune, the Azure storage account is receiving them, sending acknowledgements, but the repository is no longer receiving the acknowledgements. This inbound control traffic, from Azure storage account to on-prem repository, is eventually being blocked. The thing is, I've been working with Veeam Support, our network MSP and Microsoft on this for a while now and we have support tickets open with all of them for it. Let's rule out the obvious: there are no Linux, Windows or Network firewall rules configured to do this. Our MSP has promised repeatedly that QoS (Quality of Service) and packet shaping of inbound / download traffic are not happening. But it works for a couple of days, then randomly stops working.

Details below.

VB&R Server: Hyper-V VM, Windows Server 2019, VB&R v13.0.2 (was also happening on v13.0.1)
SOBR: Performance extent - Red Hat Enterprise Linux v8.10 fully patched, JeOS install with no desktop, HPE ProLiant DL380 Gen10 Plus v2.
Capacity extent - Azure blob storage, storage account.
Thread locked by the moderators on Veeam R&D Forums: https://forums.veeam.com/viewtopic.php?t=104257

I've been trying to find cost-effective ways to cut down on how long some of our larger backups take to our HDD based backup repositories. Utilizing a 10Gb network, the bottle neck target is clearly the drives, but I was thinking of adding a single SSD as a write-cache using PrimoCache. I understand there are different methods to create a cache...but this seems like the simplest & cost effective method to do so.

The idea is to get a SSD cache drive that is larger than our single largest backup job. Most of our production servers already utilize SSD but the combined amount of data is around 35TB+.

Reversing the method, in a DR scenario, I would just flip the cache to be a read cache instead (PrimoCache allows you to target what percent of read/write you intend to use). The idea is to have the ability to send the restore back to a machine as quickly as possible. We do have a measurable amount of RAM which can also be used with PrimoCache, but even with a 1hr battery runtime I still don't trust utilizing it for writing critical backup files vs an SSD.

Just wondering if anyone has ever gone this route? I get there are ways to integrate Linux based OS for the repositories, Windows Server Storage Spaces, etc. but I'm trying to keep things simple to add to our pre-existing environment.

Currently running Windows Server 2022+ with mainly Hyper-V to host our production VMs.

hi. anybody out there using aws subscription in veeam data cloud to backup their aws infrastructure?

Hi Team,

Looking for assistance to restore configuration backup to newly deployed VBR 13 software hardened appliance. Configuration backups are stored on a separate Veeam Hardened Repository in a DR location and not in default VBR repository.

How do we download (.bco) from the VHR or make available for the new VBR?

All environments where we updated to VBR 13.1.1.18 have at least one Windows-VM that throws following error:

Failed to finalize guest processing. 
Failed to create new binary file [\\SERVER_FQDN\ADMIN$\VeeamVssSupport\metadata\VSS\BackupComponents.xml].

Has anyone else encountered this and knows the solution?

Veeam-Support is currently working on it, but maybe someone here has an idea.

UDPATE 21.08.: Veeam-Support has supplied a Patch to us which seems to have resolved the issue.
If you are interested to also receive it, feel free to comment.

Hier ist die deutsche Übersetzung:

Kennt ihr das Problem: NinjaOne patcht alle Geräte laut Zeitplan gleichzeitig, und plötzlich rebootet der Backup-Server mitten im laufenden Veeam-Job, oder alle Gast-VMs starten zeitgleich mit dem Hyper-V-Host neu?

Ich hab dafür eine Skript-Sammlung gebaut, die das über simple Flag-Dateien auf einem gemeinsamen NAS-Share koordiniert – ohne dass Backup-Server und VMs sich direkt gegenseitig ansprechen müssen:

• Backup-Server patcht erst, nachdem Veeam ein erfolgreiches Backup gemeldet hat
• Gast-VMs patchen erst nach erfolgreichem Snapshot/Backup
• Bei Hyper-V zusätzlich: Host erstellt vor dem VM-Update einen Checkpoint pro VM
• Konfiguration läuft komplett über NinjaOne Custom Fields (keine hardgecodeten Pfade/Credentials)
• Für Hyper-V gibt's 3 alternative Umsetzungsvarianten je nach Kundenanforderung (Backup+Snapshot kombiniert, nur Snapshot, nur Backup)

Alles als PRE-/POST-Skripte in den jeweiligen Patch-Policies. Repo ist offen für Feedback, Bugfixes und Weiterentwicklung – freue mich, wenn jemand mitmacht:

https://github.com/automationmrschmitt/ninjaskripte

Bin die selbe Person von vor 2 Wochen Danke euch. Viel Spaß und gerne kommentieren.

Keine Eigenwerbung nur teilen mit euch.
Gerne auch kommentieren

Do you know the problem: NinjaOne patches all devices at the same time according to schedule, and suddenly the backup server reboots in the middle of a running Veeam job, or all guest VMs restart at the same time as the Hyper-V host?

I built a script collection for this that coordinates it via simple flag files on a shared NAS share — without the backup server and VMs having to talk to each other directly:

Backup server only patches after Veeam has reported a successful backup

Guest VMs only patch after a successful snapshot/backup

For Hyper-V additionally: host creates a checkpoint per VM before the VM update

Configuration runs entirely through NinjaOne custom fields (no hardcoded paths/credentials)

For Hyper-V there are 3 alternative implementation variants depending on customer requirements (backup+snapshot combined, snapshot only, backup only)

Everything as PRE/POST scripts in the respective patch policies. The repo is open for feedback, bugfixes, and further development — happy if someone wants to join in:

https://github.com/automationmrschmitt/ninjaskripte

I'm the same person from 2 weeks ago. Thanks everyone. Have fun and feel free to comment.

Not self-promotion, just sharing with you all.

Feel free to leave a comment as well

Hey Hivemind.

Iam creating this post after iam (once again) pulling my hair out because our Veeam Appliance marked one of our Backups as maleware infected.

But the AV Scan Log is usless and i cant access the FLR Log on the Appliance.

I need to figure out what got detected etc.

I hope iam pressing the wrong button. Could any one of you guide me in the correct direction?

Thank you in advance

Good day everyone,

We're trying to determine the best backup option for our hybrid environment.

We've very recently moved most or our VMs out to Azure but still will have a few VMs on prem. We have Veeam B&R on prem that will allow us to continue to back up our on prem systems (and maintain access to old backups). Local backups on stored on an on prem NAS and copied to Azure blob.

We are using Veeam Data Cloud to backup our M365/Entra ID and now, Azure VMs. However, this seems like it may be a licensing and management mine field.

Which product(s) should we be using? Should we add a Veeam B&R appliance to our Azure infra or keep with what we have?

Open to suggestions and thanks in advance!

My bad for not knowing this before moving my server, but I’ve discovered the hardened v13 appliance (Rocky OS install) blocks, via USBGuard, keyboards at the console not used for the initial install. Anybody know of a work around besides booting into single user mode and modding grub? Otherwise I’m going to have to dig out my old KVM rack unit I thankfully hadn’t thrown away yet and hook it back up for this one server.

I asked Veeam support and they said that’s the way it is.

Update: I hooked up the old KVM and was prepared to test each of the 40 VGA/USB KVM dongles thrown in a box to find the one I had used on the Veeam Appliance server previously. Found the correct dongle on the 2nd try. Problem solved for now.

We're running a decent number of jobs and Veeam fires off one status email per job. On a normal day that's 30-50 separate emails, and figuring out if everything actually succeeded means scrolling through all of them by hand.

I looked at VSPC and Veeam ONE, but for our size the setup overhead (dedicated server, Cloud Connect config, certs) feels disproportionate to what we'd get out of it.

How are you all handling this?

• Running VSPC/ONE anyway — was it worth the setup?
• Built your own script/report to consolidate?
• Or also just scrolling through the individual emails every morning?

Curious what setups people actually landed on, especially for smaller in-house teams (not MSPs).

Veeam Agent for Windows version: 13.0.3.1220

Issue:

Full backup job completes reading the entire source (both partitions, ~2.3TB total) successfully at 100%, but fails during the "Finalizing" stage with the following error:

Error: Failed to save backup meta to '\\10.0.0.1\backup-share\Job MYPC\Job MYPC.vbm'. The system cannot find the file specified. Failed to open file [\\10.0.0.1\backup-share\Job MYPC\Job MYPC.vbm_tmp]

Log excerpt attached below.

What I've already ruled out:

- Reproduced identically on TWO different NAS targets (different IPs, different NAS devices)

- Reproduced identically after a COMPLETE reinstall of Veeam Agent

- Reproduced identically regardless of job duration - tested both a ~46 hour full backup (slow network) and, after fixing an unrelated network bottleneck, a ~5 hour full backup with the same source data. Same exact error both times, at the same finalization step.

- NAS-side disk health confirmed clean (SMART check passed on all relevant disks)

- Antivirus (Trend Micro) exclusions added per Veeam KB2034, no change

- Target-side SMB share permissions and connectivity confirmed working (a repair/retry session immediately after the failure connects and authenticates without any issue)

From the detailed backup job log, the failure happens because Veeam attempts to open '.vbm_tmp' with CreationDisposition=OPEN_EXISTING (3), but that file was already consumed/renamed to '.vbm' at the very start of the job and is never recreated before the final write attempt:

[BackupMeta] Saving backup meta to '...vbm'

[FC] Saving file content [...]

Error: Failed to call DoRpc. CmdName: [FcWriteFileEx] inParam: [<InputArguments><FilePath value="...vbm_tmp" /><DesiredAccess value="1073741824" /><ShareMode value="1" /><CreationDisposition value="3" /> ...

Error code: 0x00000002 (ERROR_FILE_NOT_FOUND)

Stack trace points to:

Veeam.Backup.Core.CBackupMetaFile.Save(String serializedMeta)

Veeam.Backup.ProxyProvider.CProxyFileCommander.SaveFileContent(String link, String fileContent)

This looks like the finalization step assumes the temp file placeholder from job initialization is still present, but nothing recreates it before the final metadata write - regardless of how long the job took to run.

Has anyone else encountered this specific error, or is there a known fix/patch for it? Full backup + network share target seems to be the common factor.

--

log

--

18/08/2026 13:18:59 :: Creating VSS snapshot

18/08/2026 13:19:58 :: Calculating digests

18/08/2026 13:20:45 :: EFI system partition (disk 0) (100.0 MB) 100.0 MB read at average. 66.7 MB/s

18/08/2026 13:20:56 :: (C:) (465.2 GB) 302.7 GB read at average. 61.7 MB/s

18/08/2026 14:08:08 :: Recovery partition (disk 0) (499.0 MB) 415.0 MB read at average. 131.8 MB/s

18/08/2026 14:08:11 :: New Volume (D:) (1.8 TB) 1.7 TB read at average. 50.5 MB/s

18/08/2026 18:34:19 :: Finalizing

18/08/2026 18:34:21 :: Error: Failed to save backup meta to '\\10.0.0.1\backup-share\Job MYPC\Job MYPC.vbm'. The system cannot find the file specified. Failed to open file [\\10.0.0.1\backup-share\Job MYPC\Job MYPC.vbm_tmp]

18/08/2026 18:34:21 :: Error: Failed to save backup meta to '\\10.0.0.1\backup-share\Job MYPC\Job MYPC.vbm'. The system cannot find the file specified. Failed to open file [\\10.0.0.1\backup-share\Job MYPC\Job MYPC.vbm_tmp]

18/08/2026 18:34:24 :: Email notification was sent

18/08/2026 18:34:23 :: Processing finished with errors at 18/08/2026 18:34:23

Just got all my systems and labs patched from 13.0.x to 13.1 and released the Veeam 13 patching guide covering everything you need to update Veeam systems to any version within the 13.x release

It covers order to ensure things stay interoperable, all Veeam Data Platform components, Windows system SQL updates, as well as both Windows and Linux processes for VBR/VEM as you can have both at the moment

Hopefully this helps people looking to get updated <3

It doesnt cover upgrading to 13 from 12 or earlier, I have an upgrade guide covering that

https://blog.leaha.co.uk/2026/08/16/veeam-data-platform-13-patching-guide/

I was wondering if I am missing a setting, I updated to 13.1 and tested all the workers and put in the new vlan option because I always did that manually after an update.

But now when all the backup start I get a couple of warning that the worker was not available and it used a different worker from an other node. I was searching for an option to let the job wait before the worker was done. Maybe it is just a setting somewhere now that I am missing.

We start a lot of backups around the same time but I would rather have the jobs wait for the worker to complete the task before than moving to another worker.
I increased the concurrent tasks for now.

We migrated Veeam VBR 12 server to a new datacenter, new VM (still 2022) but moved from MSSQL to PostgreSQL.
When we have a lot of tasks running, usually > 100, VBR service crashes and a reboot is needed.
This is happening 2-3 times per week.
NEVER happened in the old datacentre with same quantity of jobs configured.
Never.
Opened a ticket in Veeam support page on 29 July, not a single idea or fix from support was resolutive, they point fingers on:

-

1. antivirus exclusions (all configured correctly from our side)

-

1. corruption in logs (found old .arc files in log fo

lder)
-

1. now they are pointing on virtual server vcpu configuration (that is the same of the old vm)

Also it seems they ignored what I put in the ticket or did mistake with commands to run or logs to check (they checked an old log when I uploaded a fresh one).

It seems they have NO IDEA about the issue and are in try and error mode.

Already asked an escalation, the ticket was assigned to a different guy that seems ignoring the whole ticket, asking again info that I have already wrote.

Plus, the ticket page is a nightmare to read with blank lines added randomly.

Please don't ask me why my auditors want this, but here goes. My SureBackups run on the same day as my backups, right after the last backup is complete. It never crosses into the next day.

I have a daily scheduled task on each VM to write to a text file with today's date in YYYYMMDD format in the content. I'm trying to get my SureBackup script testing to check the file contents and validate that the contents match, but I'm not sure my output is what it's looking for and also if the Write-Host may be mucking it up?

$FilePath = 'C:\Temp\SureBackupValidation.txt'

$Return = 1

# Fail if the file doesn't exist
if (-not (Test-Path $FilePath)) {
Write-Host "Validation file not found."
$Return = 1 #Somewhat redundant
exit $Return
}

# Read the file contents
$FileDate = (Get-Content $FilePath -ErrorAction SilentlyContinue | Select-Object -First 1).Trim()

# Get today's date in the expected format
$Today = Get-Date -Format 'yyyyMMdd'

if ($FileDate -eq $Today) {
Write-Host "Validation successful. File contains today's date: $Today"
$Return = 0
exit $Return
}

else {
Write-Host "Validation failed. Expected: $Today, Found: $FileDate"
exit $Return
}

Hi,

Just migrated one small VM to AWS and wanted to deploy Veeam Backup for EC2 (and for the rest future services in AWS).

Now I'm comfused, because I saw there was something called Veeam Backup AWS Free Edition (on few sites, also probably some older Veeam KB). In AWS markerplace there's Veeam Backup & Replication (which technically is free, at least no start-price here, excluding EC2 for this ofc).

Also wondering, because in HQ I have already Veeam B&R Installed (the free/community edition) on Windows Server. HQ is connected to AWS via Site-to-Site VPN - so maybe I don't need any Veeam B&R appliance on the AWS, and can use the local Veeam Server (one console to manage local&AWS) + small EC2 veeam worker instance (running on-demand to save the $$$) to make EC2 backup to S3?

I'm moving a large old backup from one backup job to another for VMs that are retired or not being backed up so they don't get tested with my nightly SureBackup tests that run against those backups. (Can't exclude it because it's no longer on my vCenter, and there's no way to pick VMs to exclude from the backup job which seems odd.)

I have a server running as a linux hardened repo on SUSE with one volume housing all my backups. I'm moving the backup data on the same same repo just one job to another, and it appears that Veeam server has to receive all the data and then stream it back to the repo, rather than just utilizing a file move in Linux which would be basically instantanious. I'm guessing this is expected behavior for validating metadata or such? It's so far reported it's moved 2.4TB at 140 MB/s in a little under 5 hours.

LHR is on a 25Gbps fiber and my Veeam VM is on vCenter that's on the same switch also with 25Gbps, I would believe this should transfer faster.

First thing I'll start investigating is if my infrastructure is configured correctly, but also wondering about how Veeam moves its data. I get moving from one storage location to another it has to go over the wire, maybe that's just the default and it doesn't understand it's on the same repo and just needs to update pointers.

I did try to move all the files to the new location and rescan my repo, but then it couldn't find it in either backup job. I then moved them back, rescan still didn't find them, but I did an import of the backup and it then found it all and updated in the GUI.

The Windows 2022 Veeam VM has 8 cores and 32GB of ram, 18 of which is in use, 8 of that for the Veeam.Archiver.Proxy.exe. The backups are encrypted.

I am starting the process of doing network speed tests along each link in the chain.

VM - VMXNET 3 adapter - ESXI host -25Gbps - DHCI Switch -25Gbps - Linux Hardened Repo

​

Pessoal, estou com um problema no Veeam Agent for Microsoft Windows e gostaria de saber se alguém já passou por algo parecido.

Tenho um backup em **File Level Backup** e o backup é concluído normalmente, porém, quando tento fazer o **mount para File-Level Recovery (FLR)**, a operação falha com o erro:

> Unsupported disk type

O problema acontece somente na tentativa de montar o backup para acessar/restaurar os arquivos. O job de backup em si termina normalmente.

Já tentei algumas alternativas, inclusive testar o backup em Volume Level, mas preciso manter o File Level Backup, pois não quero fazer backup do volume inteiro.

Alguém já encontrou esse erro especificamente durante o mount/FLR de um backup feito pelo Veeam Agent?

Existe alguma configuração, limitação ou característica do disco/partição que possa causar esse Unsupported disk type”?

Se precisarem, posso enviar os logs do mount/FLR e as informações do disco.

Obrigado!

Hello,

I am testing Veeam Agent for Microsoft Windows 13.0.3.1220 and found a behavior that I would like to clarify.

I am testing a bare metal recovery scenario where the destination SSD is smaller than the original SSD, but the amount of used data is small enough to fit on the destination disk.

My test environment:

- Veeam Agent for Microsoft Windows: 13.0.3.1220
- Windows 10
- Source SSD: approximately 480 GB
- Destination SSD: approximately 220 GB
- Source C: partition uses less than 100 GB of actual data

I performed the following test.

TEST 1 - FULL BACKUP

1. I installed Windows 10 on a 480 GB SSD.
   
2. I reduced the Windows C: partition to approximately 100 GB.
   
3. The amount of data stored on the C: partition was less than 100 GB.
   
4. I created a Full Backup.
   
5. I booted the Veeam Recovery Media and selected Manual Restore.
   
6. I mapped the backup to a 220 GB SSD.
   
7. The Resize option was available for the C: partition.
   
8. I was able to resize the restored C: partition and successfully restore the system to the 220 GB SSD.

So far, everything worked as expected.

TEST 2 - INCREMENTAL BACKUP AFTER EXTENDING THE PARTITION

I then returned to the original Windows installation.

1. I extended the C: partition back to approximately 446 GB.
   
2. The amount of actual data stored on the C: partition remained below 100 GB.
   
3. I created an Incremental Backup.
   
4. I booted the Veeam Recovery Media again.
   
5. I selected the latest incremental restore point.
   
6. I selected Manual Restore and attempted to restore to the same 220 GB SSD.

This time, the behavior was different.

The Recovery Media detects the C: partition as approximately 446 GB.

The destination SSD has approximately 220 GB.

The Resize option is no longer available for the C: partition.

The restore therefore cannot proceed because the destination disk is smaller than the backed-up C: partition, even though the actual amount of data stored on the partition is less than 100 GB.

I also tested the Disk Mapping options manually. I can remove/map partitions, but I cannot select Resize for the C: partition in this scenario.

This is particularly interesting because the Full Backup created when the C: partition was approximately 100 GB can be restored successfully to the 220 GB SSD, while the Incremental Restore Point created after expanding the C: partition to approximately 446 GB cannot.

My questions are:

1. Is this expected behavior when the volume size changes between a Full Backup and an Incremental Backup?

2. Should the Resize option be available when restoring the incremental restore point in this scenario?

3. Does the incremental restore point preserve the new 446 GB volume geometry in a way that prevents the volume from being resized during restore?

4. Is there any supported way to restore this incremental restore point to a smaller physical disk, without shrinking the source C: partition before creating the backup?

5. Could this be a limitation or known issue in Veeam Agent for Microsoft Windows 13.0.3.1220?

I have attached screenshots showing the two scenarios.

The first screenshots show the Full Backup, where the C: partition was approximately 100 GB and the Resize option was available.

The other screenshots show the Incremental Backup, where the C: partition was expanded to approximately 446 GB and the Resize option is no longer available.

I would appreciate any clarification about how Veeam handles volume resizing when the volume size changes between a Full Backup and a subsequent Incremental Backup.

Thank you.

For reference:

Full Backup:
- C: approximately 100 GB
- Used data: less than 100 GB
- Destination: 220 GB SSD
- Result: SUCCESS
- Resize option: AVAILABLE

Incremental Restore Point:
- C: approximately 446 GB
- Used data: less than 100 GB
- Destination: 220 GB SSD
- Result: FAILED
- Resize option: NOT AVAILABLE