DevOps & monitoring

Backupkrake offers central monitoring for rsync and restic backups

A new self-hosted tool called Backupkrake centralizes backup management, offering pull-based rsync snapshots, bandwidth controls, and integrated heartbeat monitoring.

Server racks under a glass dome with mixed status lights
Illustration created for this article

On November 13, 2026, a developer shared details of Backupkrake, a custom-built backup solution designed to address gaps in existing proprietary and script-based tools. The project aims to provide a centralized, monitorable system for managing data protection across home labs and remote servers without relying on vendor lock-in or complex agent installations.

What happened

The creator of Backupkrake developed the tool after finding standard options like bash scripts with rsync, Borg, Synology NAS solutions, Nextcloud, and Seafile unsatisfactory. Common pain points included proprietary restrictions, lack of central monitoring capabilities, or tools being used for purposes outside their original design intent. The resulting software is a central backup manager that pulls data from clients over SSH using rsync, requiring only the server’s public key and rsync on the client side, with no additional agents needed.

Backupkrake supports diverse environments, including systems where the user has only normal account access, such as shared Unix hosts. In these cases, it backs up specific folders like the home directory using keys locked to those paths. The system creates hardlinked snapshots, meaning every backup appears as a complete directory tree, but unchanged files are linked to previous snapshots to save storage space. This approach allows users to browse any snapshot as if it were a full copy while only consuming disk space for changed data.

The solution includes advanced scheduling and retention features. Administrators can define backup windows, such as restricting transfers to nighttime hours between 22:00 and 06:00, and set bandwidth limits like 20 MiB/s per host. If a backup runs past its window, it stops and resumes the next night. Retention policies are applied after every backup, keeping the last N snapshots along with specified daily, weekly, and monthly archives. For disaster recovery, the tool supports push-restores, allowing files to be sent back to clients or other hosts with a dry-run preview option.

Key details

  • Agentless architecture: Clients require only rsync and the server's public SSH key; no background daemons or agents are installed on source machines.
  • Storage efficiency: Uses hardlinked snapshots so that each new backup only stores changed files while presenting a full directory tree for browsing.
  • Traffic control: Per-host bandwidth limits and time windows prevent backups from impacting daytime network performance.
  • Offsite encryption: Integrates with restic to upload encrypted copies of the latest snapshots to S3, B2, SFTP, or other rest-server endpoints.
  • Centralized UI: A web interface manages hosts, schedules, and live logs, showing progress bars for data transfer speed and time remaining.
  • Heartbeat monitoring: Includes an optional hourly heartbeat to external services like healthchecks.io or Uptime Kuma to detect if the backup server itself goes down.

Background

Self-hosted backup strategies often struggle with the "silent failure" problem, where a job stops running due to a configuration change or network issue without alerting the administrator. Traditional cron jobs execute commands but do not inherently report success or failure to a central dashboard unless explicitly configured to do so. Tools like rsync are excellent for copying files but lack built-in scheduling, retention management, or visual status reporting. Combining these low-level tools with monitoring services requires significant scripting effort.

Hardlinking is a file system feature where multiple directory entries point to the same physical data on disk. In backup contexts, this allows systems to present every snapshot as a full copy while storing only one copy of unchanged files. This saves substantial storage space compared to full copies and is more accessible than complex deduplication databases for small teams. However, managing these links manually across multiple hosts is error-prone, which is why centralized tools like Backupkrake automate the process.

Why it matters

For teams running their own infrastructure, visibility is as critical as the backup itself. A backup that cannot be verified is a liability. Backupkrake addresses this by providing a single pane of glass for all hosts, showing live logs and run history. This reduces the cognitive load on sysadmins who previously had to SSH into multiple servers to check log files or rely on fragmented email notifications. The ability to see exactly how much data was transferred and how long a job took helps in capacity planning and troubleshooting network bottlenecks.

The integration of offsite encrypted copies via restic adds a layer of resilience against local hardware failure or ransomware. By automating the upload to object storage like S3 or B2, the tool ensures that a secondary copy exists outside the primary infrastructure. The retention policies ensure that this offsite storage does not grow indefinitely, controlling costs while maintaining sufficient historical data for recovery. This combination of local speed and remote durability is essential for robust disaster recovery plans.

What you can do

  • Evaluate your current backup scripts for silent failure risks and consider adding heartbeat checks to your cron jobs.
  • Test hardlinked snapshot strategies on a non-production volume to understand storage savings versus complexity.
  • Implement bandwidth throttling on backup jobs to prevent interference with production traffic during business hours.
  • Review your retention policies to ensure they balance recovery needs with storage costs, especially for offsite copies.
  • Deploy a centralized dashboard for backup monitoring to reduce the time spent checking individual server logs.
  • Verify your restore process regularly using dry-run previews to ensure that push-restore mechanisms work as expected.

More news

All news