Vykar is a Rust backup tool with a YAML config, a GUI and its own format

Borg's ideas on a different disk format

Vykar is described as a fast, encrypted, deduplicated backup tool written in Rust, centred around a friendly YAML config file. The README names its inspirations directly: BorgBackup, Borgmatic, Restic and Rustic.

What it does not inherit is the format. The README is explicit that Vykar uses its own on-disk format and is not compatible with Borg or Restic repositories. That single sentence changes the adoption conversation. A Borg or Restic user cannot point Vykar at an existing repository, cannot read a Vykar repository with their current tools, and cannot assume that a future Borg feature will apply to it.

In exchange, the project is free to make its own choices, and the feature list shows what it made. Storage backends are the local filesystem, S3 with any compatible provider, SFTP and a dedicated REST server. Encryption is AES-256-GCM or ChaCha20-Poly1305, auto-selected, with Argon2id key derivation. Compression is LZ4 or Zstandard. The language is Rust, the licence is GNU General Public License v3.0, and the documentation lives at vykar.borgbase.com.

It is a young, opinionated rewrite rather than a compatible successor, and the rest of the README reads that way.

The README says do not use it for production yet

The most important line in the README is a warning, and it should shape any decision: don't use for production backups yet, but do test it along other backup tools.

That is an unusually direct statement from a project with a version number at 0.20.1, a desktop GUI, a REST server, a daemon and a fuzzing setup. It tells you the project intends to be used, and to be exercised against real data, without asking you to trust it with the only copy of anything.

The advice itself is reasonable, and it is the advice you would give for any new backup implementation. A backup tool's correctness is not demonstrated by a feature list; it is demonstrated by restoring what you backed up and comparing the result. Until the project says otherwise, the sensible posture is to run Vykar alongside whatever you already use, back up the same data to both, and confirm that a restore from Vykar gives you what you need.

The benchmark section deserves the same scepticism. The README says Vykar leads in both speed and CPU efficiency while maintaining competitive memory usage, and describes the test conditions, an idle Intel i7-6700 at 3.40GHz with two Samsung PM981 NVMe drives, with compression settings chosen to keep repository sizes comparable. That is the project's own measurement of its own tool against its own corpus, and it is a reason to look, not a reason to decide.

Chunking, encryption and compression are the core choices

Deduplication in Vykar is described as content-defined chunking with FastCDC, a memory-optimised engine with a tiered dedup index and mmap-backed pack assembly. Content-defined chunking is the mechanism that makes deduplication work on rolling data, since the boundaries follow the content rather than fixed offsets, and the two implementation details, a tiered index and mmap-backed assembly, are about keeping the index and the pack files from becoming the bottleneck.

Encryption is applied with AES-256-GCM or ChaCha20-Poly1305, auto-selected, and Argon2id for key derivation. The choice between two AEAD ciphers removes an argument from the configuration file, and Argon2id is a memory-hard function, which is the right family of choice for turning a passphrase into a key.

Compression is LZ4 or Zstandard, which is a speed versus ratio decision, and again a per-repository choice rather than a global one.

The crate list in the workspace file backs this up. The `vykar-crypto` crate exists, and the crypto dependencies include `blake2`, `blake3`, `rand` and `zeroize`, the last being the crate that scrubs key bytes from memory on drop. Storage is a separate crate, `vykar-storage`, and the common, types, core, cli, server, gui and protocol crates cover the rest.

The REST server and concurrent clients

The storage side is the most distinctive part of the design. Alongside the local filesystem, S3, SFTP, a dedicated REST server and built-in WebDAV, Vykar covers the storage side, and the README describes it with three specific properties: append-only enforcement, quotas, and server-side compaction.

Each of those addresses a real problem with backup servers. Append-only enforcement means a client cannot rewrite or delete previously stored data, which is what makes a repository resistant to a compromised client. Quotas bound what a client can store. Server-side compaction reclaims space without shipping every pack file back to a client to be rewritten.

The second property is concurrency. The README describes concurrent multi-client backups, where multiple machines back up to the same repository simultaneously, and only the brief commit phase is serialized. That is the design that makes a shared backup repository practical: the slow part, transferring and packing data, runs in parallel, and the part that needs exclusive access, the commit, is short.

The Rust workspace has dedicated `vykar-server` and `vykar-protocol` crates for this, and the Docker image copies both a `vykar` and a `vykar-server` binary, so the server is a first class component rather than a script.

One YAML file is the source of truth

The configuration story is what separates Vykar from a plain Borg style command line. The README describes YAML-based configuration with multiple repositories, hooks, and command dumps for monitoring and database backups. Multiple repositories in one file means a machine that backs up to more than one place is not a wrapper script. Hooks cover the neighbouring tasks, and command dumps give you the database dump that belongs next to the files.

The desktop GUI keeps the same file as its source of truth and auto-reloads configuration changes, so an edit made in a text editor takes effect without restarting anything. The GUI itself, `vykar-gui`, is a Slint-based desktop app that uses `vykar-core` directly rather than shelling out to the CLI, which is why it can offer system tray behaviour and periodic background backups without going through a subprocess.

Scheduling lives in the same file:

schedule:
  enabled: true
  every: "24h"
  on_startup: false
  jitter_seconds: 0

The `jitter_seconds` setting is the kind of detail that shows the tool is meant for fleets. Without jitter, every client configured for a 24 hour cycle starts at the same moment, and the storage backend takes the same hit at the same moment. A jitter field is a small thing that only matters at scale.

Installing it and running the first backup

The quick start is one command:

curl -fsSL https://vykar.borgbase.com/install.sh | sh

Alternatively you can download the latest release for your platform from the releases page, and a Docker image is also available. Once it is installed, the sequence in the README is:

# Generate a starter config and edit it
vykar config

# Initialize the repository and run a backup
vykar init
vykar backup

# List snapshots
vykar list

The order matters. `vykar config` writes a starter configuration, which is where the repositories, the encryption settings and the schedule go. `vykar init` creates the repository on the chosen backend, and `vykar backup` then sends data to it.

Scheduling does not need cron. The README describes a built-in scheduler via `vykar daemon`, which runs backup cycles on a configurable interval, with an optional read-only HTTP status page documented in the daemon documentation. The Dockerfile shows how that is exposed: it is based on alpine, it declares port 7575 for the status page, and the comment explains that exposing the port does not bind it, since you opt in by setting `VYKAR_HTTP_LISTEN`, and for non-loopback addresses you also need `VYKAR_HTTP_ALLOW_PUBLIC=1`. The image entrypoint is `vykar` with the command `daemon`.

Nine crates, a fuzzing target list and a GPLv3 licence

The workspace file shows how the project is organised, and it is a good indicator of where the complexity sits. There are nine crates: `vykar-types`, `vykar-common`, `vykar-crypto`, `vykar-storage`, `vykar-core`, `vykar-cli`, `vykar-server`, `vykar-gui` and `vykar-protocol`, with the `fuzz` directory excluded from the workspace. The shared package metadata says version 0.20.1, edition 2021, rust-version 1.98, licence GPL-3.0-only and `publish = false`, so the crates are not published to a registry.

The Makefile shows the quality gate. There are targets for `fmt`, `fmt-check`, `lint` using clippy with warnings denied, `test`, `test-all` for the ignored tests, `doc-check` with rustdoc warnings denied, and a `pre-commit` target that chains fmt-check, lint, doc-check and test-all together. There is a `fuzz` target that runs a named list of targets for 60 seconds each, among them `fuzz_pack_scan`, `fuzz_decompress` and `fuzz_msgpack_index_blob`, plus a `fuzz-check` target that replays the corpus without running. For a tool that parses untrusted archive formats, a fuzzing setup with named targets is a meaningful part of the engineering, and it is the part of this repository that most directly addresses the warning in the README.

The rest of the repository supports the same picture: a `docs/` directory built with mdbook, a `Dockerfile.apprise` for notification, a `flake.nix` and `shell.nix`, a `prek.toml` for pre-commit hooks, `scripts/`, `testing.md`, `vykar.example.yaml`, and a `Makefile` target that builds a macOS app bundle for the GUI.

Licence wise, the README states GNU General Public License v3.0, and the workspace metadata says GPL-3.0-only, which is the stricter reading of the two. Security issues go to [email protected]. The repository is not archived, the last push was on 2026-10-15, and the recent tags are v0.20.1 from 2026-09-10, v0.20.0 from 2026-09-09 and v0.19.1 from 2026-07-31.

Editorial conclusion

Adopt Vykar when you want to evaluate a modern backup tool with one YAML file as the source of truth, a GUI for browsing snapshots, and a daemon that schedules backups without cron, and when you are willing to start from an empty repository. Do not adopt it as your only copy of production data while the README still says not to use it for production backups, and do not expect to migrate an existing Borg or Restic repository into it. Verify first that the version you install matches v0.20.1, that your storage backend and the encryption and compression settings in `vykar.yaml` match what you need, and that the restore path has been tested by you, since the on-disk format is Vykar's own and nothing else can read it.

Frequently asked questions

Official sources

1. borgbase/vykar on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases