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. Separate application events from email delivery
Notification Center events, report email, mount-watchdog alerts and 2FA email are separate flows. Success in one does not prove the others work. Define tenant/company, job owner, recipients and response ownership; do not assume identical SMTP/recipient scope for every notification.
Expected resultThe check result and relevant job identity are recorded.
022. Validate run identity and terminal state
Match job, run/sub and backup identities. The AD event contract separates started/running, progress, completed and failed; idempotency uses backup_id + job_id + job_type. The storage engine documents success as status=99/is_completed=1 and failure as status=57/is_completed=1; do not generalize these codes to every engine.
Expected resultThe check result and relevant job identity are recorded.
033. Read progress and failure details
Check units for progress, source/transferred bytes, rates and elapsed time. AD metrics distinguish MiB/s from Mbps. Record final errors and compensation/resume phases in Process Steps; the latest line or 100 percent alone does not establish application consistency.
Expected resultThe check result and relevant job identity are recorded.
044. Validate SMTP configuration with an authorized operator
In SMTP management validate server, port, TLS/SSL mode, sender and account identity for the installed release. Preserve certificate validation and protected credential storage. Keep passwords/app passwords out of chat, guides and screenshots. SMTP Test may send real email; do not randomly alter an existing configuration for testing.
Expected resultThe check result and relevant job identity are recorded.
055. Plan recipient scope and a controlled test
Validate which records feed report recipients and watchdog notification routes. Define an approved test address, expected subject/content and delivery window. Check SMTP acceptance separately from inbox delivery; distinguish bounce/spam/relay failures from task failures. No test email was sent in this inspection.
Expected resultThe check result and relevant job identity are recorded.
066. Check duplication and recovery behavior
Assess AD idempotent event updates separately from the storage scheduler’s no-duplicate-notification contract. The mount watchdog documents a transition alert after three failed attempts and a recovery message after restoration. Generic retry/backoff, muting, webhook/SMS or unlimited suppression support was not verified for every event.
Expected resultThe check result and relevant job identity are recorded.
077. Link alerts to response and acceptance records
Record alert owner, first-seen/delivery/response times and resolution. Separately define monitoring criteria for missing backup windows or aging checkpoints; no email does not mean a healthy system. Keep actual backup/restore acceptance separate from notification testing. Recipients, SMTP, 2FA and existing alert records were not changed during this inspection.
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.