Every year, more companies migrate their backup architecture to object storage. The promise is well-known: scalability, predictable cost, and an extra layer of resilience against ransomware. But with so many providers available, one of them has been gaining significant traction — Wasabi Hot Cloud Storage.
Wasabi's value proposition is refreshingly simple: S3-compatible storage, high performance, no cold tiers, predictable pricing, and full support for Object Lock, enabling true immutable backups.
In this article, I share the full experience of building a protection scenario using Veeam Agent Standalone + Wasabi, walking through:
- creating a bucket
- configuring permissions
- integrating Veeam with Wasabi
- running the first backup
- validating immutability
- restoring a full machine into a hypervisor
- performing granular file-level recovery
And I’d like to leave a special thanks to the Wasabi team, who generously provided a trial environment that made all these tests, and ultimately this article, possible.
Why Wasabi is Becoming a Strong Choice for Backup Workloads
Before diving into the configuration, it’s worth explaining why Wasabi has become such a compelling option for backup repositories.
Unlike many cloud providers, Wasabi does not work with cold tiers or Glacier-like layers. All data is stored in hot storage by default, meaning low latency, fast access, and consistent performance at all times, without additional retrieval fees.
The pricing model is another standout: simple, flat and predictable. For environments running thousands of Veeam jobs generating millions of objects, this matters more than people often realize. But perhaps the most important advantage for Veeam users is Wasabi’s full support for S3 Object Lock, which allows the creation of immutable repositories, a foundational layer in modern ransomware defense, preventing attackers (or even administrators) from deleting backups before their retention period.
Creating the Bucket: Building a Secure Foundation
When you log into the Wasabi Console to create the bucket that will store your Veeam backups, it’s easy to think of this as a simple, one-minute task. But this step carries several decisions that directly affect security, performance, and the long-term structure of your backup environment.
The first element is the bucket name. A clear and consistent naming convention helps tremendously as your environment grows. Naming buckets by region and purpose, for example, “us-east-1-veeam-prod-backup”, makes the architecture easier to understand, especially in multi-region or multi-tenant scenarios.
Selecting the Best Wasabi Region
Next comes the region selection. Wasabi offers several global regions, and the one you choose determines both the physical location of your data and the latency between Veeam and the storage platform. Selecting a region close to your backup server usually results in faster backup windows and more responsive restores. Organizations with compliance requirements may also need to store data in a specific geographic location. If you intend to use bucket replication later, your region layout becomes part of your disaster recovery design.
Creating Bucket
Then we arrive at the most crucial setting: Object Lock. This option defines whether the bucket can support immutability, and it must be enabled during creation, there is no way to turn it on afterward. Once enabled, Wasabi allows the use of retention periods and legal holds, both essential for Veeam’s ransomware-resistant backup strategy. Retention prevents deletion or modification for a defined period, while legal holds freeze objects indefinitely until manually removed. Object Lock is available in both Governance and Compliance mode, allowing flexibility depending on lab or production needs.
While creating the bucket, Wasabi also offers optional but powerful features such as tags, versioning, bucket logging, and replication. Tags help classify buckets by environment or purpose, which is helpful for automation and reporting. Versioning preserves previous copies of objects, adding an additional layer of safety against accidental overwrites. Bucket logging records access information and can be integrated with SIEM tools for auditing and forensic analysis. And if your disaster recovery strategy includes multiple regions, replication can automatically copy your data to another bucket in a different location. When using replication with immutable data, the destination bucket must also have Object Lock enabled to maintain the same level of protection.
By the time the bucket is created, you have essentially defined the storage foundation for your entire backup architecture. With Object Lock active, versioning and logging available
Permissions and Policy: Securing Access the Right Way
Next, we create a dedicated user for Veeam.
Wasabi follows the same permission model as AWS IAM, meaning you generate:
- a user
- an Access Key and Secret Key
- a policy defining what that user can do
A common mistake is granting unnecessary administrative privileges. The Veeam Agent only needs access to a specific bucket and its objects, nothing more.
Even though this policy includes DeleteObject, keep in mind:
immutability overrides permissions. If the bucket has Object Lock enabled, objects simply cannot be deleted before the retention period, not even by a root admin.
Connecting Veeam Agent to Wasabi (Job Creation + Configuration)
With the Wasabi bucket ready, we now move to the Veeam side. The goal is to create a new backup job in Veeam Agent for Microsoft Windows (Standalone) and point it directly to Wasabi as an S3-compatible object repository.
This architecture is clean, cloud-native and enables direct backing up into immutable object storage — without requiring a full Veeam Backup & Replication server.
Creating the Backup Job
Open Veeam Agent and start by creating a new job. Using a clear naming convention helps when managing multiple devices or retention strategies.
Job Name
Enter a descriptive name for the backup job.
Here, the backup job is named BKP_TechDirectArchive, allowing quick identification.
Choosing the Backup Mode
Next, Veeam asks what you want to protect. For a full system recovery or restore into a hypervisor, choose Entire computer (recommended).
This creates an image-level backup, allowing Bare Metal Restore and P2V migration.
“Entire computer” produces a full system image, ideal for DR, migrations and cloud recovery.
Choosing the Destination
Now select where the backup will be stored.
To use Wasabi, choose Object storage instead of local disks or SMB shares.
Object storage streams data directly to the cloud bucket.
Selecting S3-Compatible Storage
Wasabi is fully compatible with the Amazon S3 API, so select S3 Compatible and next.
Veeam supports Amazon S3, Azure, Google Cloud and S3-compatible providers like Wasabi.
Configuring the Endpoint and Credentials
Now configure Wasabi’s regional endpoint.
Use the endpoint matching your bucket region:
https://s3.<region>.wasabisys.comEnter the Access Key and Secret Key for the Wasabi user you created with minimal access.
The Agent authenticates using S3 API, no plugins required.
Selecting the Bucket and Folder
After login, Veeam displays your buckets.
Choose the bucket created for the job:
Inside the bucket, you can select an existing folder or create a new one to organize restore points.
Folders help separate multiple machines under the same bucket.
Retention and Immutability
Now define how long Veeam should keep restore points and enable immutability if supported.
Because the bucket has S3 Object Lock enabled, Veeam detects it and allows backups to be immutable, preventing deletion or modification during the retention period — even by administrators.
Immutability is critical for ransomware protection.
This protection layer prevents malicious removal of backups, ensuring you always have a valid restore point.
Schedule
Finally, configure the schedule.
Daily backups during low usage hours are common for servers.
!-->
Choose frequency, sleep behavior and triggers.
Review Summary
Before finishing, Veeam shows a full summary including bucket, endpoint, retention and immutability settings.
Confirm settings and click Finish.
Running the First Backup: End-to-End Validation
With everything connected, run the first backup.
One of the most noticeable advantages of Wasabi's architecture is its performance consistency and because everything is stored in hot storage, the seeding process tends to be smoother and faster than providers that rely on cold tiers.
After the backup completes, verify two things:
In Veeam:
You should see restore points with a lock icon, confirming immutability.
In the Wasabi Console:
Browse any object in the bucket and check the retention metadata, if it’s active, immutability is functioning correctly.
This combination ensures that your data is protected against deletion, corruption or ransomware-driven attacks.
Restoring Backups from Wasabi Using Veeam Backup & Replication
Once the backup stored in Wasabi Object Storage is imported into Veeam Backup & Replication, the restore workflows become fully available from the VBR Console — including Instant VM Recovery, Full VM Restore, Quick Migration and Granular File-Level Recovery.
This model turns a cloud-native backup into a portable recovery format, capable of being restored into any hypervisor or cloud environment supported by Veeam, without requiring a local repository or re-seeding the full data set.
Importing the Wasabi Repository into VBR
Before performing the restore, the Wasabi bucket is registered as an Object Storage Repository inside the Backup Infrastructure section of VBR.
This allows Veeam to:
- browse the existing bucket and folders
- detect previous restore points
- index guest files
- expose jobs inside the console
- enable full recovery workflows
Selecting S3-Compatible Provider
Veeam recognizes Wasabi using the standard S3 API, allowing native integration with Object Lock enabled.
Select:
- S3 Compatible
Connecting to the Wasabi Bucket
Provide the endpoint matching the region and the credentials created earlier:
Endpoint format:
https://s3.<region>.wasabisys.com
Selecting the Existing Bucket & Folder
After authentication, Veeam lists all buckets visible to the IAM user.
Select the same bucket used in the standalone backup, and the folder containing the restore points.
This is the point where Veeam recognizes previous backup data and exposes it to the VBR catalog.
Enabling Immutability Check and Import Mode
Inside the Bucket configuration, Veeam automatically reads Object Lock metadata and enables immutability for the entire retention period.
In this article, the repository was imported using:
- Make backups immutable
- Search repository for existing backups
- Import guest index data
These dual settings enable:
- backup discovery
- restore visibility inside VBR
- file-level indexing
without requiring a new job.
Imported Backup Visibility
With the Wasabi repository registered, the backup shows up inside Object Storage (Imported) under the Backups view:
- name of the job
- restore point count
- storage location (Wasabi)
- platform (Windows / Linux)
This confirms that the existing standalone backup is now fully cataloged inside VBR.
From this point, all restore options are available directly from VBR.
Instant VM Recovery
One of the most powerful features when restoring from Object Storage is that Veeam performs Instant VM Recovery streaming directly from Wasabi, mounting the backup into the hypervisor using the vPower NFS layer.
This enables:
- zero waiting time
- no full local restore
- booting directly from cloud backup
- live migration after startup
In the example below, a physical server backup stored in Wasabi was instantly recovered into a VMware vSphere host, fully operational in minutes.
Once the VM boots, Veeam performs a Quick Migration to move the VM disks from the temporary vPower mount into the final datastore using native Storage vMotion or Veeam I/O transport, depending on the environment.
This process converts a physical machine into a virtual one without complex migration tools.
Detailed Restore Session Logs
The detailed log below shows each stage of the Instant Recovery pipeline:
- publishing the VM
- snapshot creation
- P2V conversion
- VM registration
- dismount
- migration phase
The entire restore process was completed directly from Wasabi, confirming the efficiency of object storage for production-grade disaster recovery.
Beyond full VM restore, the VBR Console provides Granular Restore from the same object storage repository.
When performing File-Level Recovery, Veeam mounts the restore point remotely and downloads only the data blocks required for the requested files.
This approach:
- reduces egress
- accelerates restore time
- avoids local full copies
- preserves the immutability chain
In practice, recovering a file from Wasabi feels almost like restoring from a local repository.
Immutability Proof & Storage-Layer Security
To demonstrate that Object Lock is active and effective, Veeam was asked to delete the restore point before the retention date. The system immediately refused the operation:
Error: Unable to delete the backup because it is marked as immutable until…
This confirms that immutability overrides permissions, including administrative delete rights — a critical layer of protection against ransomware, malicious insiders, or accidental cleanup.
Summary of the End-to-End Workflow
The complete workflow shows a lightweight, cloud-first backup and restore strategy:
- Backup from Veeam Agent to Wasabi using S3 Object Lock
- Repository imported into Veeam Backup & Replication
- Backup becomes visible without re-seeding
- Instant VM Recovery directly from object storage
- Quick Migration finalizes the recovery into datastore
- Immutability protects the restore point at the storage layer
- Full and File-Level Recovery use the same data
This delivers a high-confidence recovery chain, combining:
- Wasabi (immutability + hot storage)
- Veeam (orchestration + restore logic)
Together, they provide fast RTO, strong ransomware resilience, and predictable cloud economics.
Conclusion
This hands-on scenario shows how Veeam + Wasabi delivers a modern, cloud-first, immutable backup architecture with:
- simple configuration
- fast restore performance
- ransomware-proof retention
- flexible DR options
- no re-uploading when importing into VBR
Restoring a physical backup directly into VMware — streamed from immutable Wasabi Object Storage — demonstrates the real power of combining a performant S3 provider with Veeam’s recovery engine.
A special thank-you to Wasabi for providing the trial environment used in this walkthrough.
