Requisitos de hardware do Duplicati: CPU, RAM, disco temporário e tamanho da cópia de segurança

Conheça os requisitos de CPU, RAM, disco temporário, tamanho dos blocos e restauro do Duplicati e escolha o hardware ZimaOS adequado para cópias de segurança encriptadas.

Requisitos de hardware do Duplicati: CPU, RAM, disco temporário e tamanho da cópia de segurança

Duplicati requirements at a glance

Duplicati's current documentation says there are no specific requirements for internal memory or processor performance and that the application itself needs about 40 MB of free disk space. That baseline is only the software footprint. Real backup and restore workloads can become much heavier because Duplicati hashes files, compresses/encrypts volumes, maintains local databases and uses temporary disk space during backup, verification and recovery.

CPU
No specific official processor-performance requirement. CPU use rises with SHA-256 hashing, compression level, encryption, database work and restore/recreate operations.
RAM
No specific official memory requirement. Large file sets, backends, database operations and some failure/recovery paths can consume far more memory than a small idle instance.
Application storage
Official community documentation says about 40 MB free disk for the application. Local databases, logs, temp files and backup working space are additional.
Architectures
Current Linux packages support x64, Arm64 and Arm7/ArmHF, covering modern x86 servers, newer ARM systems and older NAS/Raspberry Pi devices.
Temporary storage
Duplicati builds and verifies backup volumes through local temporary files. Temp-space and write load can become a major hardware constraint on large backups.
Best Zima starting point
ZimaBoard 2 832 is a strong starting point for normal personal backups. ZimaBoard 2 1664 or ZimaCube 2 becomes useful when backup sets are large, restores are frequent, temp/database I/O is heavy or the server also hosts many other services.

From official requirements to the right setup

Duplicati sizing begins with dataset shape and backup/restore behavior, not the tiny installed application footprint.

  1. Official requirements

    Count both total bytes and file count. Duplicati chunks files, hashes blocks and tracks metadata in a local database, so millions of small files can stress CPU/database work differently from a few large media files.

  2. Confirm your needs

    Account for compression and encryption. Higher compression settings can spend much more CPU for relatively small space gains on already-compressed media, while hashing/encryption are unavoidable parts of the backup pipeline.

  3. Leave room to grow

    Reserve temporary disk space and fast-enough app/database storage. Duplicati creates temporary volumes locally before upload and uses local databases during backup and restore; temp placement can affect both speed and SSD write volume.

  4. Run it on ZimaOS

    Install Duplicati from the ZimaOS App Store, run a representative initial backup plus test restore/recreate-database operation, and size hardware from the slowest real stage rather than idle container metrics.

Check every playback client

  • Total protected data size
  • Total file count and average file size
  • Compression and encryption settings
  • Remote backend latency/bandwidth
  • Local database size and storage latency
  • Temporary directory capacity
  • Backup versus restore/recreate-database performance
  • Other ZimaOS workloads active during backup windows

Official minimum requirements

Duplicati's documentation is unusually explicit that it does not require a specific processor-performance or memory level.

Duplicati hardware/software prerequisites

The approximately 40 MB disk figure describes the application footprint, not the real backup workstation. Dataset size, file count, temporary volumes, database size, compression/encryption and restore behavior determine practical hardware needs.

RequirementOfficial minimumWhat this supports
CPUNo specific performance requirementDuplicati documentation does not set a minimum processor performance.
RAMNo specific internal-memory requirementNo fixed host RAM minimum is published.
Application diskAbout 40 MB freeThis excludes local databases, temporary files, logs and backup data.
Linux x86x64 packages availableCurrent installation documentation covers common 64-bit Intel/AMD systems.
Linux ARMArm64 and Arm7/ArmHF supportedCurrent packages cover NAS and Raspberry Pi-class systems.
Temporary filesSystem/local temp storage requiredSQLite and backup-volume operations can use the system temporary directory.

When to upgrade your hardware

Upgrade Duplicati when hashing/compression/database/temp I/O or restore time—not idle memory—becomes the actual bottleneck.

Large backups make hashing or compression dominate runtime

Restore or database recreation is unacceptably slow

Temporary files or local database I/O stress the system disk

Duplicati hashes blocks and may compress them before encryption/upload. Community testing shows high compression can cost substantial CPU for minimal benefit on some data types.

Large backup sets and CPU-limited NAS hardware.

Reddit users report restores taking hours despite spare CPU/RAM because the bottleneck can be database/backend operations rather than a simple lack of cores.

Users prioritizing recovery time objectives, not just backup completion.

Duplicati creates temporary volume files locally and can write heavily during backup/verification. On small boot SSD/eMMC volumes, temp capacity and endurance can become more important than RAM.

NAS/container deployments with small system disks.

Plan hardware growth with confidence

Scale Duplicati by separating application database/temp I/O from bulk source and destination storage.

Put the Duplicati database on responsive persistent storage

Backup and restore operations rely heavily on local database state. Faster SSD/NVMe appdata storage can help even when source/destination data live on HDD or cloud/object storage.

Use reliable local SSD/eMMC/NVMe and back up Duplicati configuration/databases appropriately.

Give the temp directory enough capacity

Temporary backup volumes and verification/recovery files can be large. Insufficient temp capacity can fail a job regardless of free space on the final destination.

Reserve temp space based on remote-volume behavior and worst-case job operations.

Tune blocksize and remote-volume size only for a measured reason

Duplicati's docs expose both settings, but changing them affects metadata/database and compaction behavior. Reddit maintainers warn that many common file types gain little from very small blocks.

Benchmark a representative dataset before changing defaults.

Use more CPU/RAM for the backup window, not for idle service

A Duplicati server may look light between jobs yet spike during hashing, compression, encryption or recovery.

Choose 16 GB/Core-class tiers when large backup jobs overlap with many other ZimaOS services.

Can it run on ZimaOS?

Duplicati is currently available in the ZimaOS App Store under Productivity.

Keep database and temp storage visible in your capacity plan

The destination is not the only disk that matters. Local database and system temp paths can consume space and I/O during normal jobs and restores.

Read Duplicati advanced options

Test restores, not just backups

Hardware sizing should include the recovery path. A backup completing quickly does not prove database recreation and restore will meet your recovery-time expectations.

Read Duplicati RecoveryTool documentation

Choose Zima hardware for Duplicati

Duplicati itself has no meaningful fixed hardware floor. Choose hardware from backup volume, file count, temporary I/O, recovery expectations and other services sharing the server.

Are you protecting ordinary personal data, or running large/heavy backup and restore workloads?

Normal personal/family backups

ZimaBoard 2 832 offers ample CPU/RAM for ordinary scheduled Duplicati jobs.

  • Normal scheduled backup serverZimaBoard 2 832
  • Larger jobs and more co-hosted servicesZimaBoard 2 1664
Large backup repository or storage-heavy all-in-one server

Move to ZimaCube for integrated storage, faster database/temp workflows and broader server headroom.

  • Multi-drive backup serverZimaCube 2 Standard
  • Large backup/restore and 10GbE local workflowZimaCube 2 Pro

There is no official Duplicati RAM/CPU minimum or guaranteed backup/restore throughput. Source file count, blocksize, compression, encryption, backend latency, database state and temp storage can all dominate performance.

Zima hardware Best for Example workload Core configuration Recommended boundary Next step
ZimaBoard 2 832 Normal personal and family Duplicati backups. Scheduled encrypted backups with moderate datasets and light co-hosted apps.
CPU
Intel N150, 4 cores, up to 3.6 GHz
Memory
8 GB LPDDR5
Storage
32 GB eMMC plus dual SATA and PCIe expansion
Network
Dual 2.5GbE
Acceleration
No dedicated GPU is required for this workload.
Large restores, millions of files or heavy compression can require more CPU/storage I/O than idle usage suggests. Get Now
ZimaBoard 2 1664 Larger backup sets and a busier Productivity server. More concurrent services, larger local databases and heavier backup windows.
CPU
Intel N150, 4 cores, up to 3.6 GHz
Memory
16 GB LPDDR5
Storage
64 GB eMMC plus dual SATA and PCIe expansion
Network
Dual 2.5GbE
Acceleration
No dedicated GPU is required for this workload.
Extra RAM helps the whole server; Duplicati has no 16 GB requirement. Get Now
ZimaCube 2 Standard A multi-drive local backup and archive server. Large datasets, local backup targets and integrated storage growth.
CPU
Intel Core i3-1215U
Memory
8 GB
Storage
256 GB system storage with six 3.5-inch drive bays and SSD expansion
Network
Dual 2.5GbE
Acceleration
No dedicated GPU is required for this workload.
Choose it for storage capacity and broader backup workflow rather than Duplicati's installed footprint. Get Now
ZimaCube 2 Pro A heavier backup/restore platform with fast local data movement. Large repositories, database/temp work, multiple apps and 10GbE-capable restores/copies.
CPU
Intel Core i5-1235U
Memory
16 GB
Storage
256 GB system storage with six 3.5-inch drive bays and SSD expansion
Network
Dual 2.5GbE plus 10GbE on the current Pro configuration
Acceleration
No dedicated GPU is required for this workload.
10GbE only helps when source, destination and storage can sustain it. Get Now

What the Press Says

Highlights from trusted reviewers worldwide.

La Razón
“ZimaCube 2: Not just another NAS, tested with 25TB storage, local AI agents, 4K transcoding, and real homelab workflows.”
Read full review
GameRevolution
“The ZimaBoard 2 is a compact x86 server board that can be turned into a mini NAS, home server, media box, or self-hosting hub.”
Read full review
TechRadar Pro
“ZimaCube 2: A modern, high-performance NAS with plenty of room to grow—built for users who want more than basic storage.”
Read full review
FOX 8
“Coverage focused on ZimaCube 2's open hardware foundation, no monthly fee, and self-hosting flexibility.”
Read full review

Loved by the Community

Stories and reviews from people who build with Zima every day.

ZimaBlade single-board server
★★★★★

Zima Blade Little yet Powerful

Maybe I am not digital natives but I live with PCs since 12 years old in 1984 when IBM PC clone come to my home. Many years have passed and many operating system I've tried. For me Zima blade and CasaOS was a quantum leap for home PC enthusiast and server lab machine to make me stay curious and relevant for this era.

ZimaCube Pro personal cloud
★★★★★

Very good!!

I use ZimaCube Pro as 5th Proxmox cluster node. It runs several VMs and containers, including a VM with GPU passthrough to run a self-hosted LLM. A specific LXC container runs a Samba server for NAS capabilities using four of six RAID 6 SATA HDDs with ZFS.

ZimaBlade single-board server
★★★★★

Great innovation for mini server!

It is very useful and makes a powerful mini server for many purposes, including university and college students in engineering and electronics. Thank you so much for making this server.

ZimaBoard 2 single-board server
★★★★★

Avaliação ZimaBoard 2

Construí um servidor de uso pessoal. O desempenho está muito bom e funciona perfeitamente onde quer que eu esteja. A surpresa é não dependermos de grandes estruturas para termos nosso próprio servidor de dados. Como iniciante, estou gostando bastante do ZimaOS, pois ele é simples e eficiente.

Frequently asked questions

These FAQ topics follow query fan-out around RAM limits, slow restores, memory growth, temp files, SSD wear and blocksize. Reddit and Duplicati forum discussions were used to identify real pain points; official documentation remains the authority for requirements.

How much RAM does Duplicati need?

Duplicati's documentation says there are no specific internal-memory requirements. Small jobs can run in limited containers, while large datasets, local databases and recovery operations can consume far more memory.

Can Duplicati run with a 512 MB or 1 GB container limit?

Some users report 512 MB to 1 GB working for modest jobs, but others hit out-of-memory conditions on large backends or metadata operations. Treat a low container cap as something to validate with your actual backup and restore workload, not a safe universal minimum.

Why can Duplicati keep using a lot of RAM after a backup?

Community reports include cases where process memory remains high after a job. Runtime memory management and database/backend work can make observed RAM larger than the active backup stage; investigate version, logs and real process memory before simply adding RAM.

Why is Duplicati restore slow even when CPU and RAM are mostly idle?

Restore speed can be limited by remote-backend latency, local database recreation, metadata lookup, small-file operations and destination storage rather than CPU utilization alone. More cores do not automatically fix an I/O- or database-bound restore.

How much temporary disk space does Duplicati need?

There is no one fixed amount. Duplicati assembles local backup volumes and can download/verify temporary data during maintenance and recovery. Reserve meaningful free space on the temp filesystem instead of counting only the final backup destination.

Can Duplicati cause heavy SSD writes?

Yes. Duplicati's temp-volume workflow can generate substantial local writes during large backups and verification. Put temporary data on storage whose capacity/endurance matches the workload rather than a nearly full boot SSD.

Should I change Duplicati blocksize or remote volume size for better performance?

Only for a measured reason. Smaller blocks increase metadata/database overhead, while changing remote-volume size affects upload/compaction behavior. Current community maintainer guidance says many compressed file formats gain little from aggressively small blocks.

Can ZimaBoard 2 832 run Duplicati?

Yes for normal personal/family backup workloads. Its Intel N150 and 8 GB RAM provide substantial headroom; storage layout, temp space and restore requirements are more likely to determine when you need a larger server.

What sources and further reading informed this Duplicati hardware guide?

Duplicati's current documentation supplies the key baseline: no specific CPU/RAM performance requirement, about 40 MB application disk, and current x64/Arm64/Arm7 packaging. Advanced options document blocksize and temp behavior. Reddit and the Duplicati support forum were used for query fan-out around OOM, memory retention, restore speed and temp/SSD pressure; those cases are not treated as universal minimums. The ZimaOS App Store confirms the current Productivity app.

  1. Duplicati Community Docs - Introduction
  2. Duplicati - Installation
  3. Duplicati - Advanced Options
  4. Reddit - Duplicati Backup/Restore Performance Discussion
  5. Duplicati - ZimaOS App Store