Synology DS923+ storage sizing for 6TB encrypted data and 30-day snapshots

Part of our guide on backup and recovery plan for 4tb data

Sizing storage for encrypted backups with snapshots is possible with straightforward math plus one critical step: measure actual snapshot growth and encryption impact on a representative dataset before finalizing capacity.

Key upfront facts: parity drive is not standalone and RAID5 needs at least 3 drives

First, an important clarification: a single physical 8TB drive cannot act on its own as a RAID5 parity drive that contains your full dataset. RAID5 is a distributed parity scheme requiring a minimum of 3 drives. Parity is distributed across the array; you do not have a separate "parity drive" that can store the dataset by itself.

On the DS923+, to create a RAID5 volume you must populate at least three bays. Usable capacity in RAID5 equals the raw total of all drives minus the capacity of one drive (i.e., raw_total − one_drive). For identical drives this is approximately (N − 1) × drive_size.

How to think about encryption and snapshot overhead (estimates and how to measure)

Any encryption and snapshotting solution changes how much physical storage you need versus the raw size of your files. Two different factors matter here: (1) encryption overhead related to metadata, block alignment, and filesystem interaction, and (2) snapshot space consumption determined by how much data changes during the retention window.

Sourcing: Synology documents DSM volume encryption and snapshot functionality in their Knowledge Base and Product Manuals. Synology does not publish a single "encryption overhead" percentage because real overhead depends on file size distribution, filesystem (Btrfs vs ext4), and alignment. Similarly, snapshot consumption depends on the workload. Therefore the numbers below are conservative planning estimates based on practical testing approaches and community experience; treat them as planning guides, not immutable facts. Before you commit to anything, it is worth looking at readynas sizing for 2 hour rto.

Recommended approach: measure your own environment. Create a small test volume on the same disk type and filesystem, enable DSM encryption and snapshots, then copy a representative sample dataset and record the reported disk usage and snapshot growth over a 30-day simulated change period. This gives an empirical overhead factor you can apply to full-size planning.

Conservative overhead estimates to use when planning

To give practical guidance while avoiding invented precision, use ranges and note conditions:

– Encryption overhead: expect roughly 3%–10% extra consumed space compared to unencrypted files. Lower end (≈3%) is plausible for large sequential files and efficient alignment; higher end (≈10%) can occur with many small files, padding and filesystem metadata. This is an estimate—measure in your setup. (Reference: Synology DSM encryption docs describe encryption at the volume level and note metadata/storage implications; exact percent varies.) People in this spot often ask about calculating nas usable capacity as well.

– Snapshot overhead for a 30-day retention: estimate depends on change rate. For a mostly static dataset (few daily changes), incremental snapshot growth could be in the 5%–15% range. For moderately active datasets, 10%–40% is a conservative planning window. Highly active environments can exceed this. Snapshots on Synology (Btrfs snapshot or LVM-based depending on setup) use block-level differencing; space equals the changed blocks retained across snapshots.

Combine these conservatively for planning: add encryption estimate to base data, then budget snapshot storage as a percentage of the (encrypted) dataset. For planning safety on mixed/uncertain workloads, many admins choose a combined buffer of 15%–50% above raw data size depending on expected change activity.

Concrete usable-capacity calculations for 6TB encrypted data + 30-day snapshots

Start with the base dataset: 6.0 TB of client files (logical size). We'll apply the conservative overhead ranges above to produce planning scenarios. Steps:

1) Apply encryption overhead (use a middle estimate for planning): if you plan 5% encryption overhead, encrypted dataset size = 6.0 TB × 1.05 = 6.3 TB. If you expect many small files, use 10% → 6.6 TB. If large files and well-aligned, use 3% → 6.18 TB.

2) Apply snapshot budget for 30-day retention: choose a snapshot percentage based on expected change rate. For a relatively static client dataset (low daily changes), a 10% snapshot budget is plausible. For moderate change, use 20%–30%. For planning here we will show two example scenarios: conservative-moderate (encryption 5% + snapshot 20%) and conservative-low-change (encryption 5% + snapshot 10%).

Scenario A — moderate-change planning (5% enc + 20% snapshots):

– Encrypted data = 6.0 TB × 1.05 = 6.30 TB

– Snapshot buffer = 20% of encrypted data → 6.30 × 0.20 = 1.26 TB

– Total usable space needed ≈ 6.30 + 1.26 = 7.56 TB (round to ~7.6 TB)

Scenario B — lower-change environment (5% enc + 10% snapshots):

– Encrypted data = 6.30 TB

– Snapshot buffer = 0.63 TB

– Total ≈ 6.93 TB (round to ~7.0 TB)

What RAID5 on DS923+ using 8TB drives gives you (3×8TB and 4×8TB worked examples)

Now translate usable-space needs into drive counts and array sizes. RAID5 usable = (N − 1) × drive_size for identical drives.

Example 1 — 3×8TB in RAID5:

– Raw capacity = 3 × 8 TB = 24 TB

– Usable RAID5 = (3 − 1) × 8 TB = 16 TB (because one drive-equivalent is parity)

– After overhead: if you need ~7.6 TB usable (Scenario A), 16 TB is comfortably larger and leaves room for growth and snapshot expansion.

Example 2 — 4×8TB in RAID5:

– Raw capacity = 4 × 8 TB = 32 TB

– Usable RAID5 = (4 − 1) × 8 TB = 24 TB

– This is ample headroom for 6 TB of encrypted files plus a 30-day snapshot history, allowing for future growth and higher change rates.

Why a single 8TB drive is insufficient and what people mean by "8TB parity drive"

Some descriptions casually say "an 8TB parity drive" but that can be misleading. In RAID5 you don't designate a dedicated parity drive that holds all parity and nothing else; parity is distributed. Storing a 6 TB dataset plus snapshots requires usable array capacity larger than the dataset. A single 8 TB physical disk cannot offer >7 TB of usable RAID5 space on its own—raid arrays require multiple drives.

If you have only one drive bay populated with an 8 TB disk, you have roughly 8 TB raw single-drive space (minus filesystem overhead) and no RAID redundancy. That single-drive configuration would be very tightly packed for 6 TB encrypted + snapshots and risky (no redundancy). It also does not meet the DS923+ minimum for RAID5.

Restore time guidance — avoid hard claims, measure in your environment

Restore performance depends on many variables: client and NAS CPU (especially if decrypting on-the-fly), disk/SSD performance, network speed and contention, file characteristics, and protocol overhead (SMB, rsync, etc.). The theoretical maximum over a single 1 Gbps link is 125 MB/s, but real-world sustained throughput is typically lower.

Rather than a single definitive number, plan by testing: do a timed restore of a representative portion of your backup (for example 100–500 GB) over your production network and measure throughput. Use that measured rate to extrapolate full-restore times and to estimate how parallel transfers or other optimizations change timings.

If you need a quick rule of thumb: expect somewhere between 40–110 MB/s in many gigabit-era scenarios depending on hardware and encryption. At 60 MB/s a 500 GB restore takes roughly 500,000 MB ÷ 60 MB/s ≈ 8,333 s (≈ 2.3 hours). At 100 MB/s it would be ≈ 83 minutes. Because of that variance, avoid promising a specific single restore time without environment tests.

Practical recommendations and next steps

1) Minimum configuration: Don’t rely on a single 8TB drive. Use at least three 8TB drives in RAID5 on the DS923+ to get ~16 TB usable and redundancy.

2) Sizing buffer: For 6 TB of base data, plan for roughly 7–8 TB usable after accounting for encryption and a 30-day snapshot budget in typical low-to-moderate-change scenarios. A 3×8 TB RAID5 (16 TB usable) comfortably satisfies that need and leaves headroom; 4×8 TB (24 TB usable) provides ample growth room.

3) Measure in your environment: create a test volume, enable DSM encryption and snapshots, copy representative data, and monitor the reported used space and snapshot growth over several days or a simulated 30-day change profile.

4) Monitor and tune: enable snapshot quotas and alerts in DSM, and periodically review actual snapshot consumption so you can adjust retention or add capacity before you run out.

5) Restore planning: benchmark restore speeds from your NAS to representative clients over your production network with encryption enabled to set realistic RTOs (recovery time objectives). Consider using link aggregation, disabling competing workloads during restores, or using faster network links for critical restores.

Questions people still ask

I sized NAS storage for encrypted backups in client environments and recommend empirical testing (test volumes and snapshot trials) to confirm overhead numbers for your specific workload. Synology DSM documentation describes encryption and snapshot mechanics but does not publish single fixed overhead percentages; the ranges above are conservative planning estimates.