Summary

  • Wasabi's simple price is real but conditional. From July 2026, public Pay-Go storage is $7.99 per TB per month, with a one-terabyte monthly minimum, no separate API or ingress charge, and free egress for use that stays within the company's reasonable-use guideline. Pay-Go objects deleted before 90 days continue to incur storage charges for the remaining period, so logical backup size can be a poor forecast of the invoice when data changes quickly.
  • The storage service is only one layer of a recovery. Wasabi preserves and serves objects; backup software decides chunking, catalogues, retention, encryption, health checks and restore order; the customer supplies credentials, network capacity, clean compute, application knowledge and operators. A green upload and an immutable bucket do not prove that an application can be rebuilt within its recovery objective.
  • Object Lock can materially reduce deletion risk, but its modes and defaults require care. It must be enabled when a bucket is created, versioning then cannot be disabled, Governance retention can be bypassed by a sufficiently privileged identity, and Compliance retention cannot. Partner software must set compatible per-object retention. A mistaken period can preserve obsolete versions and costs just as effectively as it preserves good backups.
  • Wasabi documents 11-nines designed annual object durability and 99.9% availability for one region, rising to 99.99% when data is stored across two regions. Those are not recovery results. A disclosed 2024 incident in us-central-1 left some objects inaccessible after a hardware and software interaction, making independent copies, object verification, region failure drills and explicit restore tests economically relevant rather than ceremonial.
  • The right procurement measure is cost per accepted recovery. Buyers should test a representative file restore, a database or application restore, a bare-system rebuild and a regional-loss scenario; record human minutes, transferred bytes, catalogue dependencies, integrity failures and elapsed time; then compare the complete result with another cloud object store, managed backup service, second-region copy, local immutable appliance or tape.

The product is cheap storage; the outcome is a recovered service

At 02:10 on a Monday, a ransomware response team decides that the production identity system cannot be trusted. The most recent backup job is green. Its objects are present in an immutable cloud bucket. The backup console can list restore points. None of those facts answers the question facing the incident commander: can the team reconstruct a clean identity service, with its database, configuration, keys and dependent name services, before staff arrive?

The first attempt discovers that the backup catalogue was kept only on the compromised management server. The second reaches the cloud but saturates a one-gigabit internet circuit shared with ordinary traffic. The third restores files, yet the application rejects them because transaction logs and the database snapshot do not meet at a consistent point. An operator then has to locate a clean recovery host, retrieve a separate encryption key, rebuild catalogue metadata, select a pre-compromise point and verify that privileged accounts were not restored in a hostile state. The objects may be intact throughout. The recovery can still miss its deadline.

That distinction is the proper frame for Wasabi Technologies and its main product, Wasabi Hot Cloud Storage. Wasabi supplies cloud object storage with an S3-compatible interface. It is widely used as a destination for products such as Veeam, Commvault, MSP360 and other backup or data-management systems. The economic proposition is deliberately simpler than the menus of the large general-purpose clouds: one hot tier and, for normal storage-oriented use, no separate charge for API requests, data ingress or egress.

The simplicity has value. An administrator need not decide whether a restore point belongs in standard, infrequent-access or archive storage, estimate request charges for every health check, or hesitate before a recovery because downloading data creates a large metered bill. But removing line items from the storage invoice does not remove the work around storage. The backup product still has to package data into objects, retain a usable catalogue, manage consistency, verify restore points and orchestrate a restore. The customer still has to protect credentials, monitor failures, buy network capacity, maintain clean recovery infrastructure and exercise the procedure.

The useful denominator is therefore an accepted recovery: the required data and service are restored to a clean target by the agreed recovery time, no more data is lost than the recovery-point objective permits, integrity and application checks pass, and the result does not depend on an undocumented expert improvisation. Cost per accepted recovery includes every storage charge, partner licence, reserved commitment, duplicate copy, network circuit, appliance, operator hour, failed attempt and migration task needed to achieve that result.

Measured this way, Wasabi can be an economical component of a strong design. It is not, by itself, the design.

The company and service boundaries matter

The Wasabi name covers a private Boston-based storage company, a product brand, a network of regional storage endpoints and an expanding portfolio. Wasabi's company page says the business was founded by Carbonite co-founders David Friend and Jeff Flowers and gives a Boston headquarters at 75 Arlington Street. Current public records also require care with legal naming. A Florida corporate record identifies an active Delaware-organised Wasabi Technologies LLC, lists the same Boston address and names Wasabi Holding, Inc. as its member. Older material and the commissioned company name use Wasabi Technologies Inc. A buyer should use the exact contracting entity in its order form rather than assume every occurrence of the brand denotes the same corporation.

The product boundary is equally important. Hot Cloud Storage is object storage. It is not a complete backup application, a hypervisor, a clean-room recovery site or a managed incident-response service. Wasabi Account Control Manager helps providers administer multiple accounts. Wasabi Cloud Sync Manager can move data. Wasabi Ball is a transfer appliance. Newer products and the 2026 acquisition of Seagate's Lyve Cloud business widen the corporate portfolio. They do not silently become part of every Hot Cloud Storage subscription.

The Lyve Cloud acquisition announcement says Seagate received equity in Wasabi and that the acquired business brings customers and partner relationships. It does not establish that a current Wasabi bucket and a legacy Lyve Cloud bucket share a control plane, service commitment or migration path. Procurement should ask which service, region, support plan and legal terms apply to the actual workload.

That separation prevents a common attribution error. If Veeam creates an application-consistent restore point, Wasabi stores its objects but did not create the consistency mechanism. If a restore fails because the Veeam catalogue is unavailable, the object store may be healthy. If Wasabi returns an object error, the backup application's retry and reporting behaviour affects what the operator sees. If an MSP sells the combined service, first-line support, monitoring and pricing may belong to the MSP. Product value and failure responsibility cross several contracts.

What the hot, S3-compatible offer actually provides

Object storage presents buckets and objects rather than a conventional disk or file-system volume. Applications upload objects with keys, retrieve them through API calls and may attach metadata, versions and retention controls. Wasabi publishes region-specific S3 endpoints across North America, Europe and Asia-Pacific. Its storage-region page lets a customer select where a bucket is created, while its service-URL reference explains that third-party applications vary in how quickly they support new endpoints.

This architecture is attractive for backup because capacity can expand without the customer buying another local disk shelf. S3 has also become a widely supported target interface. Veeam's current documentation, for example, includes a specific workflow for adding Wasabi Cloud Object Storage and supports Wasabi as a target for backup and backup-copy jobs.

Compatibility should still be treated as a tested contract, not a brand adjective. Wasabi's S3 API reference says the service is bit-compatible with AWS S3 and IAM APIs, then directs readers to documented variations. The variations are operationally material. Wasabi provides one storage class and does not implement AWS KMS functionality, S3 Select, S3 Batch Operations, bucket acceleration, CloudWatch bucket metrics, website configuration or AWS's central S3 Block Public Access API, among other operations listed in its bucket-operation reference and object-operation reference.

Many backup products need none of those features. The point is not that Wasabi lacks an expected backup primitive. It is that “S3-compatible” does not guarantee that any application which works with AWS will work unchanged. Wasabi itself maintains a list of applications known not to work, often because the application hard-codes an AWS endpoint. A region added by Wasabi may require a partner update before it appears in a fixed selection list. Policies copied from AWS may contain identifiers that have to be changed. A client may handle an error or retry differently from another client.

The practical acceptance test is narrow and versioned: the exact backup-product build, gateway, endpoint, authentication method, bucket settings, object-lock mode and restore operation that the customer intends to run. A successful upload with a generic command-line client proves basic object access. It does not prove that a backup vendor's catalogue, synthetic full, health check, retention cleanup or instant-recovery path behaves correctly.

Three systems have to agree before a restore works

A useful recovery model separates three layers.

The object layer is Wasabi's responsibility. It authenticates permitted API calls, stores object data and metadata, encrypts objects at rest, serves them from the selected region, enforces configured retention, repairs infrastructure failures and exposes the service endpoint. Wasabi's shared-responsibility model assigns core infrastructure, hardware, data centres and service-side durability to the provider.

The backup layer normally belongs to another vendor or an MSP. It discovers source data, takes snapshots, coordinates databases, divides data into chunks, deduplicates or compresses it, uploads objects, writes a catalogue, chooses retention, expires old restore points, runs health checks and reconstructs data. It may keep active metadata on a local cache repository even when backup data is immutable in object storage. Its licence, configuration and version lifecycle are part of the recovery system.

The recovery layer belongs largely to the customer. It includes clean compute, hypervisor or cloud capacity, operating-system images, directory services, DNS, network routes, credentials, encryption keys, application installers, licences, runbooks, data owners and people authorised to decide which point is clean. It also includes the connection from Wasabi to the recovery target. Restoring 100 TB to an empty data centre is not the same task as retrieving one deleted spreadsheet.

These layers can fail independently. They can also produce misleading partial success. An object-store health page can be green while a customer's expired access key prevents a job. A backup console can report success while an application snapshot is inconsistent. A complete file restore can still be unacceptable if it takes five days against a four-hour objective. An immutable copy can be faithfully preserved yet unusable because its encryption key was lost. A second-region replica can contain the same corrupt source object.

Supervision is the work of reconciling those states. Someone must review failed and unusually small jobs, capacity growth, deleted-storage charges, stale credentials, unprotected buckets, replication lag, catalogue backups and restore-test results. During an incident, someone must select a recovery point, establish a clean target, validate hashes or application records, sequence dependencies and authorise return to service. Wasabi can lower storage administration and transfer-price anxiety. It cannot remove this judgement.

The July 2026 price is simple, but simple is not flat

Wasabi's May 2026 price notice raised public Hot Cloud Storage Pay-Go pricing to $7.99 per TB per month in North America, Europe and Asia-Pacific from July 1, 2026. It says Reserved Capacity Storage prices are based on that rate with discounts for term and capacity. The product terms set out the more consequential rules:

  • Pay-Go has a one-terabyte monthly minimum and a 90-day minimum storage duration.
  • Pay-Go Commit uses a monthly storage commitment over one, three or five years and retains the 90-day duration rule.
  • Reserved Capacity Storage has a 25 TB minimum, one-, three- or five-year terms, and a 30-day minimum storage duration.
  • Standard reserved capacity can generate overage invoices; a capped variant can stop new uploads when purchased capacity is reached.
  • No separate egress charge applies while monthly egress is no greater than active storage, under the free-egress policy.

At list rate, a stable 100 TB stored for a full month has a headline storage cost of about $799 before tax, support, partner services, a second copy and the backup product. That multiplication is useful only when “100 TB” really represents billable storage and the data remains stable.

Backup workloads often do not. They overwrite chunks, synthesize new restore points, expire versions and abandon multipart uploads. Wasabi bills active storage by time and also bills timed deleted storage when an object is removed before its minimum duration. The minimum-duration documentation says a Pay-Go object deleted early is charged for the balance of 90 days. Deleting the bucket does not cancel the charge. Incomplete multipart-upload parts can also remain billable active storage for 31 days, according to Wasabi's multipart cleanup guidance.

This is not a hidden fee; it is a published storage rule. It is nonetheless easy to omit from a forecast built from a backup console's current logical capacity.

Consider a simplified cohort. A backup system writes 30 TB of unique objects during a month and deletes each object after 30 days. Under a 90-day Pay-Go minimum, each terabyte is billed for roughly three months of storage life even though it is active for one. At $7.99, the cohort's full minimum-duration cost is about $719.10: 30 TB multiplied by three months multiplied by $7.99. Once the workload reaches a steady rhythm, the account can carry charges corresponding to active data plus data already deleted but still within its charge period.

The example is a model, not a prediction of a real backup invoice. Deduplication, incremental design, object reuse, retention, calendar length and Wasabi's daily billing determine the real result. Its purpose is to show why the buyer needs object-level churn, not merely source-data change rate. A one-terabyte change in a virtual machine might rewrite far less than one terabyte of deduplicated objects, or it might force a backup design to create a much larger new full. The backup vendor should provide a representative object-creation and deletion trace; the customer should compare that trace with actual Wasabi invoice categories during a trial.

The one-terabyte account minimum matters at the other end. A small firm storing 200 GB does not pay one-fifth of $7.99; it pays the one-terabyte minimum. Wasabi's monthly-minimum explanation also says an account with no data continues to incur the minimum until the account is deleted, and that control-account sub-accounts can each qualify for a minimum. MSP account design therefore affects aggregate cost.

“No egress fee” removes a tariff, not a physical limit

Wasabi's egress proposition is economically significant. A customer can perform an ordinary restore without facing the per-gigabyte retrieval line item common in other clouds. This lowers the temptation to avoid tests because each test produces a transfer bill. It also makes a large recovery easier to budget.

The phrase still needs its policy boundary. Wasabi's pricing FAQ says a use case fits the free-egress policy when monthly egress is less than or equal to active storage. If egress regularly exceeds active storage, Wasabi reserves the right to limit or suspend service. A customer storing 100 TB can therefore download up to 100 TB in a billing cycle within the published guideline. A full 100 TB recovery plus another full-scale drill in the same month crosses it. The policy does not say the second transfer automatically receives a metered egress invoice; it says the workload is not a good fit and may be limited or suspended if the pattern is regular. A high-read media, analytics or distribution workload requires direct commercial clarification.

More importantly, free transfer is not instant transfer. A hard lower bound for moving data is:

restore time = data volume x 8 / usable link rate

At a perfect, uninterrupted one gigabit per second, 10 decimal terabytes require about 22.2 hours and 100 TB about 9.26 days. At 10 Gbps, 100 TB still requires about 22.2 hours. Real throughput is lower because of protocol overhead, contention, round trips, proxy capacity, object size, concurrency, source-region distance, destination writes and backup-software reconstruction. Small files and catalogue operations can make byte-rate arithmetic optimistic. A cloud restore into another provider may also incur network or compute charges at the destination even when Wasabi charges no egress.

This calculation does not measure Wasabi performance. It exposes the minimum network capacity required by the business objective. If a 100 TB service must be back in four hours, even flawless storage cannot make a one-gigabit circuit adequate. The design needs a local recent copy, much faster connectivity, staged critical-service recovery, an alternate cloud execution path or a smaller first recovery set.

Wasabi Ball can help seed or retrieve bulk data using an appliance, and direct connectivity may improve predictable transfer. Those are additional operational and commercial components, not properties of the base $7.99 rate. The buyer should time ordering, shipment, ingest or export, chain of custody and target import. An appliance that arrives after the recovery deadline is a migration tool, not the required recovery path.

Immutability is a precise control with expensive failure modes

Backups are targeted because attackers understand that destroying recovery copies increases leverage. S3 Object Lock is consequently one of Wasabi's most important controls. It can prevent an object version from being modified or deleted until a retention date, even if ordinary credentials are compromised.

Wasabi's Object Lock guide distinguishes two modes. In Governance mode, the root user or an identity with s3:BypassGovernanceRetention can bypass retention. In Compliance mode, no user can shorten the active retention before its date. A legal hold prevents deletion indefinitely until the hold is removed. Object Lock requires versioning, must be enabled when the bucket is created and cannot later be disabled for that bucket. Merely enabling the feature does not necessarily lock every object: the bucket needs a default or the uploading application must set object-level retention.

Wasabi also has a separate bucket-level Compliance feature. Its immutability comparison warns that the two mechanisms are mutually exclusive and that partner applications which use S3 Object Lock must support and specify its parameters. This is why backup-vendor instructions outrank a generic desire to “turn on everything.”

Veeam's current Wasabi settings guide, for example, exposes immutability through the repository configuration and explains that effective retention can include the backup retention period plus Veeam's block-generation period. Veeam separately warns in its agent immutability documentation that default bucket retention should be disabled for its S3-compatible design to avoid unpredictable behaviour and data loss. The backup application, not a generic bucket default, needs to control the intended object periods.

There are four ordinary misconfigurations to test.

First, Object Lock is enabled but no effective retention reaches uploaded objects. The bucket looks prepared, yet a credential with delete permission can remove unprotected versions. The test is to inspect retention metadata on newly uploaded backup objects and attempt an authorised deletion in a disposable test set.

Second, Governance bypass is granted too broadly. Immutability then protects against ordinary accounts but not the privileged identity an attacker seeks. Root credentials, console MFA, backup access keys and bypass permissions need separate ownership and alerting.

Third, retention is longer than the backup application's useful period. Obsolete chunks remain stored and charged. Capacity cleanup appears to fail because the object store is correctly enforcing the lock. Shortening Compliance retention is impossible for existing objects, so a careless value can create a long, unavoidable bill.

Fourth, retention is shorter than the recovery requirement. A 14-day lock does not protect the clean 30-day-old restore point needed after a slow compromise is discovered. The policy must reflect detection delay, legal retention and the time needed to notice a failed newer backup.

Immutability also does not prove cleanliness. Malware, encrypted source data or logical corruption can be backed up and then preserved immutably. The recovery process needs multiple points, anomaly detection and an application-level validation that identifies the last known-good state.

Credentials, catalogues and logs are part of the backup

Wasabi encrypts objects at rest, but access design determines who can read, overwrite or delete them. Its security best-practices guide tells customers not to use root access keys, to prefer scoped sub-users, rotate keys, use MFA for console access and enable bucket and administrative logging. The same guide notes that a password policy is not set by default and that bucket logging must be enabled separately for each bucket.

Those details create ongoing labour. Backup software often uses long-lived access and secret keys. Rotating a key means creating a replacement, updating every client, testing access, deactivating the old key and then deleting it. An operator who deletes first can stop backups. One who never deletes leaves a credential available for abuse. A managed provider with many customer sub-accounts needs evidence that each key maps to one bounded purpose and that departure or incident procedures can revoke it without losing emergency read access.

Logs require their own protection. If bucket access logs are written into a bucket controlled by the same compromised identity, an attacker may remove the evidence unless retention and permissions separate it. Logging every object request can also create many small objects and extra storage, even if there is no API-request fee. Alerting has to distinguish a scheduled health check from unusual bulk reads or delete attempts.

The backup catalogue is an even more direct dependency. Object keys created by a backup application may not be meaningful files. Deduplicated chunks can be useless without metadata that maps them to machines, volumes, restore points and encryption keys. The catalogue, configuration database and recovery password need a protected copy outside the failed management server. A rebuild procedure should begin with blank infrastructure and recover those control records before touching production data.

This is where “bring your own storage” can create an ambiguous support boundary. Wasabi can confirm whether an object exists or an API request failed. The backup vendor understands catalogue and chunk semantics. The MSP may hold the contract and credentials. During an incident, each can reasonably ask for evidence from another layer. A procurement should name one recovery owner, define escalation between vendors, preserve support access when the normal identity provider is down and require a joint exercise before acceptance.

A region is a failure domain, not a backup strategy

Wasabi says Hot Cloud Storage is designed for 99.999999999% annual object durability. It separately says system availability is 99.9% when data is kept in one region and 99.99% when it is stored across two. Durability describes the probability of preserving objects; availability describes the ability to serve requests. Neither says an application will be recoverable.

The distinction is visible in Wasabi's service terms. The published 2024 SLA reference calculates monthly availability from selected internal server errors for read, write and delete requests. It excludes customer systems, third-party technology, internet problems beyond the service boundary, maintenance and other listed conditions. Credits are 10% when availability is below 99.9% but at least 99.0%, and 25% below 99.0%, subject to claim procedures and caps. A credit helps reconcile a bill. It does not rebuild a server or compensate for missed business.

Wasabi's own history supplies a more concrete caution. Its status record for the August 30, 2024 us-central-1 incident said a storage-system I/O module became inoperable and software managing the disks improperly took other disks offline; some objects became inaccessible. A Veeam community discussion preserved the status statement and a customer's account of later support work. The public material does not disclose the total affected object count, customer population or a statistically complete durability rate. It does establish that inaccessible-object failure is not merely theoretical.

The fair conclusion is not that Wasabi cannot be used for backup. Every storage system has failure modes, and one incident does not measure current service quality. The conclusion is that an 11-nines design claim is not permission to keep the only recovery copy in one region under one administrative domain.

Wasabi now offers object replication between buckets. The documented service supports same-owner buckets with matching versioning status and can copy between regions within the same continent. It excludes several object classes, including objects encrypted with customer-provided keys and some objects created through compose, copy or move operations. Wasabi does not publish a completion-time estimate; duration depends on object count and replication-server load. For Object Lock buckets, the destination applies its own configured retention mode rather than inheriting the source object's mode.

Replication can improve availability and regional resilience. It also doubles or otherwise increases stored capacity, retention and monitoring. A live replica may copy an unwanted new version or deletion marker, depending on configuration. A failed replication job can create false confidence. Two buckets in one provider can share identity, billing and control dependencies. The strongest design for critical data often includes another administrative or technology boundary: a second provider, an offline copy, tape, or an isolated backup service. The UK National Cyber Security Centre advises organisations to make multiple copies using different solutions and locations and not rely on multiple copies in one cloud service.

Public customer evidence proves use, not a general restore rate

Wasabi has substantial evidence of real deployment. Veeam documents it as a supported storage type. Stanford University IT has offered Wasabi storage and explicitly tells users that the service does not include backup or data-transfer support, even while listing backup tools that can use it. A 2025 Brighton & Hove City Council award sought at least 600 TB of immutable off-site storage integrated with Veeam, 24/7 support and no additional ingress, egress or API cost. The three-year contract value was £90,009 through reseller Qnetix.

That award is useful commercial evidence because it identifies capacity, integration, support and term. Dividing £90,009 by 600 TB and 36 months gives about £4.17 per contracted TB-month. The result is not a universal Wasabi price: the notice may state minimum rather than average use, currency and tax differ, the reseller package matters, and the contract does not disclose every retention or overage term. It does show why large committed procurement can differ materially from public Pay-Go list price.

Vendor-selected cases give both positive and negative clues. Wasabi's Cutter Group story says the MSP uses Object Lock for customers and retrieved more than 50 TB without an added egress charge after a customer's local environment was damaged. The page also claims the data was restored to a new server “in minutes,” but does not provide exact volume restored within that interval, network rate, start and stop definitions, integrity checks or a contemporaneous customer record. It supports the existence of a named recovery and the value of no separate egress charge, not a reproducible 50 TB restore benchmark.

An alternative-provider case study describes a different outcome. Cal Poly Humboldt told Backblaze that its Wasabi-and-Veeam deployment generated confusing charges for deleted data under a 30-day reserved-capacity minimum, creating repeated investigation and capacity work before the university migrated. Backblaze is a competitor and selected the story to sell its own service, so it is not neutral. The named institution, described mechanism and alignment with Wasabi's published minimum-duration policy make it relevant as a deployment signal. It does not establish that every Wasabi invoice is surprising or that the alternative would be cheaper for another workload.

The absence of a public, independent distribution of restore outcomes remains important. There is no credible public denominator showing, across Wasabi customers, how many scheduled restores finish within objective, how often catalogues fail, what throughput distributions look like, how frequently objects are unrecoverable, or how much operator time a large recovery consumes. Vendor durability, support and customer claims should therefore inform a test plan, not replace it.

The supervision bill belongs in the comparison

Storage is often bought to reduce capital expense and routine handling. A fair total-cost model should credit Wasabi for avoiding disk procurement, local hardware replacement, tier-selection work and ordinary egress line items. It should then add back the labour that remains.

Before deployment, the customer has to classify data, select regions, model retention, configure accounts and keys, establish bucket policies, choose Object Lock behaviour, connect backup software, seed the first copy and test recovery. During operation, someone reviews job failures, storage growth, timed deleted storage, replication reports, key age, logs, support notices and restore drills. During change, someone validates backup-product upgrades, API behaviour, region support, retention effects and catalogue migration. At exit, someone must transfer data, verify the destination, preserve required versions and wait for minimum-duration or reserved commitments to expire.

A useful monthly cost equation is:

active storage + timed deleted storage + reserved unused capacity + second copies + backup licences + support + connectivity + supervision + expected recovery loss + exit work

The expected recovery-loss term should not be used to invent a precise probability. It is a scenario value: what does four hours, two days or a week of outage cost, and which architecture makes each scenario plausible? A lower storage bill can justify funding a second independent copy or more frequent drills. Conversely, a cheap bucket that is never restored may simply conceal risk until the most expensive day.

Supervision should be measured in ordinary units. Record administrator minutes per failed 1,000 backup jobs; tickets per month; time to reconcile invoice variance; time to rotate a key across all clients; percentage of buckets with verified retention; replication failures older than one day; and restore exercises requiring undocumented escalation. These measures separate a service that is inexpensive to buy from one that is inexpensive to operate.

Small and midsize businesses have a particular trade-off. Wasabi's one-terabyte minimum and straightforward API economics can be accessible, while a managed backup provider can supply expertise the business lacks. But the MSP fee may dominate the raw storage price, and the business may not know which party owns the catalogue, keys and recovery runbook. The contract should say how to recover if the MSP itself is unavailable, how data can be exported, which Wasabi account owns the buckets and whether the customer can obtain emergency read credentials.

The failure drill that should decide the purchase

A serious evaluation does not need to destroy production or attack the provider. It needs an authorised test account, disposable data and a fixed set of ordinary failures.

Start with a representative corpus: many small files, several large files, a database-consistent backup, a virtual machine, encrypted data and data that changes daily. Record logical source size, objects written, active and deleted storage, deduplication, elapsed backup time and operator interventions. Run long enough for at least one retention cycle; a short proof of concept cannot reveal a 90-day charge pattern.

Then perform four recovery classes.

  1. Granular restore. Recover randomly selected files and application records from several dates. Verify cryptographic hashes where available, permissions, ownership, timestamps and application readability. Selection must occur before the operator sees which items are easy.
  2. System restore. Rebuild a machine or service into an isolated target using only documented recovery materials. Include catalogue recovery, encryption-key retrieval, network configuration, application start and a business-level check.
  3. Bulk recovery. Restore enough data to expose sustained throughput, small-object overhead, proxy limits and destination writes. Run during an ordinary busy period as well as a quiet one. Measure usable throughput at the application, not a synthetic Wasabi speed page alone.
  4. Control-plane loss. Assume the normal backup server, identity provider and primary credentials are unavailable. Use break-glass access, rebuild metadata and recover from a second region or independent copy. Record every human decision and support dependency.

For each attempt, preserve failures. Do not rerun until a passing number replaces the first result. Score an attempt accepted only when it meets recovery time and point objectives, integrity checks and application validation. Report first-attempt acceptance separately from eventual success. A system that succeeds after three days of expert repair is not equivalent to one that meets a four-hour objective without escalation.

Add specific fault cases: revoke an old key after rotation; deny a needed permission; point a client at the wrong region; interrupt a multipart upload; attempt to delete a Governance-locked and a Compliance-locked disposable object; let a catalogue copy become unavailable; fill reserved capped capacity; create object churn that reaches timed deleted storage; pause replication; and restore while ordinary traffic shares the link. Every action must be confined to the authorised test environment.

The commercial observation must run beside the technical one. Compare forecast and invoice categories daily. Separate active from timed deleted storage, sub-account minimums, support and partner charges. Project the observed object churn through one year and through the end of a reserved term. Ask what happens if capacity falls 30%, grows 50%, or has to migrate after six months.

CISA's ransomware guidance supports this emphasis: maintain offline encrypted backups and regularly test their availability and integrity in a disaster-recovery scenario. It also warns that immutable cloud storage should be used with care because misconfiguration can impose cost. The guidance does not endorse a particular provider. It establishes that a storage copy becomes evidence of resilience only through restoration and integrity testing.

Substitutes change which cost is visible

Wasabi should be compared with architectures, not only per-terabyte price tables.

A hyperscale object store can offer more regions, adjacent compute, private networking, key-management integration and deeper monitoring, but storage classes, requests, retrieval and egress can make the bill harder to forecast. A smaller S3-compatible provider may offer a different egress allowance or deletion minimum, with its own region and support trade-offs. A managed backup service can combine software, storage and recovery accountability at a higher unit price. A local immutable appliance can provide faster bulk recovery but requires capital, maintenance and a genuinely off-site copy. Tape offers physical separation and low long-term media cost while adding handling, catalogue and retrieval time.

The strongest result may be mixed: a short-retention local copy for fast operational recovery, an immutable Wasabi copy for off-site protection, and a separate provider or offline medium for correlated failure. That design costs more than one bucket. It can cost less than buying enough network to restore every workload remotely within hours or discovering that one administrative compromise reached every copy.

Switching cost also deserves explicit treatment. S3 compatibility improves tool portability, but moving petabytes still consumes time and destination capacity. Minimum-duration charges can continue after source deletion. Reserved capacity may remain payable. Object Lock can prevent deletion until retention expires. Backup formats may be proprietary even when the underlying objects use a standard API. A buyer should prove that another installation of the backup product can import the repository, that data can be read without the MSP, and that a neutral client can enumerate and verify objects where format permits.

The provider's 2026 price increase is a reminder that predictable billing is not fixed pricing. Wasabi gave notice and applied the new $7.99 rate to current Pay-Go customers from July 1, while existing reserved contracts remained protected until renewal under the notice. Long commitments trade price certainty for capacity and exit risk. The correct term is the shortest one that earns a meaningful discount without forcing the customer to guess growth beyond its evidence.

A conditional verdict: strong component, incomplete recovery promise

Wasabi has a coherent place in the storage market. One hot tier reduces retrieval delay and tier-management mistakes. Public list pricing is easy to understand. The absence of separate API and ordinary egress charges removes a genuine deterrent to health checks and restore drills. S3 support gives customers a broad application ecosystem. Object Lock, versioning, regional selection, replication and logging provide useful building blocks for resilient backup.

The limits are equally concrete. Pay-Go's 90-day minimum duration can make high-churn backup data cost much more than its current logical size suggests. Free egress has a reasonable-use boundary. S3 compatibility contains documented differences. A one-region design has lower stated availability than a two-region design, and a disclosed regional incident affected object accessibility. Object Lock can be bypassable or irreversible depending on mode, and it relies on correct interaction with backup software. The service does not supply the catalogue, clean recovery compute, application consistency, operators or business validation that turn objects into a recovered service.

Wasabi is most compelling when data changes slowly enough for the duration policy, egress is dominated by occasional restores, a supported backup product controls object retention, local or second-provider copies cover urgent and correlated failures, and the customer actually runs recovery exercises. It is less compelling for very high churn, frequent distribution, objectives shorter than available network transfer, uncertain capacity commitments, or organisations that expect the storage vendor to own the whole recovery.

The purchase decision should rest on five observed numbers: first-attempt accepted recovery rate, elapsed recovery time by workload, human minutes per accepted recovery, billable storage divided by logical protected data, and total annual cost including every copy and partner. Add two governance facts: who can bypass or change retention, and who can recover when the normal control systems are gone.

If those measures beat the incumbent and alternatives, Wasabi's low-friction economics are meaningful. If they are unknown, $7.99 per terabyte is only the price of storing evidence that a backup job ran. The value appears later, when the organisation proves that the evidence can bring the business back.