How much RAM does ZFS need for a 100 TB pool?

Where does the "1 GB per TB" rule come from?

Not from OpenZFS. Its FAQ asks for 8 GB or more for the best performance and adds that people run it with 2 GB or less. Its hardware guide gives no memory sizing at all.

Two real rules get mixed into one. The first is a cache target: Proxmox advises at least 2 GiB plus 1 GiB per TiB of storage for the ARC, ZFS's read cache. The second is for deduplication, and it is much larger. The FreeBSD Handbook gives 5 to 6 GB of RAM per TB of deduplicated data.

The 1 GB per TB rule is a cache wish, not a requirement: ZFS runs on far less and caches whatever you give it.

Proxmox itself sets a smaller default. Since Proxmox VE 8.1, the installer limits the ARC to 10% of memory, at most 16 GiB.

What does ZFS use the memory for?

Mostly for the ARC, a cache of recently and frequently read blocks and metadata. More cache means fewer slow trips to the hard drives.

The ARC sizes itself. On Linux, OpenZFS 2.3 and later let it grow to the larger of all memory minus 1 GiB and 5/8 of memory. OpenZFS 2.2 stopped at half of memory on Linux. The floor is the larger of 32 MiB and 1/32 of memory, and ZFS aims to leave 1/64 of memory free.

Two other uses have caps. Scrubs and resilvers sort their reads in memory, up to 1/20 of RAM by default. How long a resilver takes is on the RAID rebuild time page. Deduplication keeps its table in memory, which is where the large numbers come from.

Versions matter on rented systems. On 2 November 2026, Debian 13 shipped zfsutils-linux 2.3.9 and Ubuntu 24.04 shipped 2.2.2.

How much memory does a 100 TB backup pool really use?

Less cache than a file server, because backups are written once and read rarely. The cache helps most with metadata: listing snapshots, pruning old backups and checking indexes.

The Proxmox rule is a sound ceiling for planning. Applied to common layouts, it gives these ARC targets:

• 2 × 12 TB in a mirror, 12 TB usable: about 13 GiB.
• 4 × 10 TB in RAIDZ2, 20 TB usable: about 20 GiB.
• 10 × 10 TB in RAIDZ2, 80 TB usable: about 75 GiB.
• 10 × 16 TB in RAIDZ2, 128 TB usable: about 118 GiB.

Compare with the holds: Hold 24 32 GB DDR4 ECC, Hold 40 64 GB DDR4, Hold 100 128 GB DDR4 ECC, Hold 160 128 GB DDR4 ECC. Below the target, ZFS still runs; it simply reads metadata from disk more often.

Of 23 storage-server sellers Basalthold checked on 2 November 2026, 8 listed a server of 100 TB or more, and 1 rented one to crypto buyers without ID. The whole offer is on the 100 TB storage server page.

Should I turn on ZFS deduplication for backups?

Not on 100 TB. At 5 to 6 GB per TB of deduplicated data, 80 TB would call for 400 to 480 GB of memory. That is more than any hold carries.

Let the backup tool deduplicate instead. restic, Borg and Proxmox Backup Server split data into chunks and store each chunk once, in their own index. The differences are on restic or Borg. Keep ZFS compression on; it costs little memory.

ECC memory matters more than size. OpenZFS calls it highly recommended, because no filesystem can protect against bit flips in RAM. Why ZFS also wants plain drives is on ZFS or hardware RAID.

How do I check or cap the ARC?

Read the live size first, then set a limit only if other services need the memory. The Proxmox guide uses the same zfs_arc_max parameter.

# current ARC size and its limits, in bytes
grep -E '^(size|c_min|c_max) ' /proc/spl/kstat/zfs/arcstats
arc_summary | head -40

# cap the ARC at 64 GiB until the next reboot
echo $((64 * 1024 * 1024 * 1024)) > /sys/module/zfs/parameters/zfs_arc_max

# keep the cap after reboots
echo "options zfs zfs_arc_max=68719476736" > /etc/modprobe.d/zfs.conf
# only if the root filesystem itself is on ZFS:
update-initramfs -u -k all