ZFS vs Btrfs for Snapshots, Replication and Incremental Retention on VPS with Docker — Practical Pros and Cons

By Kevin Marcondes · Published on Oct 28, 2026 · 9 min read

This comparison of ZFS vs Btrfs for snapshots, replication and incremental retention on VPS with Docker explains, in practical terms, how each filesystem handles copy-on-write, send/receive workflows and retention policies. You’ll see RAM and I/O impacts, Docker integration details and recommended scenarios. The goal is to help you choose with clear criteria and lower operational risk.

Selection criteria focused on VPS with Docker

On a VPS you want consistent snapshots, reliable incremental replication and retention that’s easy to maintain — all without consuming excessive RAM or degrading container I/O.

ZFS and Btrfs are copy-on-write filesystems. That enables fast snapshots and compression with checksums for data and metadata. Each has different costs, limits and tooling.

Before choosing, frame the problem: what matters most in your environment? Cross-region replication? Low RAM? Databases running in containers? An immutable VPS kernel?

• Snapshot consistency: impact on databases and queues.
• Incremental replication: resuming after network failures.
• Retention: rotating daily/weekly snapshots without fragile scripts.
• Available RAM: ARC impact on ZFS and caches in Btrfs.
• Operability: tooling, monitoring and recovery.
• Compatibility with the kernel and Docker storage driver.

Snapshots and retention: how each filesystem works

ZFS uses datasets. Snapshots are instant and cheap because they only record deltas. You can apply retention policies using naming conventions and scripts, and protect snapshots with "holds" to avoid accidental deletion.

Btrfs uses subvolumes. Snapshots are also fast and space-efficient. Subvolume partitioning helps isolate what goes into a snapshot, for example /var/lib/docker/volumes/project.

In both systems, incremental retention is a business policy: define hourly, daily and weekly windows and automate cleanup. Combine with offsite backups for ransomware or disaster scenarios; see the VPS Linux security base in the VPS Linux security checklist.

For hot volumes, coordinate snapshots with the application. For databases, prefer hooks that flush pages or create consistent windows. That reduces the risk of slow recovery.

Incremental replication: ZFS send/receive and btrfs send

ZFS provides a mature send/receive incremental mechanism. It works well for replication between VPS instances, with features like bookmarks and resuming interrupted sends. If you use native encryption, you can replicate in "raw" mode without decrypting the dataset.

Btrfs supports btrfs send, including incremental sends between ancestral snapshots. In practice the tool handles subvolume replication adequately. The ecosystem is smaller, and resuming transfers often requires external wrappers.

In either case, limit the replication scope. Replicating only the containers’ persistent volumes reduces windows and traffic. Use predictable snapshot names to automate incrementals. For a block+object alternative, see LVM snapshots + Restic to S3.

Validate restores periodically. Replication without restore tests is an operational risk. Keep a clear playbook to mount volumes and bring containers up on the target.

Performance, RAM and stability on VPS

ZFS delivers advanced features but consumes RAM through the ARC. On small VPS instances, tune cache limits to avoid memory pressure for containers. LZ4 compression helps reduce I/O without a large CPU cost.

Btrfs tends to be lighter on memory. It also offers transparent compression and checksums. Behavior under random load depends on subvolume layout and the containers’ write patterns.

Copy-on-write affects databases. On Btrfs it’s common to disable CoW on specific directories when latency is critical, but you lose checksums on those paths. On ZFS, tuning recordsize and atime can help database workloads.

On VPS the provider’s storage layer sets the ceiling for IOPS and latency. The filesystem won’t overcome those physical limits. Measure and monitor before enabling heavy features like global deduplication, which rarely pays off on VPS. For sizing guidance, see how to choose the right VPS size.

• Tune compression per dataset/subvolume according to workload.
• Avoid inline deduplication on ZFS for small VPS instances.
• Monitor fsync and flush latency on database volumes.
• Test real workloads, not just synthetic benchmarks.

Docker integration: drivers and volume layout

Docker uses overlay2 by default on ext4/xfs. Both ZFS and Btrfs can be the underlying filesystem and you can still snapshot the datasets/subvolumes that contain Docker volumes.

Using Docker’s native ZFS or Btrfs storage driver ties snapshots into the image lifecycle, but increases operational complexity. Many teams prefer overlay2 and take filesystem-level snapshots for persistent volumes.

Structure layout to reflect services. Create datasets/subvolumes per application or per critical volume. Separate transient data from persistent data to keep snapshots small and replications fast.

Schedule scrubs and collect I/O metrics. Add alerts when replication backlogs grow. That avoids surprises during maintenance windows.

• Put /var/lib/docker/volumes into separate datasets/subvolumes per critical project.
• Exclude caches and ephemeral artifacts from snapshots.
• Use predictable snapshot names with timestamps and windows (e.g., hourly-...).
• Automate pre/post-snapshot hooks for consistency in sensitive apps.

Reliability and recovery: checksums, scrub and testing

ZFS and Btrfs provide checksums for data and metadata. Regular scrubs detect and, when redundancy exists, correct silent corruption. Even on single-disk setups, scrubs surface issues early.

Recovery relies on good snapshots and documentation. Have a runbook to mount the replicated dataset/subvolume, restore permissions and reattach volumes to containers.

Plan verification windows. Restore into an isolated environment and validate services. Tune retention based on those exercises. To cover disaster and ransomware, complement snapshots with encrypted incremental backups to S3.

• Schedule scrubs during low load.
• Perform sample restores monthly.
• Version snapshot/replication scripts.
• Audit deletions and protect important snapshots with holds.

Comparative table: what changes in practice

Below is an objective summary of the most relevant differences for snapshots, replication and incremental retention on VPS with Docker.

Recommendations by scenario

If the priority is robust incremental replication between VPS instances and you need native encryption with raw send, ZFS is usually the more straightforward choice.

If the VPS has limited RAM and you want simple snapshots via subvolumes and light compression, Btrfs is often more practical.

For databases in containers, evaluate CoW impact. On Btrfs, disabling CoW per directory sacrifices checksums. On ZFS, tune recordsize and compression to match the write profile.

If the infrastructure enforces an immutable kernel or blocks external modules, built-in Btrfs support in the kernel is advantageous. When ZFS is available and supported, it provides wider tooling.

For long-term incremental retention, combine local snapshots with offsite incremental backups. That reduces data loss windows and covers physical disasters.

• Start small: dedicate datasets/subvolumes for critical volumes.
• Automate snapshots and cleanup using hourly/daily windows.
• Monitor latency and RAM after enabling compression.
• Validate a full restore before standardizing the approach.

Frequently asked questions

Can I use ZFS or Btrfs on any VPS?

You need root access and a kernel with support. Some providers restrict external modules. Btrfs is included in the kernel; ZFS depends on a module compatible with the VPS image's kernel.

Which uses more RAM: ZFS or Btrfs?

ZFS typically uses more RAM because of the ARC. On small VPS instances, limit the cache and avoid heavy features like deduplication. Btrfs is usually lighter in default configuration.

Should I use Docker’s zfs/btrfs driver or overlay2?

To keep things simple, many teams use overlay2 and take snapshots at the filesystem level for persistent volumes. Docker’s zfs/btrfs drivers integrate snapshots but increase operational complexity.

Do databases in containers work well with COW?

They can, but you’ll need tuning. On Btrfs, disabling CoW for specific directories reduces latency but removes checksums. On ZFS, tune recordsize and compression for the database’s write pattern to limit impact.

Do snapshots replace offsite backups?

No. Snapshots are great for quick local recovery and replication. Offsite backups cover disasters and ransomware. Use both: frequent snapshots plus encrypted incremental copies to external storage.

How do I define an efficient incremental retention policy?

Adopt simple windows like hourly-daily-weekly and use predictable snapshot names. Automate cleanup and run a sample restore monthly. Adjust the policy based on usage metrics and restore tests.

See also

• ZFS vs LVM+LUKS on VPS for Databases — snapshots, performance and post-failure recovery
• Practical comparison — Nginx Unit vs PHP‑FPM vs RoadRunner for PHP monoliths in containers — latency, throughput & memory
• nftables vs iptables on Ubuntu 22.04: which to use and practical examples
• Flyway vs Liquibase vs Sqitch: database versioning for PHP/Laravel projects