parsync: a pull-only sync tool that resumes over SSH and can take an RDMA shortcut

parsync only pulls, and that narrowness is the design

parsync is aimed at engineers who mirror a remote directory onto a local machine over SSH and who have been disappointed by how slowly the usual tools handle it. The project describes itself as a high-throughput, resumable sync tool for SSH remotes and local to local transfers, with parallel file transfers, optional block-delta sync, and a Linux RDMA fast path when both hosts support it. The single most important constraint is visible in the description of the tool: it is rsync-like but pull-only. There is no push mode and no two-way reconciliation in what the README documents, so the tool fits pipelines that copy outward from a server rather than workflows that need to merge edits back. It is also a Rust project published under the MIT licence, with documentation hosted on docs.rs.

Parallel transfers with optional block-delta and a SQLite state store

The mechanics show up in the dependency list rather than in prose. `rayon` at version 1.10 provides the parallelism for file transfers, `glob` handles pattern expansion on the remote side, and `indicatif` supplies progress output during long copies. Delta behaviour relies on hashing crates, with `md5` and `xxhash-rust` using the xxh3 feature, and block-delta sync is described as optional rather than default. A bundled `rusqlite` gives the tool an embedded database, which fits a resumable workflow where state has to survive a dropped connection rather than live only in memory. Networking runs through `ssh2` with the vendored-openssl feature, so the SSH stack does not depend on the OpenSSL version already installed on the machine, and `ctrlc` is present for handling interrupts. Configuration is parsed with `toml` and `serde_json` handles JSON output.

Three install paths, and the binary is the fastest to try

The README lists a one line installer for Linux and macOS that downloads and runs a script:

curl -fsSL https://alpindale.net/install.sh | bash

Piping a remote script into a shell is convenient but it does mean the binary arrives without you inspecting the file first, so a security conscious team may prefer the Rust toolchain path. Cargo is supported directly:

cargo install parsync

Building from a checkout of the source is the third route, and the Makefile in the repository defines both a `build` target that runs a release build and an `install` target that installs from the current path:

make build
make install

Prebuilt binaries for each supported platform are also published on the releases page. The install targets are unsigned as far as the README describes, since it says nothing about signatures or checksums.

The command line borrows rsync flags and adds an SSH spec

A transfer is expressed as a remote spec and a local destination, with rsync style flags in front:

parsync -vrPlu [email protected]:/remote/path /local/destination

A non default SSH port is expressed by inserting the port into the host part of the spec rather than by passing an SSH option:

parsync -vrPlu [email protected]:2222:/remote/path /local/destination

SSH config host aliases are supported, so a `Host` entry in your own config can stand in for `[email protected]`. What the README does not spell out is how the `-u` style flags map onto parsync's own behaviour, whether there is a dry run mode, or how deletions on the remote side are treated at the destination. The flags are recognisable to anyone who has used rsync, which lowers the learning curve, but the details a script depends on are not spelled out in the documentation.

The RDMA path is Linux only, opt in by default, and limited to large files

The fastest route is a direct RDMA transfer that skips the SSH stream. When RDMA devices and rdma-core `librdmacm` rsockets are available on both hosts, parsync opens a local RDMA receiver and starts `parsync --internal-rdma-send` on the source host over SSH, falling back to the normal SFTP and chunk transfer when RDMA is unavailable. The mode is `auto` by default for SSH sources, and the fast path only applies to files of at least 64 MiB, which means a directory of many medium files will never touch it. The CLI exposes four controls:

parsync --rdma=require [email protected]:/remote/path /local/destination
parsync --rdma=off [email protected]:/remote/path /local/destination
parsync --rdma-bind 10.10.0.12 [email protected]:/remote/path /local/destination
parsync --rdma-min-size 1048576 [email protected]:/remote/path /local/destination

`--rdma=require` turns the fast path into a hard requirement, `--rdma=off` disables it, `--rdma-bind` pins the local IPv4 address when the RDMA fabric uses a different one from the SSH route, and `--rdma-min-size` changes the size threshold. The same settings exist as the environment variables `PARSYNC_RDMA`, `PARSYNC_RDMA_BIND`, `PARSYNC_RDMA_MIN_SIZE` and `PARSYNC_RDMA_HELPER`, and as the config file keys `rdma_mode`, `rdma_bind`, `rdma_min_size` and `rdma_helper`.

The RDMA path can be exercised with a software RDMA driver

You do not need RDMA hardware to check whether the fast path works. The README notes that the Linux RXE software RDMA driver, `rdma_rxe`, together with rdma-core installed can stand in for real hardware, and it points at an ignored integration test that wraps a virtual machine validation:

cargo test --test rdma_rxe_vm -- --ignored

Running it with `-- --ignored` is required because the test is excluded from the default run. The Makefile's `test` target shows the same pattern for the other slow suites, running the normal test set first and then the ignored SSH daemon and performance smoke tests. RDMA support, including the CLI controls and the internal helper, is not built on Windows or on other non-Linux platforms, so on macOS the binary exists but the fast path does not.

Platform support splits into a portable path and a Linux-only one

The build targets listed in the README are `x86_64-unknown-linux-gnu` and `aarch64-unknown-linux-gnu` for Linux, `aarch64-apple-darwin` and `x86_64-apple-darwin` for macOS, and `x86_64-pc-windows-msvc` for Windows, where metadata support is described as best effort. The Cargo manifest reflects that split in its target specific dependency tables: Unix builds pull in `nix` for user, filesystem, signal and process handling along with `xattr` for extended attributes, while Windows builds depend on `windows-sys` for foundation and thread management features. Preserving ownership, permissions and extended attributes is the kind of detail that matters when a mirror has to look like the original, and the Unix path is where that work is concentrated.

The version in Cargo.toml trails the newest release tag

parsync is young and moving quickly. The release list shows v0.1.0 and v0.2.0 both dated 2026-03-05, a few hours apart, and v0.3.0 on 2026-08-13, with the last push also on 2026-08-13. That date is recent enough that the project is not abandoned, but the version field in the Cargo.toml at the repository root still reads 0.2.0 even though a 0.3.0 tag exists, so a build from source and an installed release can report different versions. The API and command line may therefore still shift between minor versions. The MIT licence keeps adoption straightforward for commercial use, with no copyleft obligation and no runtime fee, and the documentation lives on docs.rs for anyone reading the crate before installing it.

Editorial conclusion

parsync fits a specific job: mirroring a remote directory to a local disk over SSH where interrupted transfers are common and the source is a large repository. It is the wrong choice for pushing, for two-way sync, or for a Windows host that needs the fast path, since RDMA support is not built there. Before adopting it, compare `parsync -vrPlu` against the rsync invocation you use today on a directory with a few very large files, because the 64 MiB RDMA threshold and the auto mode default mean the behaviour you get depends on file size and on RDMA availability on both ends. Also pin a version deliberately: the newest tag is v0.3.0 from 2026-08-13 while the version field in Cargo.toml still reads 0.2.0.

Frequently asked questions

Official sources

1. AlpinDale/parsync on GitHub
2. Issues
3. License: MIT
4. README
5. Releases