After vacations, it’s time to start writing some blog posts, and today I will begin updating some of the features from Object First(Ootbi) and Veeam.
Suppose you need a primer on Ootbi (Out-of-the-Box Immutability) architecture. Why object storage fits backups, and immutability basics, read this first: Object First Ootbi: The Ultimate On-Premises Backup Storage Appliance for Veeam, and also my latest about Veeam Backup & Replication v12.3: What’s New. These articles focus on what changed, how to configure it right, and where it pays off in 2025.
Note: Veeam will launch Veeam Data Platform v13 in Q3. This release will update several existing capabilities and introduce new features focused on Immutable Backups and Fast Recovery. In the coming days, I will publish a dedicated article detailing these changes and providing guidance for adoption.
What Changed (and Why You Should Care)
Veeam Data Platform 12.3. Instant Recovery now scales up to 1,000 VMs per backup server and 200 VMs per vPowerNFS server. That means you can land backups on object storage and still hit tight RTOs. Veeam Threat Hunter adds built-in malware/IoC scanning in Scan Backup, Secure Restore, and SureBackup so you avoid “restore and reinfect” during incidents. Veeam Data Cloud Vault gives you an immutable, logically air-gapped off-site tier with flat per-TB pricing that includes API and egress.
Object First Ootbi. The portfolio now spans 20 TB and 40 TB edge units up to a 432 TB enterprise model. A 4-node cluster scales to about 1.7 PB, and the 432 TB line can ingest up to 8 GB/s. New hardware/firmware brings roughly 10–20% faster backup/restore. Net: it is easier to land backups directly on an immutable, on-prem object tier that is also fast to recover from.
Direct-to-Object on Ootbi as Your Primary Landing Zone
Direct-to-object used to be “great demo, risky RTO.” With Veeam 12+ and Ootbi, it is a production pattern. Veeam writes per-machine chains to object storage (higher concurrency, easier mobility). In 12.3, S3-compatible repositories support multiple-bucket mode: Veeam can auto-provision child buckets and spread chains. Mapping metadata lives in a master bucket, so the system always knows where a chain lives. This keeps buckets from ballooning and preserves performance at scale.
Plan the layout before first writing. If your S3-compatible repo uses SOSAPI load-balancing at a “smart-entity” level, multi-bucket is not supported. Also, once you enable multiple buckets, you cannot revert to a single bucket. Decide early and document it.
Recover fast by sizing the path. Treat this like what it is—object I/O plus an Instant Recovery write cache. Place the mount server close to hosts, size the IR write cache for your parallel IR goals, and consider redirected writes to fast datastores during IR. With 12.3’s IR scale, mount placement and cache sizing are table-stakes.
Threat-Aware Restores with Veeam Threat Hunter
Fast restores are useless if they reintroduce malware. Threat Hunter is built into Veeam and plugs into three touch-points:
- Scan Backup to identify the last known good restore point before you touch production.
- Secure Restore to scan disks during Instant Recovery; if Threat Hunter flags activity, you can halt or quarantine before the VM completes boot.
- SureBackup to make verification jobs boot + clean, not just “it powers on.”
Threat Hunter runs on the mount server. Give it CPU and disk to match your IR ambitions and avoid AV conflicts on that host (or add exclusions). It will not replace EDR in production; it seals the restore boundary.
Off-site Copies with Veeam Data Cloud Vault
You still need off-site for 3-2-1-1-0. Veeam Data Cloud Vault is Veeam-managed Azure object presented as a first-class repo: immutable by default, logically air-gapped, and billed at flat per-TB pricing (storage + API + egress). In practice, add Vault as Capacity/Archive Tier in a SOBR with Ootbi as Performance Tier, enable copy mode, and you get predictable off-site without lifecycle/lock booby traps. Keep Ootbi as the local fast-path for IR; use Vault for resilience and long-term retention.
Use Case 1: Ransomware-Resilient Mid-Enterprise
Goal: Restore fast and clean, even if production is compromised.
Design: Land direct-to-object on Ootbi with immutability enabled in the Veeam repo. Build a SOBR with Ootbi as Performance Tier and Veeam Data Cloud Vault as Capacity/Archive in copy mode. On the bucket, enable Versioning + Object Lock but do not set bucket-level default retention or lifecycle—Veeam must control per-object locks. Start with 14–30 days immutability and align job retention with lock windows.
Runbook: Patch to 12.3.x. Place the mount server near hypervisors and size the IR cache for expected concurrency. During an incident, run Scan Backup to locate clean points, then use Secure Restore for IR. Quarterly, run SureBackup jobs that include Threat Hunter to validate “boot + clean.”
Why it works: You get hours-level service recovery from Ootbi and predictable off-site immutability with Vault. A 10 TiB cloud pull over 1 Gbps is roughly a full day; keep cloud for resilience, not your only RTO path.
Use Case 2: Edge / ROBO with Thin IT
Goal: Give branches reliable, immutable backups and a local IR safety net without heavy ops.
Design: Use a 20–40 TB Ootbi per site as the primary direct-to-object target (immutability on), and SOBR-copy to Vault in your central region. Schedule frequent incrementals and consolidate after hours; seed initial fulls centrally for weak links. Keep per-machine chains so you can move machines and jobs independently as sites evolve.
Operations: Standardize a policy pack (bucket prefixes, retention/immutability defaults, encryption, concurrency limits, IR test cadence). Monitor via Veeam (SOSAPI exposure) and run remote SureBackup + Threat Hunter each quarter across representative branch workloads.
Why it works: Branches get fast local restores without managing DIY NAS or OS hardening; off-site copies land in a managed, immutable service with flat pricing.
Use Case 3: Long-Term Compliance Retention
Goal: Keep data immutable for more than 90 days (sometimes years) without breaking operations.
Design: Ootbi remains the primary immutable repo; Vault (or another compliant object) holds long-term copies. The UI cap for object-repo immutability is 90 days; use PowerShell to set longer periods (for example, up to 999 days for S3-compatible). Avoid bucket-level default retention and lifecycle policies—Veeam must set locks per object. Understand Block Generation (Veeam may add extra days to reduce churn), then align immutability, job retention, and legal requirements. You can extend a lock; you cannot shorten it with compliance-mode semantics.
Why it works: Predictable legal behavior (locks where they belong) and smooth operations (no stuck deletes), plus an off-site copy with no egress/API bill shock.
Things to Avoid (with “Why” and “Fix”)
1) Bucket-level default retention or lifecycle rules
Why: They fight Veeam’s per-object immutability and can cause add/import failures or undeletable objects.
Fix: Enable Versioning + Object Lock on the bucket, leave default retention off, and avoid lifecycle rules. Manage immutability only from Veeam (repo settings/PowerShell).
2) Misplacing the mount server or under-sizing the IR write cache
Why: With IR scaling into hundreds of VMs, latency through the mount server becomes your bottleneck; a tiny cache stalls many IRs.
Fix: Put the mount server next to your ESXi hosts, give it a fast local disk for the IR cache, and consider redirected writes to performant datastores during IR.
3) Enabling multi-bucket on the wrong storage
Why: Multi-bucket is powerful, but not supported when the vendor’s SOSAPI uses smart-entity load balancing. Once enabled, you cannot revert to single-bucket.
Fix: Check your vendor’s SOSAPI behavior; if smart-entity LB is enabled, keep single-bucket. Decide before the first write.
4) Designing RTOs around cloud-only restores
Why: WAN is physics—large pulls take hours to days, even at 1–2 Gbps.
Fix: Keep Ootbi as the local performance tier for Instant Recovery; use Vault for immutable off-site and predictable cost. Validate with a full IR drill, not just file-level restores.
Configuration Quick-Start
Create the repository correctly.
- Create an Ootbi bucket with Versioning + Object Lock; do not set default retention or lifecycle.
- In Veeam, add S3-compatible object storage, pick the bucket, and enable immutability in the repo. For new repos, multiple-bucket provisioning is available—leave defaults unless your storage’s SOSAPI disallows it.
Build the SOBR and off-site.
- Performance Tier: Ootbi
- Capacity/Archive Tier: Veeam Data Cloud Vault with copy mode for 3-2-1-1-0 and predictable costs
Set immutability > 90 days (when required)
1 2 3 4 5 6 7 | # Raise immutability beyond the 90-day UI cap (S3-compatible) $repo = Get-VBRObjectStorageRepository -Name "Ootbi-Primary" Set-VBRAmazonS3CompatibleRepository -Repository $repo ` -EnableBackupImmutability -ImmutabilityPeriod 180 |
My Analysis & Final Considerations
This integrated design marks a real turning point. We’re moving away from fragile, DIY multi-vendor stacks toward an integrated approach that addresses the twin challenges of ransomware and operational complexity. It makes robust data protection practical and repeatable.
However, powerful tools require discipline. Before you deploy, keep these three principles in mind:
- The technology empowers; you strategize. Object First provides the hardened, immutable foundation, but your Veeam configuration—SOBR policies, mount-server placement, and retention/immutability settings—turns capability into outcomes.
- Recovery is a discipline, not a feature. Bake Threat Hunter into incident response (Scan Backup, Secure Restore, SureBackup) and run regular, automated recovery drills. An untested backup is a liability.
- Don’t neglect the network. This design is high-throughput. Size proxy-to-object paths, place the mount server close to the compute, and avoid WAN-only recovery paths for large restores.
Conclusion
The combination of Object First and the Veeam Data Platform moves data protection from theory to operational reality. It’s not just about having immutable backups; it’s about engineering fast, clean, and predictable recovery.
The blueprint is straightforward: use the on-prem Ootbi appliance as your high-performance, immutable landing zone for daily operations and Instant Recovery. Use Veeam Data Cloud Vault for resilient off-site copies and long-term retention with predictable costs.
Success hinges on two commitments: deliberate Veeam configuration (policies and resource placement) and a rigorous, automated testing schedule. An untested backup is just a hope—integrating Threat Hunter into scheduled drills turns that hope into confidence.
This is how you stop merely storing data and start safeguarding the business.
Share this article if you think it is worth sharing. If you have any questions or comments, comment here, or contact me on Twitter(yes, for me, it’s not X but still Twitter).
©2025 ProVirtualzone. All Rights Reserved
Leave A Comment