Three open source tools can back up a server, but they don't cover the same data. restic and Plakar store files in an encrypted, deduplicated repository, run from the command line and come with no scheduler: restic writes to S3, SFTP or Backblaze B2 out of the box, while Plakar adds a web UI and database connectors that you install as packages. Databasus only backs up PostgreSQL, MySQL, MariaDB and MongoDB, from a web interface that schedules jobs, applies retention and checks each backup by restoring it.
File backup or database backup
restic and Plakar read directories, split them into chunks and only write the chunks the repository doesn't already hold. Each run creates a snapshot you can list, compare or mount over FUSE to pull out one file without restoring the rest. Even so, Plakar pitches itself as the next step: its post A Short history of backup groups restic with Borg, Duplicity, Tarsnap and Kopia, then says most of them needed a full restore to reveal their contents, which restic doesn't.
restic only sees a database through the output of a command such as pg_dump. With --stdin-from-command, a failed dump cancels the snapshot; with a plain pipe into restic backup --stdin, the docs warn that a dump that fails still ends in an empty snapshot. Plakar runs pg_dump or pg_basebackup itself through its PostgreSQL connector, as long as those client tools are installed on the backup host, and also reads MySQL, MongoDB, etcd and Kubernetes, so files and databases end up in the same repository.
Databasus comes at it from the other side and backs up no files or directories at all. From PostgreSQL 17 onward, it chains a full backup, block-level incrementals and continuous WAL streaming over the replication protocol, with nothing installed on the database host, so a restore can target any given second. MySQL, MariaDB, MongoDB and PostgreSQL before 17 get a full dump on every run. The project targets teams that want a UI, per-workspace roles and a setup that doesn't call for PostgreSQL expertise, and its comparison with pgBackRest points anyone who needs physical backups before PostgreSQL 17, differential backups or delta restore to pgBackRest instead.
Encryption, deduplication and storage targets
restic, Plakar and Databasus all encrypt backups before they reach storage. restic encrypts everything it writes with AES-256 in CTR mode and authenticates it with Poly1305-AES, under a key derived from the password with scrypt; its README assumes other people, system administrators included, can get at the storage. Plakar encrypts data and metadata by default, and since v1.1.5 refuses to open an unencrypted repository unless PLAKAR_INSECURE_PLAINTEXT is set; the audit of its cryptography, published in February 2025, found no major security issue. Databasus encrypts each backup with AES-256-GCM, under a key derived from its secret.key file. Forget restic's password and the data is gone for good; for Databasus, the README advises copying secret.key right after installation, so backups can still be restored if the Databasus server is lost.
Deduplication is where the two families part ways. In a restic or Plakar repository, a chunk that is already there isn't written again, and several machines can back up into the same restic repository, where a shared chunk is stored once. Databasus documents no deduplication: each logical backup is a full dump compressed with zstd, and only the PostgreSQL 17 physical incrementals are limited to what changed since the last full backup.
restic writes without plugins to a local disk, SFTP, S3 and compatible services, OpenStack Swift, Backblaze B2, Azure Blob Storage, Google Cloud Storage and rest-server, the project's own HTTP server, with rclone for everything else. Started with --append-only, rest-server rejects any deletion, so a compromised machine can't wipe its older backups. Plakar covers S3, SFTP, Azure Blob Storage, Google Cloud Storage, an OCI registry and rclone, but through connectors that aren't in its binary, which only ships base connectors such as the filesystem one. Those connectors install with plakar pkg add, which fails without a Plakar account, or get built from source with git, make and Go into an unsigned package. Databasus sends backups to a local disk, S3 and compatible services, Cloudflare R2, Google Drive, Azure Blob Storage, a NAS, FTP, SFTP and rclone.
What each tool needs to run
Read from the repositories and documentation on 7 October 2026.
| Tool | Licence | What you run | What it backs up | Scheduling | Latest release |
|---|---|---|---|---|---|
| restic | BSD-2-Clause | one Go binary, no server; rest-server optional | files; databases through a dump's output | none: cron, systemd timer | 0.19.1, 5 Jul 2026 |
| Plakar | ISC | one Go binary and its cache process; connectors as packages, with an account or built from source | files; PostgreSQL, MySQL, MongoDB, etcd, Kubernetes through connectors | none since 1.1: cron, or Plakar Control Plane | 1.1.7, 24 Sep 2026 |
| Databasus | Apache-2.0 | one Docker container bundling its own PostgreSQL 17; at least 1 core, 500 MB of RAM and 5 GB of disk | PostgreSQL, MySQL, MariaDB, MongoDB; no files | built in, hourly to monthly or a cron expression | 3.60.0, 22 Sep 2026 |
Plakar publishes a measurement of its footprint: on a one-million-item dataset, the v1.1.3 changelog records a peak of about 1.3 GiB of RAM during backup, 1.7 GiB during sync and 800 MiB during restore, with a default on-disk cache of about 1.8 GiB. Databasus verifies backups through an agent that runs on a machine with Docker and HTTPS access to the instance, and asks for at least 1 CPU core and 512 MB of RAM per concurrent check.
Scheduling, retention and restore tests: what each tool leaves to you
restic and Plakar don't start anything on their own. restic's docs say it plainly: it runs when you call it and is not a daemon. Cron, a systemd timer or Windows Task Scheduler triggers it, and your script has to make sure two runs never overlap. Plakar's 1.1 branch dropped the scheduler that shipped in 1.0, which the pull request that removed it calls unusable as is, and points to cron as well; centralised scheduling belongs to Plakar Control Plane. Databasus schedules each database from its interface and reports results by email, Slack, Telegram or webhook.
Retention in restic takes two steps: restic forget drops snapshots according to rules such as --keep-daily, --keep-weekly or --keep-within, then prune deletes the data that only those snapshots referenced. While prune runs, the repository is locked and no backup can complete, so the docs ask you to keep it clear of backup runs and to run restic check afterwards. Plakar stores its rules as named policies, for example one snapshot per week over three months, which plakar prune -policy applies; without -apply, the command only lists what it would delete. Databasus sets retention by age, by count or as a GFS rotation, which keeps hourly, daily, weekly, monthly and yearly backups independently.
Databasus is the only one of the three that checks a backup by restoring it. Its agent restores the latest backup into a throwaway container of the same major version, after each backup or on a schedule, and the report compares the restored size with the backup's and lists every table with its row count. restic and Plakar check the repository without restoring, and their commands don't check the same thing by default. restic check only looks at the repository structure; --read-data reads back all the data, which means downloading it, and --read-data-subset reads a share of it per run, by group, percentage or size. plakar check works the other way round and validates the MACs of all the data from the start, while -fast limits it to the structure. With either tool, a restore test means running restore yourself, by hand or from a script.
Where the projects stand
restic is the veteran: its repository dates from April 2014 and has never tagged a 1.0. v0.19.0 shipped on 9 June 2026, fourteen months after 0.18.0, with v0.19.1 following on 5 July, and since 0.6.1 every released binary can be rebuilt byte for byte from source. Plakar's repository dates from March 2021, but its first stable release, v1.0.1, only came in May 2025, and the 1.1 branch still changes behaviour in patch releases: since 18 September 2026, Plakar's server rejects logins that don't go through the authentication flow introduced in v1.1.6. Databasus, formerly Postgresus, opened its repository in June 2025 and shipped 251 versions between v0.1.0 in July 2025 and v3.60.0 on 22 September 2026; one developer authored 955 of the 1,047 commits. Its v3.43.0 removed the agent that used to take physical backups from the database host, so anyone still holding such backups has to stay on 3.42.0 or delete them before upgrading.
Licences and paid plans
restic is under BSD-2-Clause, Plakar under ISC and Databasus under Apache-2.0, all three permissive licences. Plakar keeps centralised scheduling, inventory and the full interface for Plakar Control Plane, a virtual appliance you host yourself, free up to 500 GB of managed data; beyond that, pricing goes through sales. Its prebuilt connectors are free but need an account, and the VMware and SQL Server connectors, which have no public repository, only come prebuilt. Databasus rules out open core: no gated features, no hosted version, and sponsorships from 25 to 5,000 dollars a month that list the sponsor's name and unlock nothing.