When you need this
A successful pg_dump or mysqldump does not prove the backup reached storage or can be restored. Monitor the whole chain: file creation, validation, transfer and retention checks. Send success only after the final required step.
How to connect
- 1
Combine the dump, file validation and storage upload in a script that returns nonzero if any required step fails.
- 2
Wrap that script and set a monitor matching the backup schedule, allowing for its normal runtime.
- 3
Create a separate scheduled restore test and give it a separate monitor.
Ready-to-use example
Install Bash, curl and uuidgen on the job server. Save the code as /opt/tickwatch-run.sh, replace the ping URL with your own and use the absolute path to your job. Keep the ping key private. The wrapper preserves the job exit code; a failed monitoring request does not interrupt it. backup-and-verify.sh is your existing backup and validation script, not a command supplied by Tickwatch.
#!/usr/bin/env bash
# Save as tickwatch-run.sh; run: bash tickwatch-run.sh /path/to/job.sh
if [ "$#" -eq 0 ]; then echo "Usage: $0 command [args...]" >&2; exit 2; fi
PING='https://ping.tickwatch.dev/YOUR_PING_KEY'
RID=$(uuidgen) || exit 1
ping() {
curl -fsS --connect-timeout 3 --max-time 5 --retry 2 --retry-max-time 12 \
-X POST "$PING/$1?rid=$RID" >/dev/null 2>&1 || true
}
finish() {
code=$?
trap - EXIT
if [ "$code" -eq 0 ]; then ping ""; else ping fail; fi
exit "$code"
}
trap finish EXIT
trap 'exit 130' INT
trap 'exit 143' TERM
ping start
"$@"0 3 * * * /usr/bin/bash /opt/tickwatch-run.sh /usr/local/bin/backup-and-verify.shCheck before going live
If using pg_dump | gzip, enable pipefail in your Bash backup script: a successful gzip must not mask a pg_dump failure.
An empty or old file is not a new backup. Check its size, creation time and successful upload to remote storage.
The wrapper sends status signals only. Do not send database dumps, connection strings or passwords in ping bodies.
Common questions
Does a green monitor prove the data is restorable?
Only if the job actually performs the required restore test. Tickwatch records the reported result; it does not inspect the dump contents.
Does this work with PostgreSQL and MySQL?
Yes. Monitoring is database-independent. The script must return the correct exit code and report success only after every required stage.