How to Optimize Restic Pack Size for a Local NAS Repository

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

How to Optimize Restic Pack Size for a Local NAS Repository

For a local NAS repository, keep restic's 16 MiB default unless measurements show that repository file overhead or HDD seek behavior is limiting throughput. If the NAS stores a multi-terabyte repository on spinning disks, 32 MiB or 64 MiB packs are reasonable values to benchmark before considering anything larger.

Pack size is not the same as restic's deduplication chunk size. Restic first splits file data into content-defined blobs and then groups blobs into pack files. Changing the target pack size changes how those blobs are bundled in the repository; it does not change the repository's chunker polynomial or content hashes.

Start With the 16 MiB Default

The current restic tuning guidance states that the default target pack size is 16 MiB. It also notes that larger pack files can reduce repository file counts and improve backup performance for some repositories stored on local HDDs.

restic version
restic -r /mnt/nas/restic-repo snapshots
restic -r /mnt/nas/restic-repo stats --mode raw-data

Record the restic version, repository size, number of snapshots, storage type, and current backup duration before tuning. If the repository already finishes inside the backup window, a larger pack size may add complexity without producing a useful gain.

Understand What Pack Size Actually Changes

Restic's repository format design explains that file content is split into content-defined blobs and those blobs are grouped into pack files.

Source files
   |
content-defined chunking
   |
deduplicated blobs
   |
pack grouping
   |
repository data files

A larger pack target generally means fewer, larger repository files. That can help a rotating disk spend less time on metadata and file-open overhead. It does not make identical file content deduplicate better.

Check Whether the NAS Is Actually Pack-Size Limited

Before tuning, watch the repository disk during a normal incremental backup. A local HDD repository that is busy with many short seeks and metadata operations while throughput stays low is a better candidate than an SSD repository already writing sequentially at high speed.

iostat -xz 2

Look for sustained disk utilization, elevated await times, and low throughput relative to a large sequential write. Also check CPU use and source-read speed. If compression, hashing, source I/O, or networking is the bottleneck, increasing pack size will not fix it.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

Benchmark 16, 32, and 64 MiB With Comparable Repositories

The cleanest comparison uses disposable repositories created for the test. Use the same source dataset, NAS volume, restic version, and backend connection count.

restic --pack-size 16 -r /mnt/nas/test-restic-16 init
restic --pack-size 16 -r /mnt/nas/test-restic-16 backup /srv/testdata

restic --pack-size 32 -r /mnt/nas/test-restic-32 init
restic --pack-size 32 -r /mnt/nas/test-restic-32 backup /srv/testdata

restic --pack-size 64 -r /mnt/nas/test-restic-64 init
restic --pack-size 64 -r /mnt/nas/test-restic-64 backup /srv/testdata

Measure elapsed time, repository-disk throughput, temporary-space usage, and resulting data-file count. Repeat runs when possible so page cache effects do not determine the result.

Account for Temporary Space Before Increasing Pack Size

Restic documents the temporary-space requirement as approximately:

pack size × (backend connections + 1)

With five backend connections and a 64 MiB target, that is 384 MiB of minimum temporary space. The local backend currently defaults to fewer connections than most remote backends, but the same rule still applies.

df -h "${TMPDIR:-/tmp}"
export TMPDIR=/mnt/fast-temp/restic
mkdir -p "$TMPDIR"

Larger temporary packs can also increase memory use and may cause more temporary writes to reach SSD storage instead of remaining in cache.

Keep the Same Pack-Size Setting on Repository-Writing Commands

Restic says the pack-size setting should be specified for every command that modifies the repository. Use one environment variable for the whole job:

export RESTIC_REPOSITORY=/mnt/nas/restic-repo
export RESTIC_PACK_SIZE=64
export RESTIC_PASSWORD_FILE=/root/.config/restic/password

restic backup /srv/data
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6
restic prune

Changing pack size does not redefine deduplication chunking, but it can leave differently sized packs. Consistency makes future maintenance and performance comparisons easier to interpret.

Do Not Expect Existing Packs to Resize Automatically

A new pack-size setting affects newly created or repacked data. Existing pack files are not rewritten merely because RESTIC_PACK_SIZE changes.

If you intentionally want prune to repack smaller existing packs, current restic provides --repack-smaller-than. Review the prune repacking options first.

restic prune --dry-run --repack-smaller-than 32M

Start with a dry run. Do not force a full repack solely to make every pack file look uniform.

Validate Integrity After Tuning

restic check
restic check --read-data-subset=5%

Choose a verification schedule that fits the repository size. Restic's repository troubleshooting guidance treats integrity checks as the basis for diagnosing repository damage.

For a wider backup design, combine the local repository with another independent copy. The ZimaOS 3-2-1 backup strategy explains why local redundancy and a separate target solve different failure modes.

Use This Decision Rule

Stay at 16 MiB if backups already meet the window or the bottleneck is elsewhere.
Test 32 MiB if a large HDD repository spends substantial time on metadata and small-file operations.
Test 64 MiB if 32 MiB helps and temporary-space use remains comfortable.
Stop increasing when gains flatten or temporary I/O rises.

The best pack size is the smallest value that measurably reduces repository overhead without creating a new bottleneck.