# Pika Backup puts a GNOME interface in front of BorgBackup > Pika Backup is a Rust application distributed through Flathub and the GNOME apps site that takes BorgBackup, a well tested deduplicating archiver, and gives it a desktop interface with scheduling, encryption and a file browser for recovery, and its own README is explicit that it saves personal data rather than whole systems. **pika-backup/pika-backup** — Pika Backup – 🪞 Mirror only 🪞 – See https://gitlab.gnome.org/World/pika-backup for development - Repository: https://github.com/pika-backup/pika-backup - Website: https://gitlab.gnome.org/World/pika-backup - Stars: 626 · Forks: 11 - Language: Rust - License: GPL-3.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/pika-backup-pika-backup ## Backups for people who do not want to think about backups Pika Backup's pitch is one line: doing backups the easy way, plug your USB drive in and let the Pika do the rest for you. The features list follows that promise closely. You can create backups locally and remotely, and set a schedule for regular backups. The tool saves time and disk space because it does not need to copy known data again, which is the deduplication behaviour of the archiver underneath. Backups can be encrypted. You can list the archives it has created and browse through their contents, and recover files or folders through the file browser. That last pair of features is the one that separates this from a scheduled command. Browsing an archive and recovering a single file without remembering a command line is what turns a backup from something you set up and hope for into something you can actually use when a file is missing. The distribution story is the GNOME one. There is a Flathub badge, a badge for Apps for GNOME, a GNOME Circle badge, and an Open Collective donation link. The project is part of the Circle, which is the community label GNOME applies to apps that meet its packaging and quality expectations, and the help pages live under the GNOME infrastructure at world.pages.gitlab.gnome.org. The canonical home is on GitLab under the World group, and the GitHub repository is a mirror, with the description stating Mirror only and pointing at the GitLab project for development. The licence is GPL-3.0 and the implementation is Rust. ## Borg does the work, and that is the whole design Pika Backup is powered by BorgBackup, which the documentation calls well tested, and that relationship is the key to how the tool behaves. Because Borg is the engine, the properties a user notices come from Borg. Deduplication, which is why the tool does not need to copy known data again, is Borg's chunk-level content addressing. Encryption is Borg's. Remote repositories, whether on a local network or a hosted provider, are Borg's. The archive format on disk is Borg's, which is the practical point: an archive created by Pika Backup is a Borg repository, and Borg itself can read it. The name Pika comes from the American pika, a small lagomorph that caches food in haypiles, and the README explains the techniques it borrows: storing piles below overhanging rocks, using plants that inhibit bacterial growth as a preservative, and preferring plants with high nutritional value. There is also a line noting that frequent rumours about a connection to a monster with electrical abilities are unfounded, which is a strange sentence to find in a backup tool's README and a sign of what kind of project this is. The limits are stated in the same paragraph as the features. Pika Backup is designed to save your personal data and does not support complete system recovery. That is a real design boundary rather than a missing feature, since a full system backup is a different job with different requirements, and the comparison with the alternatives below makes it clearer. ## The alternatives the project itself names The README has an Alternative Software section, and it is more useful than most projects' competitor lists because it says what differs rather than that the alternatives exist. Vorta is BorgBackup with a Qt frontend, described as being for advanced users. The backend is the same, so the archive format, the deduplication and the encryption are identical, and the difference is entirely in the interface. If you want Borg and you are comfortable with a denser, more technical desktop application, Vorta is the same data with a different shell. Déjà Dup Backups is the other one, with duplicity, which uses librsync, or restic, as the backend, and a GTK frontend like Pika Backup's. So the choice within the GTK world is which archiver you want underneath, and the choice against Vorta is Qt versus GTK. The practical difference between the backends is the one Pika Backup's own feature list hints at. Borg deduplicates across the whole repository, so a backup of your documents, your code and a large media folder re-sends only the parts that changed. Duplicity and restic take different approaches, and the consequence for a user is how much bandwidth and how much space a recurring backup costs, which is the difference between a weekly schedule that is pleasant and one that is expensive. Pika Backup's own pitch to you is the convenience of the default, and the README's other alternative is a manual Borg command line, which is the most powerful option and the least friendly. ## Where the backup space lives The hosting section is about the practical question of where the remote copy lives, and it lists providers with specific support for the Borg technology. BorgBase is named first, and the README says it generously supports the development of Pika Backup. The service is specialised for use with BorgBackup and offers security features such as append-only repositories and two-factor authentication, and there is 10 GB of storage available for free. An append-only repository is the interesting one, because it means the storage side cannot silently lose or rewrite older archives, which is a property a backup provider can offer that a plain filesystem cannot. Other providers are listed after it. rsync.net and Hetzner both offer storage with BorgBackup support, which is the pattern of a general storage box that happens to allow Borg repositories rather than a service designed around them. That distinction is the one to check. A provider that supports BorgBackup is offering you a place to put a Borg repository, and everything else, the deduplication, the encryption, the browsing, the schedule, comes from the software you already have. A provider designed around Borg, like BorgBase, adds the repository-level guarantees on top. The two features of the BorgBase offering, append-only storage and two-factor authentication, are also the two things worth asking any provider about, including a NAS on your own network, because both address a failure mode that a backup does not otherwise protect against, which is the storage quietly changing what you wrote. ## The Rust workspace and what the dependencies reveal The Cargo manifest is a three member workspace: ```toml [workspace] members = ["pika-backup", "pika-backup-common", "pika-backup-monitor"] resolver = "3" ``` The three members are the application, a common library shared between them, and a monitor. The split is a sensible one for a project that also has a non-application component, since a monitoring process that has to coexist with the desktop app should not drag the whole application with it. The shared metadata is a single version for the whole workspace, currently 0.9.0-alpha, on edition 2024 with a minimum rust version of 1.92 and the licence GPL-3.0-only. The alpha in the version is the fact a user should notice, and it applies to the workspace rather than to one crate. The lint configuration is a workspace-wide one, and it is stricter than most: ```toml [workspace.lints.clippy] unimplemented = "forbid" todo = "forbid" ``` Forbidding the unimplemented and todo lints outright is a small policy with a large meaning for a project that promises a working backup, because an unimplemented path in a backup tool is a path where the backup silently does not happen. The release profile is tuned for size and speed, with link time optimisation on and a single codegen unit: ```toml [profile.release] lto = true codegen-units = 1 ``` The dependency list describes the shape of the application. gettext-rs with the system feature is the translation layer, and there is a po/ directory in the repository. nix is used for filesystem, user and signal handling, walkdir for traversal, fancy-regex for pattern matching, serde and serde_ini for configuration, zeroize for clearing secrets from memory, and zxcvbn for password strength, which is a dependency that only makes sense in an application that creates encrypted repositories. The async runtime is smol with async-process for running the backup commands, and tracing with tracing-subscriber handles the logging, with an env filter for debug output. ## Two build systems, one canonical repository, and an alpha label The repository carries two build systems side by side, which is unusual and worth understanding. There is a Cargo.toml for the Rust crates, and there is a meson.build with meson_options.txt and a build-aux/ directory, which is the GNOME packaging path, along with data/ for the desktop data, po/ for translations and a .gitlab-ci.yml for the pipeline. The Rust source lives in the three workspace member directories, and the Cargo.lock is checked in alongside a deny.toml, which is the cargo-deny configuration used to police the dependency licences and advisories. The development location matters for anyone following this project. The README's description of the GitHub repository says Mirror only and points to gitlab.gnome.org/World/pika-backup for development, and the Cargo metadata agrees, with the repository URL pointing at the GitLab project. The homepage is the GNOME apps site. The repository has no GitHub releases, because releases are made from the GitLab project. That arrangement is normal for a GNOME project and it has one practical consequence for an evaluator: the version you find in the GitHub mirror is not where the work happens, so issues and pull requests aimed at the mirror are not the way to contribute. The alpha version label is the other thing to weigh. A workspace at 0.9.0-alpha is close to a first release, which usually means the interface is still moving, and for a backup tool that is the kind of change that deserves a moment of thought, because a schedule that reappears in a new place after an upgrade is a small annoyance and a lost encryption setting would be worse. ## Conclusion Pika Backup fits a GNOME user who wants deduplicating, encrypted backups with a schedule and a point and click recovery path without learning a command line, since Borg is a fine archiver with an unfriendly interface and this is the interface for it. It does not fit someone who needs full system or bare metal recovery, because the project says so plainly, and it does not fit a team that wants Borg's own tooling, since Vorta does the same job for users who prefer a more technical interface. Before switching, read the release stage, since the workspace version is 0.9.0-alpha and development happens on the GitLab repository rather than on the GitHub mirror, and confirm that the provider you use supports the Borg repositories Pika Backup creates. ## FAQ ### What is Pika Backup and what does it use as its backend? Pika Backup is a Rust application that does backups the easy way, and it is powered by BorgBackup, which the documentation calls well tested. The features include local and remote backups, scheduling, encryption, listing and browsing archives, and recovering files or folders through the file browser. ### Does Pika Backup support full system recovery? No. The README states that Pika Backup is designed to save your personal data and does not support complete system recovery. ### What are the alternatives to Pika Backup? Vorta, which uses BorgBackup as its backend with a Qt frontend for advanced users, and Déjà Dup Backups, which uses duplicity, with librsync, or restic as its backend with a GTK frontend. Pika Backup differs in choosing the Borg backend with a GNOME interface. ### Which hosting providers support the Borg repositories Pika Backup uses? BorgBase, which is specialised for BorgBackup, supports its development and offers append-only repositories, two-factor authentication and 10 GB of free storage, and the README also lists rsync.net and Hetzner as offering storage with BorgBackup support. ### Where is Pika Backup developed, and what licence is it under? Development happens at gitlab.gnome.org/World/pika-backup, and the GitHub repository is a mirror only, with the project distributed through Flathub and Apps for GNOME. It is licensed under GPL-3.0, and the workspace version is 0.9.0-alpha on Rust edition 2024. ## Sources - [Issues](https://github.com/pika-backup/pika-backup/issues) - [License: GPL-3.0](https://github.com/pika-backup/pika-backup/blob/main/LICENSE) - [pika-backup/pika-backup on GitHub](https://github.com/pika-backup/pika-backup) - [Project website](https://gitlab.gnome.org/World/pika-backup) - [README](https://github.com/pika-backup/pika-backup/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pika-backup-pika-backup