BEFORE YOU BEGIN
Check before you begin
Task state, notification delivery, report summaries and actual recovery acceptance are assessed separately. Validate fields, permissions and supported report/notification types against the installed release.
Visual/acceptance limit: content is based on local UI/backend contracts and technical documents. No new Dashboard/Reports/Notification Center detail screen was captured. The monitoring guide’s earlier real Backup List image is only a catalog/status example, not a report or notification detail. This inspection did not start/stop tasks, generate reports, change SMTP/recipients or send email.
- Tenant, platform and source/job/run identities
- Date range, time and state mapping
- Authorized ownership and recipient scope
- Task/catalog/data acceptance evidence
011. Define report purpose and scope
Separate server/policy inventory, task success, capacity and recovery-acceptance questions. Verify tenant/company and permission scope. Record environment and time zone in the title/operations record; do not assume every platform supports the same report type.
Expected resultThe check result and relevant job identity are recorded.
022. Select a server or job under Reports
Use the server-based or job-based path exposed under Reports by the installed release. The inspected code uses selectedServer or selectedJob; verify source and policy identity. Report generation may also test server connectivity, so it is not necessarily a historical-data-only read.
Expected resultThe check result and relevant job identity are recorded.
033. Validate the date range and data gaps
Compare start/end dates and system time. The inspected code expands a single date or range to the end of the final day; validate local-time/UTC interpretation in the installed release. Empty results do not mean there were no failures or every backup succeeded.
Expected resultThe check result and relevant job identity are recorded.
044. Reconcile results with tasks and catalogs
Compare sample successful/failed runs with Notification Center, task history and catalog points. Validate report status-code mappings against engine/release. Notification row counts are not unique backups or recoverable-point counts; one job produces multiple events.
Expected resultThe check result and relevant job identity are recorded.
055. Test saved-report preview
The inspected preview_report code generates server_based reports from the saved start date to today; other types may return Unsupported report type. Do not assume saved preview preserves the original date range. Automatic scheduling, PDF/CSV export and preview for every report type were not verified here.
Expected resultThe check result and relevant job identity are recorded.
066. Check recipients and delivery scope
Before sending, validate report contents, authorized recipients and SMTP configuration. The inspected send_report_mail uses saved recipient identities and SMTP settings. Avoid sending private infrastructure/tenant data to incorrect recipients. No report was generated or emailed while preparing this guide.
Expected resultThe check result and relevant job identity are recorded.
077. Document the report’s decision limits
Record report date, scope, filters, row counts and data gaps. Attach restore-test evidence and actual RPO/RTO separately for audit decisions. Active status/success rate is not a business-continuity guarantee. No unauthorized recipient, automatic delivery or record deletion was configured here.
Expected resultThe check result and relevant job identity are recorded.
COMMON QUESTIONS
Does a success notification replace restore acceptance?
No. Assess tasks, catalog points, actual data and application acceptance together; test email delivery separately.