A backup file is only one part of the evidence
Finding yesterday's backup file is useful, but it leaves several questions unanswered. Did today's job start? Did it finish before the next scheduled run? Did the program return a failure? Can you restore the data you actually need? Backup monitoring separates these questions so that a green execution record is not mistaken for proof of recoverability.
MetriBeacon can observe backup jobs through its job monitor and CLI runner. Your existing scheduler still starts the work. MetriBeacon records the reported execution and evaluates the configured expectations; it does not perform a restore or inspect your backup contents automatically.
Define three execution failures
| Failure | What to investigate |
|---|---|
| Failed run | The backup program's result, logs and destination |
| Missing start | Scheduler, machine availability and expected schedule |
| Overdue run | Runtime, stalled operations and overlapping work |
A missing-start rule requires a configured schedule. Without one, monitoring cannot know whether a quiet job should have started. Choose the correct time zone and allowed lateness, especially if your scheduler follows local time.
Wrap the command you already use
Create a job monitor using the Backup/Cron template, review its schedule and explicitly enable the rules you need. Run your existing backup program through the CLI wrapper:
metribeacon run --monitor-id MONITOR_UUID -- /usr/local/bin/backup.sh
Replace the identifier with your monitor's ID and configure the CLI's credentials according to the job monitoring documentation. Keep keys out of command examples, repositories and shared logs. The wrapper reports the execution; your cron service or other scheduler remains responsible for invoking it.
For overlapping scheduled runs, use the documented --scheduled-for option to report the intended UTC scheduling minute. This lets an execution describe the slot it belongs to rather than relying only on the time its process eventually started.
Make the exit code meaningful
A shell script can hide a failed backup if it finishes with an unrelated successful command. Review the script's error handling and the backup tool's documented exit codes. Ensure the wrapper observes the result of the actual backup operation.
Do not deliberately damage a production backup to test this. Use a harmless test command that returns a non-zero code, then a successful command, and inspect both recorded runs. Separately pause a test schedule to verify the missing-start rule. These tests cover different paths.
Use runtime as context
Choose an overdue limit from normal backup duration and an acceptable margin. A growing dataset may take longer even when every operation succeeds. Compare recent runs before assuming that a longer duration proves a fault.
Check destination capacity and source-machine health alongside job results. The server monitoring guide covers disk, CPU and memory observations. Those signals can help explain a slow run, but they do not establish the cause on their own.
Keep restore testing separate
A successful process exit means the reported operation succeeded according to that program. It does not demonstrate that the archive contains every required file, that credentials remain available or that the restore procedure works on a clean machine.
Run periodic restore exercises in a suitable test environment. Verify the restored application or files against a written recovery requirement. A separate restore-test job can report its own execution to MetriBeacon. Keep backup production and recovery validation distinguishable in names, schedules and alert rules.
A small operational checklist
- Confirm the expected schedule and its time zone.
- Inspect a real successful run and the program's exit status.
- Test failure, missing start and recovery with controlled examples.
- Confirm that the selected notification destination receives messages.
- Record the result and scope of a separate restore exercise.
Keep the checklist focused on evidence you can act on. More notifications are not automatically better coverage.
Frequently asked questions
Does MetriBeacon run the backup for me?
No. Your existing scheduler and backup program do the work. The integration reports execution and lets monitoring detect unmet expectations.
Can an alert prove my backup is restorable?
An execution alert cannot. A restore exercise provides separate evidence. Report that exercise as its own job when useful.
What if a backup finishes after midnight?
Keep the intended schedule, actual start and completion distinct. Review the configured time zone and, where applicable, report the intended slot with --scheduled-for.
Put one backup job under observation
Start with the backup you would most need during recovery. Set a meaningful schedule, test its alerts and add a separate restore exercise. The Backup/Cron template below provides the monitoring entry point without replacing your backup tool.
