Borg Backup Monitoring vs. Heartfly: A Deep Dive for Cron Jobs

As engineers, we rely heavily on automated tasks. Cron jobs are the silent workhorses of our infrastructure, handling everything from daily backups to log rotation, data synchronization, and certificate renewals. When it comes to critical tasks like backups, we often turn to robust tools like BorgBackup. Borg is fantastic for deduplicated, encrypted backups, and it provides excellent internal mechanisms for verifying the integrity of your archives.

But here's a crucial question: How do you know your Borg backup script actually ran? And what about all your other cron jobs? This is where the distinction between a tool's internal monitoring and an external "did it even run?" monitoring service like Heartfly becomes critical.

This article will break down how Borg handles its own monitoring, where its capabilities end, and how Heartfly fills the essential gap of ensuring your scheduled jobs execute reliably, providing a comprehensive safety net for your entire cron ecosystem.

Borg's Built-in Monitoring: What It Does Well

BorgBackup is designed with integrity in mind. It ensures that your backups are valid, consistent, and recoverable. Its monitoring capabilities are focused on the success or failure of the backup operation itself.

Here's how Borg typically provides feedback:

  • Exit Codes: Like most well-behaved Unix tools, Borg commands return an exit code of 0 on success and a non-zero value on failure. Your backup script can check these.
  • --stats and --progress: When creating archives, these flags provide detailed output on data processed, deduplication rates, and elapsed time. This is invaluable for understanding the backup's performance.
  • borg check: This command is your best friend for verifying repository consistency. It checks archive integrity, metadata, and data chunks. Running borg check regularly is a non-negotiable part of a robust backup strategy.
  • borg prune --list and borg diff: These help you track what's in your repository and how it changes over time.

Consider a typical Borg backup script. You'd likely integrate checks for exit codes and perhaps email yourself a summary:

```bash

!/bin/bash

borg_backup.sh

REPO=/mnt/backup/borg_repo SOURCE=/home/user/data EMAIL_RECIPIENT="your_email@example.com" HOSTNAME=$(hostname)

Ensure repo exists (optional, 'borg init' will fail if it exists unless --append-only is used)

borg init --encryption=repokey-blake2 $REPO 2>/dev/null || true

Perform backup

borg create --stats --progress --compression lz4 \ $REPO::"{hostname}-{now}" $SOURCE BACKUP_EXIT_CODE=$?

Prune old backups

borg prune --list --keep-daily=7 --keep-weekly=4 --keep-monthly=6 $REPO PRUNE_EXIT_CODE=$?

Check repository consistency

borg check $REPO CHECK_EXIT_CODE=$?

if [ $BACKUP_EXIT_CODE -ne 0 ] || [ $PRUNE_EXIT_CODE -ne 0 ] || [ $CHECK_EXIT_CODE -ne 0 ]; then ALERT_SUBJECT="[ALERT] Borg Backup Failed on $HOSTNAME" ALERT_BODY="Borg backup, prune, or check failed with exit codes: Backup=$BACKUP_EXIT_CODE Prune=$PRUNE_EXIT_CODE Check=$CHECK_EXIT_CODE Please investigate." echo "$ALERT_BODY" | mail -s "$ALERT_SUBJECT" "$EMAIL_RECIPIENT" exit 1 else SUCCESS_SUBJECT="[SUCCESS] Borg Backup Completed on $HOSTNAME" SUCCESS_BODY="Borg backup, prune, and check completed successfully. Check repository for details if needed." echo "$SUCCESS_BODY" | mail -s "$SUCCESS_SUBJECT" "$EMAIL_RE