Documentation

Everything you need to get pinemere running. Start with installation, then work through the quickstart.

Overview Installation

What pinemere does

Pinemere is a file synchronization tool that uses content-addressed storage and Merkle-tree deduplication. Instead of comparing file paths and timestamps (like rsync), it hashes file contents into blocks and only transfers blocks that don't already exist at the destination.

The result: moving, renaming, or duplicating files costs almost nothing to sync. If two files share content (even partially), the shared blocks are stored and transferred once.

Core concepts

Pools

A pool is a directory that pinemere manages. When you run pinemere init ./photos, pinemere creates a hidden .pinemere/ directory inside ./photos containing the block index (a SQLite manifest) and configuration. The pool tracks every file's content hash and block map.

Targets

A target is a remote (or local) destination where pinemere sends data. Targets are defined in pinemere.toml at the pool root. Each target has its own retention policy and sync schedule. During sync, pinemere queries the target for its block inventory, computes the diff, and streams only missing blocks.

Blocks

Files are split into variable-size blocks using Rabin fingerprinting (target size: 64 KB, range: 32–128 KB). Each block is identified by its BLAKE3 hash. Blocks are the unit of deduplication — if two files share a 64 KB region, that region is one block referenced twice.

Quick example

$ pinemere init ./photos
  Initialized pool  (1,247 files indexed, 8.3 GB)

$ pinemere add-target nas --path /mnt/nas/photos-backup
  Target 'nas' added

$ pinemere run --target nas
  Resolving manifest ...  done
  Streaming changes   ...  1,247/1,247
  Verifying parity    ...  ok

  ✓ done in 4m12s   peak 94.2 MB/s   dedup ratio 1.00x

$ # Later, after adding 30 new photos and renaming a directory:
$ pinemere run --target nas
  Resolving manifest ...  done
  Streaming changes   ...  30/30    (1,217 skipped — already present)
  Verifying parity    ...  ok

  ✓ done in 0.8s   peak 38.1 MB/s   dedup ratio 42.6x

The second sync transferred only the 30 new photos. The renamed directory was recognized by content hash — zero bytes transferred for those files.

Next steps