As described in the title, I would like to explain in this blog post why a Veeam Hardened Repo and Object First is a great combination.
A Veeam Hardened Repository and an Object First appliance each offer specific advantages for backups and restores, security, etc., but they also have their weaknesses. From a technical and cyber security perspective, combining both approaches offers a significantly stronger, more resilient backup architecture than either concept alone.
I work on a lot of Veeam projects for SMEs, SMBs, and enterprise customers. I see the combination of the two products as being more suitable for the SMEs and SMBs sectors. In the enterprise sector, due to the larger amounts of data and faster restores, other products are used, but I don’t want to go into those here, as this post is about Hardened Repositories and Object First.
Why different/multiple technologies?
The first point I would mention here is media or storage technology break.
A media or technology break in backup repositories is the basis for reliably implementing the 3-2-1-1-0 rule, ransomware resilience, and compliance (e.g., NIS2/DORA). Without this break, all copies effectively end up on the same technology/attack surface – then a single exploit or a configuration/file system error is enough to lose all backups at once.
The modern 3-2-1-1-0 explicitly requires “2 media types” and at least one immutable or air-gapped copy.
The technology break reduces the risk of a bug in the file system/storage/server stack (e.g., XFS/RAID firmware/disk firmware) destroying all backup chains.
Customers who are still using Veeam V12, for example, cannot yet write directly to S3 with the Enterprise Plugins. This means that they still need a repository other than object storage (hardened repo, NFS, etc.) as their primary repository. With V13, it is now possible to write directly to object storage. This means that this point only applies to V12 deployments and becomes obsolete as soon as V13 is in use.
This approach is essential for V12 customers with enterprise plugins.
Why this combination?
People often ask: Why still use hardened repositories and not just Object First?
Every product has its strengths, but also its weaknesses (as always). Since I don’t work for a manufacturer, but for a partner, and am always looking for the best solution for my customers, I can write and talk freely about how I see things.
But it’s the same as always. Not every repository solution is suitable in every case. That is the big advantage and disadvantage of Veeam. You have a lot of flexibility with the repositories, but this can sometimes be a problem because many people don’t know what to use.
I can use hardened repositories with internal and external disks, which can be HDDs, SSDs, NVMEs, etc. This allows me to guarantee fast recovery from SSDs/NMVEs.
Unfortunately, Object First currently only has HDDs installed. I hope that an SSD appliance will also be launched next year, so that we can restore much faster. On the other hand, I currently have more security with the appliance.
This makes the combination of an SSD repository as the primary and an Object First appliance with spinning disks and more security as the secondary repository a great combination.
Due to the large number of projects I work on, I naturally always see things that don’t run so smoothly.
One issue is particularly evident in repositories (without referring to Object First or Veeam Hardened Repositories specifically, but rather as a general problem/topic): When there is less intelligence built in, less code in the data path and fewer components are in use (e.g., metadata databases, deduplication databases, load balancers (fortunately, the last two are not used at Object First and Veeam Hardened Repository), etc.), there are fewer problems with backups and restores.
And that is a huge advantage of the Veeam Hardened Repository. It is designed to be as simple as possible, and potential sources of error are minimized (With the hardened repository, data is written directly to XFS, while with object first, data is written to XFS via S3 stack).
However, it must also be clearly said that the problems often come from Veeam rather than the repositories. This is simply due to things like block size, number of S3 API calls etc. No matter how good the repository is, if the application does not implement the storage properly, it will not work smoothly. Fortunately, V13 has improved this situation significantly.
That’s why I’m a huge fan of Veeam Hardened Repositories for primary repositories, either with internal hard drives (here you can install the repository with the Veeam Hardened Repository (V12)/ Infrastructure Appliance ISO (V13)) or with external disks (here you have to install the repository manually, and you are also responsible for hardening and installation yourself and do not receive any Veeam support).
Veeam Hardened Repositories don’t have too much intelligence built in, simple x86 components, and work great.
But here’s where a big disadvantage becomes apparent: depending on whether I have internal or external disks.
If I have a server with internal disks, I can use the Veeam Hardened Repository/Infrastructure Appliance ISO for installation. With that, I have the same standards and security, automatic updates, etc. with every installation.
Here, I have a simple and quick installation and can connect to the repository immediately after installation using a certificate (without entering a password for the first time). Secure backup!
But if I want to set up a repository with external disks, I have to install it myself manually (especially for big repos where the internal disks aren’t enough). I’m responsible for the setup myself. Maybe I have different installations, different defaults, different security settings…
With Object First, the installation is similar to the Hardened Repository managed by Veeam, except that the OS is already preinstalled on the appliance –> quick and easy, except that I still have to create the users and buckets. Install, switch on, run setup, create users, create buckets, connect buckets to Veeam, start backup. Secure backup!
The Object First Appliances are simple, secure, and easy to maintain, and each appliance is set up/installed/hardened in the same way.
Therefore, combining the two products simply makes sense to me and can round off a backup concept from a cyber resilience perspective.
In some environments/situations, it also makes sense to back up directly to the Object First Appliance and then copy the data again (e.g., to the cloud). I don’t dispute this, and it also depends on the workload. This would be conceivable, especially for backing up smaller remote locations.
However, I am simply a fan of the combination of the two technologies, Veeam Hardened Repository and Object First Appliance, as the advantages of both technologies are impressive.
Advantages and disadvantages of Veeam Hardened Repository
Veeam Hardened Repositories have become more and more popular in recent years and are now my first choice for Veeam storage.
However, they also have some disadvantages that need to be addressed openly and clearly.
I would like to list some of the advantages and disadvantages here, some of which can have serious consequences.
I have separated the advantages and disadvantages again depending on whether the repository was installed by the Veeam Hardened Repository/Infrastructure ISO (managed by Veeam) or installed manually on bring-your-own Linux server OS.
This removes some confusion or mixing of the respective advantages and disadvantages.
Advantages and disadvantages of Veeam Hardened Repository managed by Veeam (Veeam Hardened Repository/ Veeam Infrastructure Appliance ISO)
Advantages:
- Fast, easy, and secure installation with Veeam ISO –> The OS is secure!
- The hardened repository storage software stack natively and effectively protects backups against manipulation and deletion, even if Veeam or administrator credentials are compromised. Immutability provided by hardened repository meets the requirements for non-rewritable, non-erasable storage as specified by SEC 17a-4(f), FINRA 4511(c) and CFTC 1.31(c)-(d) regulation
- Communication with the repository is only possible via Veeam proprietary protocols. This makes the repository even more secure than if it could be accessed via other protocols.
- Hardening according to DISA STIG (Set by default during every installation and cannot be deactivated. This ensures a high standard of security.)
- Any Red Hat-certified hardware can be used, allowing maximum flexibility in hardware selection (Veeam JeOS ISOs are Rocky-based)
- The XFS file system enables block cloning and native disk space savings, offering high efficiency
- Free choice of hard drive type (SSD/HDD/NMVE) and free scaling
- Veeam support of the entire hardened repository stack including Veeam JeOS
- Immutability is enabled by default.
- No need to dedicate staffing resources to monitor and manage software updates –> Updates are now managed by Veeam
- You can’t really break anything
- Penetration tests are continuously performed by external companies.
Disadvantages:
- With a hardened repository, the ILO/iDRAC must be protected as best as possible (complex passwords, separate networks, etc.). If an attacker gains access to the server’s ILO, they can delete the RAID via the RAID controller, install other things, etc.
Ideally, the ILO/iDRAC should be disconnected from the server, but this means that no information about failed hardware (e.g., hard disks) is available and the hardware cannot be monitored.
Except for Fujitsu servers, no MFA for ILO via OTP. - No monitoring from the OS, only via ILO/iDRAC –> Veeam is working on this, but currently it’s a black box
- No hard drive expansion possible out of the box (only via live ISO)
- External disks (iSCSI/FC/SAS, etc.) are only possible with a self-built hardened repository
Advantages and disadvantages of self-installed/manually installed hardened repository (not from Veeam ISO):
Advantages:
- The hardened repository storage stack natively and effectively protects backups against manipulation and deletion, even if Veeam or administrator credentials are compromised
- Communication with the repository is only possible via Veeam proprietary protocols . This makes the repository even more secure than if it could be accessed via other protocols.
- Hardening according to DISA STIG (Must be selected manually during installation, but can be implemented. This means the same standards as for Managed by Veeam ISO)
- Any from Veeam supported Linux operating system can be used (it should also have security policies integrated). Accordingly, any OS supported hardware can be used, allowing maximum flexibility in hardware selection
- The XFS file system enables block cloning and native disk space savings, offering high efficiency (
- Free choice of hard drive type (SSD/HDD/NMVE) and free scaling
- Immutability enabled after partitions are correctly written with XFS
- It is possible to increase and add storage space (however, this cannot be done with a click of the mouse).
- External disks (iSCSI/FC/SAS, etc.) are possible
Disadvantages:
- With a hardened repository, the ILO/iDRAC must be protected as best as possible (complex passwords, separate networks, etc.). If an attacker gains access to the server’s ILO, they can delete the RAID via the RAID controller, install other things, etc.
Ideally, the ILO/iDRAC should be disconnected from the server, but this means that no information about failed hardware (e.g., hard disks) is available and the hardware cannot be monitored.
Except for Fujitsu servers, no MFA for ILO via OTP. - No regular penetration tests are performed as standard. Only if you do them yourself in your company.
- No Veeam support for the OS, as it was installed manually
- Updates are your own responsibility
- Administration and maintenance effort is higher, as Linux knowledge and ongoing system maintenance are required
- Incorrect or insecure configurations put immutability and security at risk – do-it-yourself carries risks (root user, SSH enabled, etc.)
- Monitoring via Redfish and co is possible, but must be built yourself
- Ultimately, the repository is only as secure as you make it.
Advantages and disadvantages of Object First Appliance
As you can see from the above, Object First appliances also have advantages and disadvantages.
However, I believe that the biggest advantage is clearly security!
Advantages:
- Out-of-the-box immutable – setup and operation are extremely simple and can be used by administrators even without storage or Linux know-how
- Includes built-in telemetry, zero-trust principles, and proactive monitoring for maximum security without complex proprietary monitoring
- No ILO necessary, as internal monitoring of the hardware
- Scalability through the combination of different sized models – suitable for both edge scenarios and central environments
- No need to dedicate staffing resources to monitor and manage software updates
- Well suited for companies that want as little effort and risk as possible in their operations
- You can’t really break anything
- SOSAPI interface (Smart Object Storage API is a special interface that allows Veeam to interact more “intelligently” with S3-compatible object storage)
- Penetration tests are continuously performed by external companies.
- Blocks are locked with Object Lock directly during writing (native immutability via S3 Object Lock. Versioning, compliance mode, access control, and encryption comply with HIPAA and ISO 27001 data security standards).
- Object First and Veeam Support work very well together. If you ever have a problem, the two support teams will talk to each other or can also open tickets with each other.
- Next business day on-site service for faulty hardware (in some remote areas, this is on a ‘best efforts’ basis or a spare part kit is required)
Disadvantages:
- Hardware dependency and limited flexibility – extensions/upgrades only possible on a per-appliance basis
- Largest appliance only has 432 TB; if more storage is required, additional appliances must be purchased and set up as a cluster (up to 1.7 PB, SOBR,…)
- Currently only HDDs
- Not as much space savings as Hardened Repo (with block cloning and XFS) with V12, but much better with V13 thanks to adjustments made by Veeam.
- With Veeam V12, it is not possible to write to the appliance with all workloads (Enterprise Plugins); with Veeam V13, this is now possible
Conclusion
I hope that my blog post has highlighted the advantages and disadvantages of hardened repositories and object-first appliances, and why combining the two technologies is a really good approach for SMEs and SMBs.
This is not intended to be a bashing of any of the products, rather it is meant to show how well the products can be combined with each other.
Combining both approaches offers the benefits of maximum immutability, high operational reliability and flexibility, as well as the best possible resilience against cyberattacks and operating errors.
Edit 30.12.2025:
Due to the improved differentiation between the individual installation types (Veeam ISO/Manual), I have separated the advantages and disadvantages and made some adjustments in the post.
Thanks to Anton for taking the time to give me feedback!
Original Post on my Blog: Why a Veeam Hardened Repo and Object First Appliance is a great combination - petersvirtualworld.de
