387 Veeam Backup & Replication 13.1 is now available, with enhancements spanning identity protection, hypervisor support, malware detection, backup infrastructure and operational automation. Automated Active Directory forest recovery and the expanded hypervisor lineup will get most of the attention, and deservedly so. The more consequential changes for storage teams are in the repository, and they point in a consistent direction. Veeam 13.1 treats the backup repository as something you operate against during a recovery, not simply a place where backups land. That distinction matters because most backup architectures are still designed around the write path. Jobs complete, immutability is configured, capacity is monitored. What happens next — who can reach the data, from where, and whether anyone has proven it restores — usually depends on the same backup server that created the backups in the first place. Several of the 13.1 repository changes exist to break that dependency. Read-only repository access is the change that matters A second Veeam Backup & Replication server, such as one located at a disaster recovery site, can now connect to an immutable object storage repository already managed by the production backup server. The second server cannot write to or modify the stored data. It can use the repository for restores, recoverability checks and Data Integration API-based forensic or ransomware scans without assuming ownership or disrupting active backup jobs. Previously, accessing the repository from another backup server could require transferring repository ownership. That introduced coordination requirements and made regular testing more difficult, particularly when the production environment needed to remain available. In practice it meant recovery testing from a separate server was something teams intended to do rather than something they did. Read-only access provides a cleaner separation between production backup operations and recovery activities. An organization could maintain a secondary Veeam server with access to an immutable repository and use it to: Test restores without changing the production repository Investigate backup data following suspicious activity Validate recovery points from a separate administrative environment Restore data if the primary Veeam server becomes unavailable The last of those is the one worth dwelling on. A compromised or unavailable backup server has historically been a recovery problem in itself, because the path to the data ran through it. Read-only access makes a standby administrative environment a supported configuration rather than a workaround. It is worth being precise about what the feature does and does not do. The option applies to immutable object storage repositories, and read-only access is selected when the repository is connected on the second server. Veeam’s own guidance adds an important detail: the credentials used to add the repository should themselves carry read-only permissions, because full-access credentials can produce unpredictable behavior. Read-only mode constrains what the secondary Veeam server will do. It does not isolate the underlying storage network, and it is not a substitute for separate credentials, network segmentation and documented access procedures. Object storage extents remove the unstructured data ceiling Object storage can now be used as an extent within the scale-out backup repositories used for unstructured data backup. Capacity can be added incrementally across on-premises or cloud-based object storage deployments without redesigning the repository or interrupting existing jobs. This is important because unstructured data rarely grows in predictable increments. File shares, video repositories, research data, engineering files and application-generated content can quickly outgrow a fixed backup target. A scale-out repository allows storage capacity to expand alongside the protected data while keeping backup management within Veeam — which in turn means a capacity decision no longer forces a repository redesign. Several related improvements make large file estates cheaper to protect: Grandfather-Father-Son retention can be configured directly within NAS and object storage backup jobs, with weekly, monthly and yearly restore points referencing existing backup data rather than requiring additional full copies. Files larger than 32 MB can be processed incrementally, so Veeam transfers only modified portions instead of reading the entire file again. Access control list changes can be captured during incremental backups and reapplied during recovery. Additional source-side parallelism improves throughput when protecting large individual file shares. Object storage removes many fixed-capacity limitations, but it does not remove the need to size for ingest rate, retention period and recovery throughput. Network bandwidth, gateway resources and the performance of the underlying storage nodes still determine how quickly data can be protected and recovered. Knowing what the repository actually holds Object storage consumption has been difficult to estimate from logical backup sizes alone. Block reuse and other optimizations mean the figure shown for a backup chain may differ substantially from the physical capacity it occupies. Veeam 13.1 now displays both: “Backup size” for the logical size and “Actual size” for the capacity consumed after optimizations, either for a specific repository tier or across all tiers at once. This is a small change with disproportionate value for anyone running tiered or scale-out storage, because expansion decisions can finally be based on measured utilization rather than estimates derived from protected capacity. It also improves the conversation between backup, infrastructure and finance teams: backup administrators can point to what is consuming physical capacity, and storage administrators can plan expansion before the repository approaches its operational limits. Detection, immutability and testing do different jobs Unstructured data holds a large share of most organizations’ valuable information and is difficult to monitor during a ransomware incident. Attackers may encrypt, rename or delete files across large shares while remaining unnoticed until users begin reporting inaccessible data. Veeam 13.1 extends malware detection to unstructured data workloads. File-level analytics can identify suspicious patterns such as mass renaming or deletion, while Indicators of Compromise scanning provides another signal for potentially malicious activity. Veeam Threat Hunter now supports file-share and object-storage backups as well, with automated post-backup scans or on-demand inspections using signature detection and customizable YARA rules. Both capabilities require the Advanced Edition of the Veeam Universal License, so licensing belongs in upgrade planning. Read alongside the read-only repository work, this produces a clear division of responsibilities: Veeam monitors backup activity, analyzes data and helps identify appropriate recovery points. Immutable object storage prevents protected backup objects from being altered or deleted during their retention period. A secondary Veeam server can access the repository in read-only mode to investigate and to prove that recovery works. No single one of those determines whether an organization recovers from ransomware. Detection explains what happened, immutability preserves usable recovery points, and testing confirms those points restore inside the required window. The reason the 13.1 repository changes are interesting together is that they let each of those three jobs be performed by a different part of the architecture. More retention flexibility, with a sharper edge A new Copy policy for the scale-out backup repository Archive Tier lets qualifying GFS restore points be copied to archive as soon as they are created, while the local version remains on the Performance Tier until its normal expiration. Copy and Move policies can be combined, keeping recent restore points on faster storage while another copy is retained on lower-cost archive storage. One constraint is worth checking before designing around it: the Copy policy applies only to Direct Archival configurations, meaning a Performance Tier and an Archive Tier. Configurations with a Capacity Tier between the two do not support Copy mode. Archive repositories can also be configured with a minimum immutability period — a fixed number of days during which data cannot be deleted or modified — instead of remaining immutable for the full retention period. This is genuinely useful for controlling archive costs, and it is the one new option in the release that can quietly weaken a recovery position. A short immutability window protects the period right after a backup is written, but it also exposes older recovery points to deletion while they may still be operationally or legally required. The window should be set against how long a compromise typically goes undiscovered, how many clean historical restore points the organization needs, and what regulation requires — not against the capacity you would like to reclaim. Direct archive options apply to supported archive-class services such as Veeam Data Cloud Vault Archive, Azure Archive and Amazon S3 Glacier, rather than to every S3-compatible repository. An on-premises object storage platform can therefore remain the primary immutable recovery layer while a separate archive service holds infrequently accessed data for longer periods. Two smaller changes worth noting Veeam 13.1 adds Gateway mode when backing up IBM AIX and Oracle Solaris agents to S3-compatible object storage, routing backup and restore traffic through a gateway server assigned in Veeam rather than requiring every protected endpoint to reach the object storage system directly. For the many enterprises still running critical Unix systems on isolated network segments, this removes a real deployment obstacle. The gateway does become part of the data path, so it should be sized for the throughput it now carries. The release also broadens hypervisor support considerably, adding Citrix XenServer, XCP-ng and Sangfor aSV natively while Platform9 and VergeOS join through the Universal Hypervisor API. The repository consequence is easy to miss: as more platforms converge on the same backup infrastructure, a repository designed around a single hypervisor becomes a constraint on which platforms you can adopt. S3-compatible object storage decouples the two, so virtualization decisions and storage decisions stop being the same decision. What Veeam 13.1 means for Scality ARTESCA Scality ARTESCA provides an on-premises S3-compatible repository designed for backup and cyber resilience. ARTESCA is listed in the Veeam Ready program as a Veeam Ready Repository – Primary Target for Veeam Backup & Replication 13, with validated attributes including object immutability, IAM and STS, Smart Object Storage API support and governance mode. Three of the 13.1 changes line up directly with how ARTESCA is deployed. Read-only repository mode supports recovery testing and investigation from a secondary Veeam server while the immutable repository stays under production management. Object storage extents let Veeam’s unstructured data repositories expand horizontally as protected capacity grows. And ARTESCA’s use of S3 Object Lock to preserve backup objects through their retention period is the storage-layer half of the division of responsibilities described above — Veeam analyzes and orchestrates, the storage platform enforces. Scality also offers the ARTESCA+ Veeam Unified Software Appliance, which combines Veeam Backup & Replication with ARTESCA object storage. It is listed as Veeam Ready for Veeam Backup & Replication 13 and can be deployed as a primary backup system or as a secondary repository with a standby Veeam instance — a configuration the read-only repository work makes more useful than it was. As with any platform update, the exact Veeam build, ARTESCA version and intended architecture should be validated against current compatibility information before upgrading production systems. Building a more usable recovery layer The object storage changes in Veeam 13.1 are significant because they address what happens after backup data has been written. Read-only access supports recovery operations outside the production backup server. Malware scanning provides evidence about the integrity of unstructured data. Object storage extents absorb growth, and actual-size reporting makes capacity planning a measurement rather than an estimate. None of that arrives with the upgrade. An organization that installs 13.1 and changes nothing else has the same recovery architecture it had before, with more options available. The work is deciding which of those options belongs in the design: whether a second server should hold read-only access, whether the immutability window survives contact with realistic discovery timelines, and whether anyone has restored at production scale recently enough for the answer to mean anything. The objective does not change. Preserve clean recovery points, maintain access to them during an incident, and prove the environment can restore data at the speed the business requires. Frequently asked questions What is new in Veeam Backup & Replication 13.1 for object storage? The most significant addition is read-only access to immutable object storage from a second backup server. The release also adds object storage extents for unstructured data repositories, actual-capacity reporting alongside logical backup size, an Archive Tier Copy policy and minimum immutability period, Gateway mode for AIX and Solaris backups, and malware detection and Threat Hunter support for unstructured data. Can a second Veeam server access an immutable object storage repository? Yes. Veeam 13.1 allows a second backup server to add an immutable object storage repository in read-only mode. The secondary server can perform restores, recoverability checks and supported forensic operations without modifying the data or taking ownership from the production server. Veeam recommends that the credentials used also carry read-only permissions. Does Veeam 13.1 improve NAS backup to object storage? Yes. Object storage can be used as an extent in scale-out repositories for unstructured data backup. The release also adds GFS retention within NAS backup jobs, incremental processing for files larger than 32 MB, ACL change tracking, improved single-share performance and additional malware detection. Does Veeam Backup & Replication 13.1 support Scality ARTESCA? Scality ARTESCA is Veeam Ready for Veeam Backup & Replication 13 and supports validated object storage features including immutability, IAM and STS, SOSAPI and governance. The exact Veeam 13.1 build and ARTESCA version should be confirmed against the latest compatibility information before production deployment.
