Forum R&D Forums

Hello, Restore VMs to Azure is causing our business to increase the amount of money that they pay to the server. Example: We have a server with 2 disks. One disk 100GB and the other one 1024GB. When we restore it to Azure, the disk 1 is restored with 101GB and the disk 2 with 1025GB. After that we will pay next tier of each disk, in the case of the 1024 , we will pay for 2048 and we don´t have any option to reduce the disk one Azure. VERY BAD SITUATION.

For sure. I was merely pointing out that what is simple from a coding perspective is sometimes, as in this case, much more complex operationally.

The one thing is, the Veeam Updater service fails and you might get errors like ... Failed to synchronize update settings. Error: Failed to connect to the Veeam Updater service The other thing is, your overall infrastructure health decreases as well ;p Suddenly, your infrastructure looks worrysome

yes, we are using private mode deployment

I had the same problem (#08242899), technical support came up with a workaround.

Hi, this reads like exactly what I ran into. Except that my testing scenario is at 150M small objects (less than 256 KB) and my production is currently sitting at 400+M with a projected size of 1+B in a few years. My Veeam support case is # 08232244 and it's been escalated. I am doing an object to object backup. Both sides are Ceph-based. I have 4 backup proxies (virtual) with Direct connection to the backup repository. I also put the "Backup I/O" slider (in the source bucket properties) to the most aggressive setting "Faster backup". Source bucket is a flat space, there is no folder structure, all the objects are sitting in the root of the bucket. It seems this is not an ideal situation in terms of how Veeam parallelizes the job, but for now I cannot change it. My initial full backup started at 138.7M objects. The backup took 30 hours in total. First 9 hours there were no writes to the backup repository. My reading is that Veeam was enumerating the bucket contents because there was a huge number of read I/O targeted at bucket.index pool. After 9 hours Veeam started to write to the repository and this continued for 20 hours at around 40 MB/s, tranferred 4 TB. Then there was 3 hours of "break", there were no writes. Unclear what Veeam was doing (writing CRC on the object cache maybe?). Then there was another 40 minutes long write activity which corresponds to 55 minutes of job reporting as "backup metadata update". My second backup (first incremental) eventually processed 152.

Hi, Are you using private mode deployment in your deployment?

Hi, Are you using private mode deployment in your deployment?

Download link: Signatures 1.8.235 Compatibility: Veeam ONE 13.0, Veeam ONE 13.0.1, Veeam ONE 13.0.2, Veeam ONE 13.1.0 Veeam Backup & Replication 13.0.3 (13.0.3.63) is available The Veeam Backup & Replication 13.0.3 (13.0.3.63) addresses the following security vulnerability: CVE-2026-58070 - A vulnerability that causes guest OS credentials used for Application Aware processing to be recorded in cleartext in logs on the guest machine. Veeam Backup & Replication 13.1.1 (13.1.1.18) is available The Veeam Backup & Replication 13.1.1 (13.1.1.18) resolves the following: Veeam Software Appliance - proxy configuration causing service failures and HTTP 502 errors after an upgrade. Object Storage Repository - immutability mismatch errors in backup jobs that write directly to object storage. Guest Processing - PostgreSQL instance exploration warnings on Windows machines. Cloud Connect - certificate revocation cache issues for tenant deployments that target Cloud Connect repositories with publicly trusted SSL certificates. Veeam Agents - updated agent versions: Veeam Agent for Microsoft Windows 13.1.1.700, Veeam Agent for Linux 13.1.1.4 and Veeam Agent for Mac 13.1.1.3. Veeam ONE 13.0.2 P1 (13.0.2.7159) is available The Veeam ONE 13.0.2 P1 (13.0.2.7159) addresses the following security vulnerabilities: CVE-2026-64633 - A vulnerability allowing remote unauthenticated code execution on agent hosts. CVE-2026-58075 - A vulnerability allowing unauthenticated arbitrary file reading, enabling pr

Thanks Alex! I can also confirm, the auditing has been fixed in this 12.3.2.485 build.

Hi Team, This is regarding regarding trusted client certificates for CloudSQL Backup. as per Cloud GCP Team, they confirmed that SSL/TLS connection is allowed but not working with required trust certificates. It is very critical as per our future projects which are in pipeline to have this feature. Can you please look into it. Veeam Support - Case # 07226769

Hi, I'm wondering what the process is for adding a new tenant. Pure speculation: 1) Add tenant via UI/PowerShell 1a) VBM365 creates a new application in Entra ID 2) Tenant updates EWSAllowedAppID to include new Application ID 3) Wait ~24 hours 4) Create & run backup Is this the "correct" approach now? Thanks. /Lasse Check the EWS Usage Report in the Microsoft 365 Admin Portal: " EWS usage report " There may already be applications in your tenant that rely on EWS. Common examples include Outlook itself (for certain operations) and the Apple Internet Accounts application. From my experience, Apple Mail and Calendar on macOS still use EWS as of now, and Apple need to to fix this in a coming release! Before enabling the restriction, make sure to add all existing App IDs currently using EWS to the EWSAllowedAppId list. Otherwise, only the VB365 backup application would be allowed, and the other applications would stop working. In my environment, the initial activation of the parameter took effect within a few minutes. However, I forgot to include one App ID and added it shortly afterward. Interestingly, that additional change took much longer to become effective. In any case, if everything is working correctly right now, you can enable the allow list and continue running backups as usual. There is no need to wait 24 hours before running the next backup. In the future, it is possible that newly whitelisted App IDs may take several hours before Exchange Online backups start working