| Internet-Draft | HyPR | October 2026 |
| Cummings | Expires 23 April 2027 | [Page] |
Local redundancy mechanisms such as RAID and software-defined parity pools tolerate only a bounded number of correlated device losses, while remote backup services typically require replication of the full data set. HyPR's remote storage requirement scales with the parity-to-data ratio m/k rather than with the size of the protected data, at the cost of not protecting against total loss of the local copy. This document specifies HyPR (Hybrid Parity for Remote Resilience), a framework that treats remote storage, including consumer-grade end-to-end-encrypted cloud services, as additional failure-domain participants in an erasure-coded storage system. HyPR defines a content-chunked Remote Parity Fragment format, transport requirements for backend-agnostic encrypted fragment delivery, immutable and versioned vault semantics, a resumable reconstruction protocol that produces signed rebuild receipts, and a boundary within which machine-learned orchestration agents may advise but never replace deterministic reconstruction.¶
This note is to be removed before publishing as an RFC.¶
This is an individual submission. It is not the product of an IETF working group, and it does not represent IETF consensus. Comments may be sent to the author at the address above.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Redundant arrays and erasure codes tolerate loss only within the failure domains they span. A RAID-Z3 array survives three drive failures, but it does not survive a controller fault that removes several drives at once, a firmware or manufacturing-batch failure that affects a whole cohort of drives, or the loss of the site that houses the array. Remote replication addresses site loss, but it carries at least 100% storage overhead and exposes plaintext to the provider unless the data is separately encrypted.¶
No standardized protocol currently allows a client to compute supplemental erasure-coded parity for data held on an existing local array and deposit that parity on arbitrary remote storage, so that losses exceeding the local redundancy budget can be repaired using only a fractional amount of remote capacity. This document describes such a framework, called HyPR.¶
HyPR does not propose a new file system and does not modify the local array. It operates above the storage mechanism layer, on content-defined chunks of file data, and computes Remote Parity Fragments that are encrypted on the client and delivered to any conforming remote store.¶
HyPR is complementary to, and not a replacement for, a full offsite copy. As shown in Section 5.4, remote parity of fractional size cannot by itself restore a data set whose local copy has been lost entirely. HyPR addresses losses that are partial, correlated, or beyond the local redundancy budget.¶
This document specifies the Remote Parity Fragment format (Section 6), the vault manifest (Section 7), transport and vault requirements (Section 8, Section 9, Section 10), degraded-stripe detection and restoration (Section 11, Section 13), the reconstruction protocol (Section 12), and the boundary between deterministic reconstruction and advisory orchestration (Section 14).¶
This document does not specify a file system, a replacement for local RAID, a cloud provider API, a key escrow service, or the internal behavior of any machine-learned model.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Existing approaches fall short along three axes.¶
Domain binding. Standard local erasure codes, such as mdadm RAID levels, ZFS RAID-Z, and Btrfs profiles, cannot extend parity across a wide-area boundary. Their redundancy is bounded by the devices in the local array, and a single correlated event can exceed it.¶
Asymmetry. Remote backup replicates data, which carries 100% or greater storage overhead and, absent separate encryption, exposes content to the provider. Parity fragments carry no independently intelligible payload and incur only fractional overhead.¶
Reconstruction coupling. No widely deployed remote-backup mechanism defines how a degraded local array identifies which parity it requires, so that a targeted partial rebuild can be performed instead of a full restore.¶
Related mechanisms exist but address different problems. File parity tools such as PAR2 [PAR2] and SnapRAID compute parity over files or disk sets, typically stored locally and without a defined remote delivery or immutability model. Distributed filesystems such as Tahoe-LAFS [TAHOE] erasure-code and encrypt the data itself across servers, rather than adding supplemental parity to an existing local array. Deduplicating backup tools such as restic and Borg use content-defined chunking and encrypted repositories but replicate chunks rather than computing cross-chunk parity.¶
+-------------------------------------------------------------+
| Orchestration Agent (optional, advisory) |
| failure prediction / tiering / repair scheduling |
+------------------------------+------------------------------+
| advice only
+------------------------------v------------------------------+
| HyPR Core (deterministic) |
| chunking | supplemental EC | encryption | keys | rebuild |
+---------------+-----------------------------+---------------+
| |
+---------v---------+ +---------v---------+
| Local Array | | Remote Vault(s) |
|(ZFS, Btrfs, mdadm;|-RPFs--->| (S3-compatible, |
| unmodified) | | SFTP, WebDAV) |
+-------------------+ +-------------------+
The HyPR Core reads file data from the Local Array, forms Supplemental Stripes, computes RPFs, encrypts them, and delivers them to one or more Vaults together with an encrypted Manifest. The Local Array is not modified and need not be aware of HyPR. The layering is two-tier: the Local Array provides inner redundancy at the device level, and HyPR provides outer redundancy at the Chunk level.¶
A HyPR Core MUST divide file data into Chunks using content-defined chunking, for example Rabin fingerprinting [RABIN], such that an insertion or deletion perturbs a bounded number of Chunks.¶
Chunking parameters, including any polynomial or seed, SHOULD be secret to the Vault owner and derived from the Vault key material. Public, fixed chunking parameters allow an observer of fragment sizes and boundaries to confirm the presence of known content (Section 16).¶
Minimum, average, and maximum Chunk sizes are deployment-configurable and are recorded in the Manifest.¶
The HyPR Core groups Stripe Units into Supplemental Stripes of k units and computes m RPFs over each stripe using a systematic maximum-distance-separable (MDS) code, for example Reed-Solomon over GF(2^8) or GF(2^16) [REEDSOLOMON] [PLANK]. Any k of the k+m members of a Supplemental Stripe suffice to recover all k Stripe Units. When GF(2^8) is used, k+m MUST NOT exceed 256.¶
The Supplemental Stripe is a logical construct defined by HyPR over Chunks. It does not depend on the physical stripe geometry or the parity of the Local Array, which HyPR treats as opaque.¶
Because HyPR cannot observe where the Local Array places data, stripe membership SHOULD be formed by interleaving Chunks drawn from files written at different times and from different parts of the file tree. This reduces the likelihood that a localized failure in the Local Array erases more than m members of any one Supplemental Stripe. The protection this provides against physical loss is therefore statistical rather than guaranteed.¶
As an illustration only, assume that Stripe Units are placed uniformly and independently across the Local Array, and that a fraction f of local data becomes unreadable while the m RPFs of each stripe remain intact. A stripe is then unrecoverable when more than m of its k local Stripe Units are lost, which has probability P(X > m) for X distributed Binomial(k, f). For k = 10, m = 2, and f = 1%, this is about 1.1 x 10^-4 per stripe. With 1 MiB Stripe Units, a 50 TB data set has roughly 4.8 million such stripes, so about 540 stripes would be unrecoverable. The model shows that HyPR is most effective against small, scattered losses and that its benefit falls quickly as the lost fraction rises. It is not a guarantee, because real placement is neither uniform nor independent.¶
A Supplemental Stripe is immutable once sealed, and a Vault object is never modified in place. When file data changes, the HyPR Core forms new Stripe Units, new Supplemental Stripes, and new RPFs in a new Epoch. Stripes that no longer reference live data are released by retention policy (Section 10) and not by overwrite.¶
Because RPFs are encrypted on the client, a remote party cannot apply parity deltas. The client computes each new RPF in full and uploads it as a new object. Remote write amplification is bounded by the number of Supplemental Stripes touched by changed Chunks, not by the size of the data set. Implementations MAY use the linearity of the code to compute an updated RPF from the old and new Stripe Units, where each parity row is combined using the appropriate field coefficient, but this is a local optimization and is not visible to the Vault.¶
For a Supplemental Stripe of k Stripe Units and m RPFs, the stripe remains recoverable after the loss or corruption of any m or fewer of its k+m members, where RPFs held on remote storage count as members.¶
Recovering a data set of size D requires at least D units of information to survive. Consequently, if every local copy of the k Stripe Units is lost and only m < k RPFs remain, the stripe cannot be recovered. HyPR therefore protects against:¶
HyPR does not, by itself, protect against the simultaneous loss of all or most local data, such as loss of the entire site. Deployments that require that property MUST maintain a full offsite copy, and MAY use HyPR in addition to it. A deployment that sets m greater than or equal to k obtains full-copy recoverability from parity alone, at storage overhead comparable to replication.¶
A principal advantage of HyPR over full offsite replication is reduced remote storage. For a Supplemental Stripe of k Stripe Units and m RPFs, the remote parity occupies m/k of the protected data size, whereas a full offsite copy occupies 100% of it. Table 1 gives examples for a 50 TB data set.¶
| Scheme | Remote overhead | Remote storage | Survives total local loss |
|---|---|---|---|
| Full offsite copy | 100% | 50 TB | Yes |
| HyPR, k=4, m=2 | 50% | 25 TB | No |
| HyPR, k=10, m=2 | 20% | 10 TB | No |
| HyPR, k=20, m=2 | 10% | 5 TB | No |
The figures in Table 1 are the steady-state parity size only. This saving is obtained in exchange for the limitation stated in Section 5.4: remote parity of fractional size cannot restore a data set whose local copy has been lost entirely. HyPR is therefore a means of obtaining protection against losses that exceed the local redundancy budget at a fraction of the remote cost of replication. It is not a substitute for a full offsite copy where total site loss must be survived.¶
The following factors increase actual remote usage above the figures in Table 1.¶
Under a simplified model, remote usage is approximately (m/k) x D x (1 + c x R), where D is the protected data size, c is the fraction of data that changes per day, and R is the retention period in days. The model assumes that changed data forms new stripes and that superseded stripes are kept for the full retention period. Table 2 applies it to the 50 TB data set with k = 10 and m = 2, and compares it with a full offsite copy kept under the same retention, whose usage is approximately D x (1 + c x R) under the same assumptions.¶
| Daily change (c) | Retention (R) | HyPR remote usage | Versioned full copy |
|---|---|---|---|
| 0% | any | 10 TB | 50 TB |
| 0.5% | 30 days | 11.5 TB | 57.5 TB |
| 0.5% | 90 days | 14.5 TB | 72.5 TB |
| 2% | 30 days | 16 TB | 80 TB |
| 2% | 90 days | 28 TB | 140 TB |
The ratio between the two right-hand columns stays at m/k, so the relative saving is unchanged by churn, but absolute usage can grow to a multiple of the steady-state parity size. Deployments with high churn and long retention should size remote capacity with this model and not from Table 1 alone.¶
Compared with adding parity devices to the Local Array, HyPR does not reduce the amount of parity stored. It places that parity in a separate failure domain, which is its purpose.¶
Implementations MAY use rateless erasure codes such as RaptorQ [RFC6330] where the number of surviving fragments is uncertain. Rateless reconstruction is best suited to immutable or rarely mutating data, which is consistent with the immutability of Section 5.3.¶
An RPF is a binary object with the layout in Figure 2. All multi-octet integers are in network byte order. The fixed header is 72 octets and is authenticated, but not encrypted, as associated data of the AEAD construction (Section 8).¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic (0x48795052) | +---------------+---------------+-------------------------------+ | Version | Code ID | Flags (zero) | +---------------+---------------+-------------------------------+ | | | Vault ID (16 octets) | | | | | +---------------------------------------------------------------+ | | | Stripe ID (16 octets) | | | | | +---------------------------------------------------------------+ | Epoch (8 octets) | | | +-------------------------------+-------------------------------+ | Fragment Index | K | +-------------------------------+-------------------------------+ | M | Key Generation | +-------------------------------+-------------------------------+ | Fragment Length | +---------------------------------------------------------------+ | | | Nonce (12 octets) | | | +---------------------------------------------------------------+ | Ciphertext (Fragment Length octets) | +---------------------------------------------------------------+ | | | Authentication Tag (16 octets) | | | | | +---------------------------------------------------------------+
| Field | Size (octets) | Description |
|---|---|---|
| Magic | 4 | 0x48 0x79 0x50 0x52 ("HyPR") |
| Version | 1 | Format version; this document defines 0x01 |
| Code ID | 1 | 1 = Reed-Solomon over GF(2^8); 2 = Reed-Solomon over GF(2^16); 3 = RaptorQ |
| Flags | 2 | Reserved; MUST be zero on send and ignored on receipt |
| Vault ID | 16 | Random identifier of the Vault |
| Stripe ID | 16 | Random identifier of the Supplemental Stripe |
| Epoch | 8 | Epoch in which the RPF was written |
| Fragment Index | 2 | Index of this RPF among the m parity fragments, starting at zero |
| K | 2 | Number of Stripe Units in the stripe |
| M | 2 | Number of RPFs in the stripe |
| Key Generation | 2 | Identifier of the master key generation from which this RPF's key is derived (Section 9) |
| Fragment Length | 4 | Length of the ciphertext in octets |
| Nonce | 12 | AEAD nonce |
Implementations SHOULD use a fixed Fragment Length across a Vault so that fragment sizes do not reveal Chunk sizes (Section 15). The IANA media type for an RPF container is requested in Section 17.¶
Reconstruction after loss of local state requires knowing which Chunks belong to which Supplemental Stripe and where the corresponding RPFs are stored. The HyPR Core MUST therefore write, for each Epoch, an encrypted Manifest to the Vault. A Manifest records:¶
Digests MUST use SHA-256 [RFC6234] or a stronger function. A Manifest MUST be encrypted with an AEAD construction under a key distinct from the RPF keys. A HyPR Core MUST verify the hash chain when it enumerates Epochs and MUST report any discontinuity to the operator.¶
A conforming transport MUST provide the following.¶
Client-side encryption before egress. The remote party MUST NOT hold, and MUST NOT be able to derive, any decryption key. RPFs and Manifests MUST be encrypted with an AEAD construction. ChaCha20-Poly1305 [RFC8439] is mandatory to implement. Implementations MUST ensure that a (key, nonce) pair is never reused. Deriving a distinct key for each RPF from the master key, Vault ID, Stripe ID, Fragment Index, and Epoch using HKDF [RFC5869] is RECOMMENDED.¶
Resumable retrieval. The transport MUST support byte-range retrieval of fragments and resumption of an interrupted transfer without restarting completed fragments.¶
Integrity verification. The HyPR Core MUST verify the AEAD tag of every RPF and the digest of every recovered Stripe Unit before using them in reconstruction.¶
Transports SHOULD map onto existing protocols, including S3-compatible object APIs, SFTP, and WebDAV [RFC4918]. A HyPR Core MUST NOT depend on any provider feature other than object creation, ranged read, listing, and, where available, object-level immutability.¶
This section defines the minimum key management required for interoperable recovery. Key escrow services, hardware token interfaces, and organizational key policy are out of scope.¶
A Vault MUST enforce append-only writes with configurable retention, such that compromise of the local system, including malware operating with the local host's credentials, cannot destructively rewrite or delete remote parity within the retention period.¶
To that end:¶
Where a provider cannot enforce immutability, the deployment MUST document that limitation, and the HyPR Core SHOULD detect and report unexpected modification or removal of objects at each Epoch.¶
The reconstruction protocol (Section 12) starts from a degraded Supplemental Stripe, that is, one with one or more unreadable or corrupt Stripe Units. Because HyPR treats the Local Array as opaque, it has no direct view of device health, and detection relies on the following sources.¶
A verification pass reads every protected byte, so its cost is proportional to the data set size D. For example, a full pass over 50 TB at an aggregate 500 MB/s takes about 28 hours of read time. The HyPR Core therefore MUST make the verification schedule configurable, SHOULD support rate limiting so that production workloads are not starved, and SHOULD support sampled passes that verify a rotating fraction of Stripe Units so that every unit is verified within a bounded number of passes. Encoding needs to read only data that is new or changed since the last Epoch, so a full verification pass is the cost of independent confirmation and not a routine cost of operating HyPR.¶
A Stripe Unit digest in the Manifest is valid only for the data as it was when the Epoch was sealed. A digest mismatch on a file whose size and modification time are unchanged since the Epoch is treated as corruption. A mismatch on a file whose size or modification time has changed is treated as legitimate modification and is not degradation. Such a file is re-encoded in a new Epoch (Section 5.3). A change that preserves file metadata cannot be distinguished from corruption, and treating it as corruption is the safe interpretation.¶
An Orchestration Agent MAY advise on the scheduling and ordering of verification passes. The result of a detection step derives solely from the sources above (Section 14).¶
When the HyPR Core detects a degraded stripe, that is, a Supplemental Stripe with one or more unreadable or corrupt Stripe Units, it proceeds as follows.¶
An interrupted rebuild MUST be resumable without restarting completed fragment transfers.¶
A Rebuild Receipt identifies the Epoch, the reconstructed extents, the source RPFs, and the verification digests, and it is signed with Ed25519 [RFC8032]. The signing key SHOULD be held outside the protected host, for example in a hardware token, so that a compromised host cannot forge a receipt. A receipt records what the HyPR Core did; it does not by itself prove that the reconstructed data is the data originally written.¶
Reconstruction (Section 12) yields verified Stripe Units. This section defines how they are returned to the Local Array.¶
An Orchestration Agent MAY provide advice on: disk failure prediction from time-series device telemetry [PINHEIRO] [SCHROEDER]; degradation-aware repair ordering, which prioritizes stripes approaching their fault-tolerance budget; tiering of data across parity depths on the basis of replaceability; and anomaly detection on synchronization behavior.¶
The following constraints apply.¶
RPFs are parity, so they carry no independently intelligible payload, and they are encrypted on the client. A remote provider that is compelled to disclose stored objects can disclose only ciphertext, and it cannot recover protected content without keys it does not hold.¶
The provider can still observe access patterns, object counts, object sizes, write timing, and the cleartext header fields of Section 6, which reveal code geometry (K, M), Epoch, and fragment indices. To reduce this surface, deployments SHOULD use a fixed Fragment Length, SHOULD upload on a uniform cadence where practical, and SHOULD use random Vault and Stripe identifiers that carry no semantic content.¶
This document requests registration of the following media type in the standards tree, in accordance with [RFC6838].¶
This document also requests that IANA create a registry for the RPF Code ID field (Table 3), with initial values 1, 2, and 3 as defined above and a registration policy of Specification Required.¶