What AIOZ Storage Erasure Coding Covers and What It Doesn't
AIOZ Storage protects every object with Reed-Solomon erasure coding, and there is nothing to switch on. That covers you when nodes or disks on the network fail. It does not undo a deletion you make yourself, because AIOZ's docs say a deleted bucket cannot be restored.
TL;DR:
- AIOZ Storage encrypts each object, then splits it into data and parity pieces stored on different AIOZ DePIN nodes. Any k of the n pieces rebuild it, and no single node holds a complete copy.
- That covers node and disk loss. The network audits nodes and repairs lost pieces. The k and n values aren't public, so don't plan around a specific number.
- It doesn't cover deletes, overwrites or a lost account. AIOZ cannot restore a deleted bucket, so erasure coding is not a backup.
- Two node counts get quoted: 191,285 edge nodes on the Storage homepage, and 328,460 total DePINs on the AIOZ DePIN page on 2026-10-09. They measure different things.
Updated Oct 19, 2026: rewritten around erasure coding, which is how AIOZ Storage protects stored objects. Earlier versions described redundancy as full copies; the title, image and FAQ changed with it.
How Does AIOZ Storage Protect Your Data?
Every object you upload goes through the same steps, per AIOZ Storage engineering (2026). Server-side encryption runs first. Reed-Solomon erasure coding then splits the encrypted object into data pieces plus parity pieces, n pieces in total, and each piece goes to a different node on AIOZ DePIN. Any k of those n pieces are enough to rebuild the object.
Two things follow for you. Your object survives the loss of several pieces at once, because the pieces that remain can still rebuild it. And no single node holds a complete copy, only an encrypted fragment. The network also audits the nodes that store pieces and repairs pieces that go missing, so protection doesn't wear down as nodes join and leave.
The Getting Started overview lists "No Single Point of Failure" among the platform's key features, and for stored objects this is the mechanism behind it. For the general idea, with Storj's and Sia's published k and n values, read What Is Erasure Coding? How It Compares to Replication.
Why Erasure Coding Instead of Full Copies?
Parity pieces buy durability for far less disk than whole copies. Storj's documentation puts it plainly: "replicating data at 10x can't beat erasure codes with k=16, n=32, which is an expansion factor of only two." Ten full copies cost ten times the storage, while that code costs twice the file's size.
The cost moves to coordination. A read gathers pieces from several nodes instead of one, and a lost piece has to be rebuilt from the others. That is why the audit and repair loop matters as much as the coding itself. For the full-copy side of the comparison, What Is Data Replication in Distributed Storage Systems? covers how replication works in general.
What AIOZ DePIN Means for Your Data
AIOZ's definitions page spells DePIN out as Decentralized Physical Infrastructure Networks, and says AIOZ Network "rewards DePIN computational resources for computing, storing, transcoding, and streaming digital media content." The AIOZ DePIN page lists Stream, Storage and Pin together under AIOZ DePIN's collaborative infrastructure. If you want the network-level picture, What Is AIOZ DePIN and How It Powers Video Delivery covers it from the Stream side.
Two node counts circulate, and they answer different questions:
| Figure | Where it appears | What it counts |
|---|---|---|
| 191,285 | AIOZ Storage homepage, "Edge Nodes", shown next to a 15MB/s average download speed | Storage's own edge node figure |
| 328,460 | AIOZ DePIN page, "Total DePINs", read on 2026-10-09 | The whole network across its products |
The second number is a live counter and moves from day to day, so treat both as snapshots. Neither says how many nodes hold pieces of any particular object.
Erasure Coding With Nothing to Configure
In Amazon S3, copying objects to a second bucket or region is a feature you set up. Live replication starts when you add a replication configuration to the source bucket, naming the destination buckets and which objects to copy. Both buckets must have versioning enabled, and objects that existed before you set it up are not replicated unless you run a separate Batch Replication job.
AIOZ Storage has no setup step for its protection. The coding runs on every upload, and it reaches vectors too: the vector database docs say stored vectors get the same protection as every other object, with "no cluster to size, patch, or scale." If you are weighing that feature, Vector Database vs Agent Memory on AIOZ Storage: A Guide covers it.
What Doesn't Erasure Coding Protect Against?
Erasure coding protects the object as it is stored now against lost nodes and disks. It keeps no history of your data, so it can't bring back an object you deleted or overwrote, and it can't help if you lose access to your account. The AIOZ docs are direct about the case that matters most. A bucket can only be deleted when it is empty, and the Manage Buckets page says the action "cannot be undone." The static website hosting page goes further: "If a bucket is deleted, it can't be restored by AIOZ. Before deleting a bucket, make sure that you have backed up or replicated your data."
Folders are looser. The Manage Objects page says a folder does not have to be empty before you delete it, so a folder with files in it can be deleted.
Overwrites work the same way. The AIOZ docs don't describe object versioning, so when you upload a new object under an existing key, plan as if the old one is gone. A copy you keep elsewhere is the only undo you control.
A Simple Backup Routine That Fits
The 3-2-1 backup rule (three copies, two media, one off-site) is the standard frame. Erasure coding on AIOZ makes one copy hard to lose to hardware, so the other copies have to live somewhere else. A routine that covers the gap:
- Keep one copy of anything you cannot recreate on a different provider or on your own hardware. Multi-Cloud Storage Disaster Recovery with AIOZ and S3 shows the rclone setup, and why its two-way sync mode is labeled advanced.
- Prefer a one-way copy for backups. A two-way sync passes your mistakes to the other side.
- Check the second copy before you delete a bucket. That is the exact step the docs ask for.
- Restore a few files from the second copy now and then, so you know it works.
Frequently Asked Questions
Does AIOZ Storage protect data automatically?
Yes. Every object is encrypted, then Reed-Solomon erasure coded into pieces on different AIOZ DePIN nodes, with no configuration on your side.
How many pieces does AIOZ Storage split an object into?
The k and n values aren't public. Any k of the n pieces rebuild the object, and no single node holds a complete copy. If a compliance requirement depends on exact numbers or piece locations, ask AIOZ directly.
Can AIOZ restore a bucket I deleted?
No. The docs say a deleted bucket "can't be restored by AIOZ" and that deleting a bucket cannot be undone.
Are vectors protected the same way?
Yes. The vector database docs say stored vectors get the same protection as every other object on the network.
Is erasure coding the same as replication?
No. Replication stores whole copies on several nodes. Erasure coding stores data and parity pieces, any k of which rebuild the file, so it reaches the same durability with much less storage. What Is Erasure Coding? How It Compares to Replication explains the difference.
How many nodes does AIOZ have?
191,285 edge nodes on the AIOZ Storage homepage, and 328,460 total DePINs on the AIOZ DePIN page on 2026-10-09. Different scopes, both moving.
Related Reading
- What Is Erasure Coding? How It Compares to Replication - k, n and the expansion factor, with Storj's and Sia's published schemes.
- What Is Data Replication in Distributed Storage Systems? - the full-copy approach erasure coding is measured against.
- Data Durability vs Availability: What 11 Nines Means - what redundancy does and does not guarantee.
- The 3-2-1 Backup Rule: A Practical Framework Explained - the backup frame used above.
- What Is AIOZ DePIN and How It Powers Video Delivery - the network from the AIOZ Stream side.
References
- AIOZ Storage Docs: Definitions
- AIOZ Storage Docs: Manage Buckets
- AIOZ Storage Docs: Manage Static Website Hosting
- AIOZ Storage Docs: Vectors and Vector Databases
- AIOZ DePIN: Powered by People
- Storj Documentation: Understanding File Redundancy, Durability, Expansion Factors, and Erasure Codes
- AWS: Replicating Objects Within and Across Regions
- AWS: Requirements and Considerations for Replication
Related Content
How to Create a Bucket and Upload a File on AIOZ Storage
Create a bucket and upload a file on AIOZ Storage in five steps: sign up, set a passphrase, add credits, and upload. Plus what the passphrase cannot recover.
AIOZ Storage Rate Limit: Working Within 100 Requests/s
The AIOZ Storage rate limit is 100 requests per second. See what the docs do and don't say, and how to stay under it with boto3 retries and a limiter.
What AIOZ Storage Erasure Coding Covers and What It Doesn't
AIOZ Storage erasure coding splits each object into pieces on DePIN nodes, so it survives node loss. See what it covers, what it doesn't, and what to back up.
How to Rename a File in an S3 Bucket on AIOZ Storage
Rename a file in an S3 bucket on AIOZ Storage from the dashboard, then move, delete and download files, and see which actions the docs say are not supported.
AIOZ Storage llms.txt: Docs Built for Super Intelligence
AIOZ Storage publishes llms.txt, a 46-link docs index, and llms-full.txt, all docs in one 164 KB file. See what each file contains and when to use which.
Vector Database vs Agent Memory on AIOZ Storage: A Guide
Vector database vs agent memory on AIOZ Storage: use the vector database for control over embeddings and metadata, Memory for simple Record and Recall calls.