# Kup Backup System: scheduled backups for the Plasma desktop

> Kup is a KDE backup scheduler that watches for your external drive or network mount and runs rsync or bup plans when it appears. It fits desktop users who want backups to happen without a cron job, and it assumes you are running Plasma.

**KDE/kup** — Backup scheduler for the Plasma desktop

- Repository: https://github.com/KDE/kup
- Website: https://invent.kde.org/system/kup
- Stars: 35 · Forks: 8
- Language: C++
- License: not declared
- Published: 2026-08-21 · Updated: 2026-08-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/kde-kup

## The problem Kup solves: backups that wait for the drive

Most desktop backup tools assume the destination is always there. A USB hard drive is not. It is unplugged, carried somewhere, plugged back in days later, and the scheduling question becomes awkward: a nightly cron job either fails silently or wakes a sleeping laptop for nothing.

Kup takes the opposite position. The README describes a background program that monitors whether the backup destination is available and only then schedules and runs plans. Connecting a USB hard drive is described as the primary supported way to store files, with network destinations listed as possible for advanced users. On top of availability it adds a second gate: a usage-based schedule that suggests a backup only after you have been active on the computer for some number of hours since the last one, and it can ask before copying anything.

The target user is a Plasma desktop user with personal files and one or two backup targets. It is not aimed at servers, at fleets, or at anyone who wants a single self-contained binary. Kup is a scheduler and a set of KDE integrations wrapped around two external programs, and the README is explicit that you need either bup or rsync installed for backups to be created at all.

## Two schemes, two very different storage models

Kup supports exactly two backup types, and the difference between them matters more than any UI setting.

The first is a synchronized folder produced by rsync. This keeps the backup folder in sync with the source, which means a file deleted on your computer is also deleted from the backup. If you delete something by mistake and only notice a week later, the synchronized scheme has already propagated the deletion.

The second is an incremental archive produced by bup. Here older versions are kept, and only the parts of files that actually changed since the last backup are stored, so incremental runs are described as very cheap. The README makes a specific claim about access: every backup contains a complete version of your directories, even though identical content is stored only once behind the scenes. That is the classic content-addressed store trade-off. You get cheap repeated backups and browsable snapshots, and in exchange the archive is not a plain directory tree you can copy to another machine and read with a file manager.

The choice is therefore not cosmetic. rsync gives you a mirror that any tool can read. bup gives you history and low incremental cost, at the price of depending on bup and its archive format for every restore.

## What actually ships in the repository

The top-level layout confirms the README's component list rather than just repeating it. There is kcm/ for the configuration module that appears in System Settings, daemon/ for the background program that watches destinations and runs plans, kioworker/ for opening files inside bup archives from KDE applications, and filedigger/ for the standalone archive browsing application used to locate and restore files. purger/ is a separate top-level directory, and the README does not describe what it does, so treat its behaviour as undocumented here.

Also present are plasmoid/ for the system tray applet that can trigger a manual backup, fileitemaction/ for file manager integration, settings/ and kupenums.h as shared definitions. The build system is CMake, the language is C++, and the repository carries .gitlab-ci.yml and .kde-ci.yml, which points at KDE's GitLab instance at invent.kde.org rather than GitHub as the canonical home.

One practical consequence of this layout: Kup is not one program. The daemon must be running for scheduled backups to fire, and the kioworker must be installed for KDE applications to open an archive path. If you build only part of the tree, you get a configuration dialog with nothing behind it.

## Building Kup from source and taking a first backup

There are no packaged install instructions in the README, only a source build. The dependency list is long and Plasma-specific: qt5-base, kcoreaddons, kdbusaddons, ki18n, kio, solid, kidletime, knotifications, kconfig, kjobwidgets, kcmutils, plasma-framework and libgit2, plus CMake and extra-cmake-modules. The README does not document a distribution package name, so on a non-KDE system you are looking at installing a large dependency set before the first build.

The documented build sequence is run from the source directory:

```bash
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=release ..
make
sudo make install
```

Note the install prefix: /usr, with sudo. This installs into the system rather than into a user prefix, which is what the KCM and the kioworker expect in order to be discovered by System Settings and KIO.

Before any of that produces a backup, the external program must exist. The README states you need either bup or rsync installed, and it links to the bup project for details. A reasonable order is to install the backend first, then build Kup:

```bash
sudo apt install bup rsync
```

After installing, the configuration lives in System Settings, where you define backup plans, what to include, where to store the backup and how often, and where the status of each plan is shown. The README does not walk through the individual fields of that dialog, so the first real use is: create one plan, point it at a destination that only exists when your drive is mounted, choose the scheme, and trigger a manual run from the system tray applet instead of waiting for the daemon's schedule. That manual trigger is documented as one of the three schedule types and is the fastest way to confirm the backend is wired up correctly.

## Where Kup is the wrong tool

The synchronized rsync scheme deletes from the backup whatever you deleted locally. That is stated plainly in the README and it is not a bug, but it disqualifies Kup for anyone whose threat model includes accidental deletion or ransomware, unless every plan uses the bup scheme instead. Even then, the archive lives on a destination that Kup itself monitors and writes to, so an attacker or a mistake that reaches the mounted drive reaches the archive.

The usage-based schedule is the other constraint. It fires after you have been active on the computer for some hours since the last backup. A machine that is powered on briefly, or a headless box, will not accumulate that activity. The README lists manual, interval and usage-based schedules, so an interval schedule is available, but the daemon still has to be running and the destination still has to be detected. For server-side backups with retention policies, verification and offsite copies, Kup is simply not the category of tool.

Finally, restoring from a bup archive depends on the bup tooling and on Kup's own kioworker or filedigger application. If you want a backup you can hand to someone with a USB cable and no software, use the rsync scheme, and accept the deletion propagation that comes with it.

## How Kup differs from a plain rsync script or a scheduled job

The obvious alternative is a shell script with rsync and a systemd timer or a cron entry. The difference is not the copying, since Kup runs rsync for one of its schemes anyway. The difference is the trigger. A cron entry fires on a clock; Kup fires on destination availability plus a usage threshold, and it can prompt before starting. If your drive is usually unplugged at the scheduled hour, the script fails and you find out later, while Kup's whole design is built around waiting for the drive to appear.

Against file-sync tools that keep a live mirrored folder, the difference is versioning. A live mirror gives you the current state everywhere and no history; Kup's bup scheme gives you history with deduplication, and the README describes the restore experience as being as easy as if a complete backup were taken each time, through the archive browser and the kioworker. That is a heavier dependency chain in exchange for cheap repeated snapshots of large files.

Against a full backup suite with its own catalog and server component, Kup's distinguishing feature is that it is a desktop citizen: a KCM in System Settings, a tray applet, a KIO worker, all built on KDE Frameworks. That integration is the product. If you are not running Plasma, most of it is dead weight.

## Maintenance, licensing and what the repository does not say

The repository is not archived, but no last push date and no releases appear in the repository metadata, so there is no basis for describing the project as actively developed or regularly updated. The sensible reading is that Kup ships as part of KDE's release cycle rather than as a fast-moving standalone project, and that the things to watch are the KDE Frameworks and Qt versions it builds against, since the dependency list is pinned to qt5-base and a set of KF5 libraries. Upgrading your distribution's Qt or Frameworks is the event most likely to require a rebuild.

Licensing is the weak spot here. The repository has a LICENSES/ directory and an org.kde.kup.appdata.xml file, but the README does not state a licence identifier and the repository metadata does not either. KDE projects are commonly GPL-licensed, but that is an assumption, not a fact from the repository, so check the files under LICENSES/ yourself before redistributing or bundling Kup. The separate bup and rsync programs carry their own licences, and the README points to the bup project for its details.

Upgrade cost is mostly about the archive. A bup archive written by one version of bup is read by the bup you have installed, so the restore path depends on a program Kup does not ship. The README does not document archive migration or rollback, which is worth knowing before you make the bup scheme your only copy of anything.

## Conclusion

Adopt Kup if you run Plasma, keep a USB drive or a network mount as your backup target, and want backups triggered by usage rather than by a cron entry. Do not adopt it if you are not on KDE, if you need backups to run while you are logged out, or if you want a single binary with no external programs: Kup needs bup or rsync installed separately. Before relying on it, verify that your destination is actually detected when mounted, confirm which scheme each plan uses, and test a restore through the bup archive browser rather than assuming the files are readable.

## FAQ

### What does Kup need installed to create backups?

The README states you need either bup or rsync installed, since they provide the implementations for the two backup types Kup supports. Kup itself is the scheduler and the KDE integration around them.

### What is the difference between the two Kup backup schemes?

One scheme keeps the backup folder completely in sync with your computer using rsync, deleting from the backup any file you deleted locally. The other uses bup to keep older versions and stores only the changed parts of files, while every backup still contains a complete version of your directories.

### When does Kup actually start a backup?

The README describes a background program that monitors whether the backup destination is available, then schedules and runs your plans. Schedules can be manual, interval based, or usage based, where a backup is suggested after you have been active on the computer for some hours since the last one.

### How do I compile Kup from source?

The README gives a CMake build from the source directory: create a build directory, run cmake with -DCMAKE_INSTALL_PREFIX=/usr and -DCMAKE_BUILD_TYPE=release, then make and sudo make install. It requires CMake, extra-cmake-modules, and a list of KDE Frameworks and Qt5 development libraries.

## Sources

- [Official documentation](https://invent.kde.org/system/kup)
- [Official README](https://github.com/KDE/kup#readme)
- [Project repository](https://github.com/KDE/kup)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kde-kup