Parity protection for NAS and file servers
A cloud object store keeps several copies of your data across separate hardware and checks them constantly. A NAS in a cupboard does not. A single drive, an ageing USB enclosure, or a filesystem that loses a block during a power cut can leave one backup file quietly corrupt - and you find out at restore time.
For those destinations Nyx Backup writes Reed-Solomon parity alongside each pack of backup data: additional recovery data that lets the original be reconstructed even if part of it is unreadable. The same principle as RAID, at the level of individual backup files, and it travels with the backup rather than depending on the hardware it happens to be sitting on.
Where it applies
Parity is written only for the destinations that lack cloud-grade durability:
- SMB / CIFS shares
- SFTP servers
- AFP shares
- WebDAV
It is never written for cloud object stores (S3, B2, Azure, GCS, Google Drive, OneDrive, Dropbox) or for local disk, and that is a hard rule rather than a default - those destinations already replicate and verify internally, so parity would cost space and time to duplicate a guarantee you already have.
Settings
| Setting | Effect |
|---|---|
| Auto (default) | Parity on NAS-class destinations, off everywhere else |
| Off | No parity, even on a NAS-class destination |
| Custom | Choose the ratio yourself, as data shards + parity shards |
The default geometry is 10 data shards + 2 parity shards: about 20% extra storage, and any two shards of the twelve can be lost with the pack still recoverable.
Custom geometry trades space against resilience - more parity shards survive more damage and cost more space. There is no benefit to setting it on a cloud destination; the hard rule above means it will be ignored.
How repair happens
Repair is automatic and needs no action from you. When a restore reads a pack whose contents fail to decrypt - the signature that the stored bytes are damaged - Nyx looks for the parity file next to it, reconstructs the damaged part, and continues the restore. It is logged, so you know the destination has started to rot even though the restore succeeded.
That last point is the real value: parity turns a corrupt backup from a failed restore into a successful one plus a warning that it is time to look at the hardware.
Related
Parity protects against damage to stored data. It does not protect against something deleting the data outright - for that see the integrity checks described under scheduling, and immutability on supported providers.