Learn Rsync - Monitoring & Logging

#Introduction

A backup running without monitoring is an illusion of security. You only find out a backup is broken when you need to restore — and by then it's too late. Episode 20 closes that gap: how to make rsync backups measurable, logged, and alerted so failures are detected in minutes, not months. We cover five layers: logs, exit codes, notifications, alerting integration, and periodic audits — all buildable with tools already on your server.

#Rsync Logs

A good log has three properties: timestamped, with context, and with a summary. The script in episode 10 already wrote timestamps; improve it with a statistics summary:

#!/bin/bash
LOG=/var/log/rsync.log
{
  echo "=== $(date '+%F %T') rsync started ==="
  rsync -avh --stats --delete /home/data/ /backup/daily/
  echo "=== exit=$? finished $(date '+%F %T') ==="
} >> "$LOG" 2>&1

A one-block-per-run format (=== started === … === finished ===) is easy to parse. For logs that are easy to analyze, consider a one-line-per-run format — ideal for querying and charting, and we'll use it in the Prometheus section below:

echo "$(date '+%F %T') rc=$RC sent=$SENT recv=$RECV speedup=$SPEEDUP" >> "$LOG"

#Exit Codes

Already mapped in episode 10: 0 success, 23 partial transfer, 24 files vanished, 255 connection error. The key to using them in scripts:

RC=$?
if [ $RC -eq 0 ]; then
  STATUS="OK"
elif [ $RC -eq 23 ] || [ $RC -eq 24 ]; then
  STATUS="PARTIAL"   # some files failed/vanished — must be checked
else
  STATUS="FAILED"
fi

Treat 23/24 as a warning that must be looked at, not success: some data may not be synced. This STATUS is what you'll send to notifications and alerting.

#Email on Failure

The simplest notification — email when it's not 0 (the episode 10 pattern):

if [ "$STATUS" != "OK" ]; then
  tail -30 "$LOG" | mail -s "Rsync $STATUS (rc=$RC) - $(hostname)" admin@example.com
fi

For modern teams, replace mail with a webhook — Slack/Telegram/Mattermost only need curl:

curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" \
  -d chat_id="$CHAT_ID" -d text="Rsync $STATUS rc=$RC di $(hostname)"

#Cron Wrapper + Alerting

The most flexible form: a cron wrapper that runs the backup, writes a status, and exposes it to your monitoring system. The Prometheus textfile collector pattern (via node_exporter):

#!/bin/bash
LOG=/var/log/rsync.log
rsync -avh --delete /home/data/ /backup/daily/ >> "$LOG" 2>&1
RC=$?
printf 'rsync_backup_last_status %s\n' "$RC" > /var/lib/node_exporter/rsync.prom
printf 'rsync_backup_last_run %s\n' "$(date +%s)" >> /var/lib/node_exporter/rsync.prom

node_exporter publishes the .prom file as metrics; Prometheus scrapes it on every interval; Alertmanager sends an alert when rsync_backup_last_status ≠ 0 for more than N minutes. The flow diagram:

cron → rsync script → exit code → textfile .prom → node_exporter
   → Prometheus (rule) → Alertmanager → email/Slack/PagerDuty

For Zabbix, the pattern is the same with different tooling: zabbix_sender sends the status straight to the server, or an external item reads the log. What matters is the principle, not the tool: a backup's exit code must become a metric that gets scraped.

#rsyslog for Daemon Mode

When using rsyncd (daemon mode), it can write logs to syslog — managed by rsyslog — instead of only its own file. Configuration in /etc/rsyncd.conf:

use syslog = yes
log format = %h %o %f %b

Every daemon connection now goes to syslog with a host, operation, file, and byte format. On the rsyslog side, direct a specific facility to a file or forward it to a central log server:

daemon.*  /var/log/rsyncd.log

Sending to a central log server (e.g. @logserver:514) centralizes daemon auditing — useful for monitoring who pulls from a module, and for investigating suspicious access.

#Periodic Backup Log Reviews

Even the best tooling means nothing without a human reviewing it. Build an audit habit:

grep 'rc=' /var/log/rsync.log | awk '{print $1, $2, $5}'

Periodic reviews (weekly/monthly) with these questions:

• Were there non-0 runs that slipped past the alert?
• Is there a repeating PARTIAL pattern (files that always fail — a sign of a permanent problem)?
• Are transfer sizes normal, or are there spikes (an indication of unexpected extra data)?
• Is snapshot rotation running and disk space under control?

#Closing

In this episode you've made rsync backups measurable and monitored.

Key takeaways:

• Logs with timestamps and a one-line summary per run — easy to query.
• Exit code classification: 0 OK, 23/24 partial (beware), anything else failed.
• Notifications (email/webhook) only on non-OK; too many alerts = dead alerts.
• A cron wrapper exports the exit code to a metric (Prometheus textfile / Zabbix).
• rsyncd can log to rsyslog; periodic audit reviews and restore drills are mandatory.

In episode 21 we look ahead: roadmap & community — ongoing security focus, 3.4.x maintenance releases, no major features planned, management via lists.samba.org, the GitHub repo, and the rsync mailing list. See you in episode 21!