← Documentation: Reliable Backup & Sync Execution Validation (Log-Driven)
Configure one noncritical job first. The setup connects an existing backup process to the monitor: the script creates a log, an uploader sends it to GCS, and n8n compares it with the GitHub manifest.
You need a Linux host with bash, cron and rsync or rclone, a private GCS bucket, a GitHub repository and credentials for the n8n integrations.
Download the example manifest and the script for your backup tool below. The manifest is used in step 3. In the rsync or rclone script, set JOB, SRC, DST and LOGDIR; for rsync, also set SSH_KEY and SSH_OPTS.
For example:
JOB=Projects \
SRC=/data/projects/ \
DST=backup@example:/backup/projects/ \
LOGDIR=/var/log/sync-jobs \
bash ./rsync_job-Template.sh
The rsync template uses --delete and the rclone template uses sync; both can delete destination-only files. Test with non-production data.
You can retain an existing backup script by adding the 01 · Architecture & Data Flow: START, the tool result, SUMMARY and final END, using the actual exit code. Other backup engines need a tested adapter. Provider names in sample filenames are naming examples, not restrictions on destinations.
Use a private bucket with uniform bucket-level access and public access prevention. Configure a dedicated uploader identity and the rclone remote; n8n can use a separate reader identity with list/read access.
rclone config
rclone lsd gcs:YOUR_BUCKET
Upload completed logs to the exact folder expected by n8n:
rclone copy /var/log/sync-jobs \
"gcs:YOUR_BUCKET/sync-logs/YOUR_HOST/$(date -u +%Y/%m/%d)/" \
--include "*.log"
This uploader is a separate script, not an n8n node. Verify that the expected object appears in GCS. Schedule upload after the backup finishes and before monitoring begins.