The Backup Logs page is your audit trail for every backup run. It’s where you filter, read, and investigate messages generated by file and database jobs across all schedules you’re allowed to see.

Who can view this

• Requires the view_backup_logs_page permission.
• If your account is limited to specific servers (USER_SERVERS), only logs for those servers are shown.

What you’ll see

• A counter with total log entries in the system.
• A Clear backup logs button — removes logs for idle schedules only and cleans up orphaned entries (running jobs keep their logs).
• A date filter (From / To) with date pickers. Filtering is inclusive; the To date includes that entire day.
• A results table ordered by newest first:

• Date — when the entry was recorded.
• Status — color coded: started, completed/success, stopped, warning, error/connection, info.
• Type — FILES or MYSQL (and occasionally system categories used internally).
• Schedule — the policy that produced the entry.
• Message — human-readable description. For warning / error entries you can click to open a modal with the full message context.
• Duration — run time captured for completed items when available.

Statuses & where they come from

• started — a job began (manually or by cron).
• completed / success — the job finished successfully (exit code 0, or mapped “completed” conditions).
• warning — non-fatal outcomes (e.g., rsync code 23), or unknown/empty exit codes recorded defensively.
• error — fatal failures (e.g., “No space left on device”, connection failures).
• stopped — a running job was stopped from the UI.
• running — long-running alerts (e.g., “FILES/MYSQL … running for over 24h/36h/…”). These are emitted by the background checker to notify on stuck/extended runs.
• connection — connectivity issues detected by background routines.

Filtering & reading tips

• Use a tight date range to focus on an incident window; the list can be large on busy systems.
• Click the message of any warning or error to open the Message Log modal for full details captured from the remote log.
• Pair this page with the Monitor view for a live, auto-refreshing feed (and quick access to running schedules).

What “Clear backup logs” does

• Deletes log entries for schedules that are not currently running.
• Also removes orphaned records that point to deleted schedules.
• Does not affect any backup data or points on storage; it’s safe for housekeeping.

How logs are generated (under the hood)

• Every job action calls an internal logger that writes rows with: date, status, type, schedule, duration, y/m/d, point.
• During runs, the background checker re-evaluates active schedules: it inspects remote screen/process state, maps rsync/mysql exit codes, and posts completed, warning, or error entries with parsed messages.
• If a run exceeds thresholds (24h, 36h, …), the checker records a running alert (and can trigger email notifications if enabled per user).

Typical patterns to look for

• Repeated connection or error: check storage reachability, SSH keys, and free space.
• Frequent warning 23/24 on FILES: partial file list or excludes; often benign but worth reviewing.
• Many stopped entries: jobs are being interrupted; consider rescheduling or adjusting concurrency.

Good to know

• Time filtering uses the server’s clock and includes the entire To day.
• Emails (if configured per user) mirror key log events (started, stopped, completed, warnings, errors, connection, long-running).
• Logs are scoped by your server access list; you won’t see entries for servers you aren’t allowed to manage.