BEFORE YOU BEGIN
Check before you begin
This guide covers SQL/MSSQL instance and database workflows through the Windows agent. Full, differential and transaction-log chains are distinct. The 10 October Always On acceptance plan lacks evidence for AG discovery, preferred-replica selection, health/failover decisions and automatic join/seed; a visible cluster field is not acceptance.
Visual/acceptance limit: this guide is based on local Agent Policy and restore templates plus available technical documentation. The ongoing Firefox page-reading issue prevented new SQL Server/Oracle captures in this inspection; PostgreSQL or another engine’s screenshot was not substituted. No instance/policy was created and no backup/restore or log-finalization operation was executed. The installed release and end-to-end data acceptance require separate validation.
- Engine, agent/master releases and instance identity
- Database scope, method and access privileges
- Full base, log chain and repository access
- Isolated destination, collisions and application acceptance
011. Record instance and database scope
Record SQL Server release/edition, Windows and agent releases, instance name/port, databases and recovery models with the DBA. Choose a small standalone test database for initial acceptance. Record AG/listener, node and actual replica identities separately; do not generalize standalone acceptance to Always On.
Expected resultThe selection and relevant acceptance evidence are recorded.
022. Verify agent and engine access
Validate the correct Windows Agent service, instance access, SQL/OS privileges required for backup and repository capacity. Use the approved instance credential record; do not put passwords in policy names or logs. Validate VSS/VDI and open-database consistency against the installed agent release.
Expected resultThe selection and relevant acceptance evidence are recorded.
033. Prepare a SQL policy for the correct engine
Open Home → Policies → Agent Policy → Create Agent Policy. Select the correct Agent, Policy Name and Storage. Under Policy Type → SQL choose SQL Server. Do not substitute File Backup or Bare Metal for a database policy. If the instance list is empty, validate access before creating an arbitrary connection.
Expected resultThe selection and relevant acceptance evidence are recorded.
044. Match the instance and elements in Clients
Open the registered SQL Server instance in Clients, select the test database and compare it with the summary. Avoid similarly named host/listener records. Selecting multiple databases may affect restore options; keep the first test explicitly scoped to one database.
Expected resultThe selection and relevant acceptance evidence are recorded.
055. Define the method and log chain with the DBA
The inspected MSSQL Backup Methods screen offers Transaction Backup (Truncate Logs) and Transaction Backup (Keep Logs). UI descriptions are not proof of actual log-chain/SQL behavior; the DBA must validate the method, recovery model and compatibility with existing log-shipping/AG plans. Do not accept an option that affects the current chain merely because it is the default.
Expected resultThe selection and relevant acceptance evidence are recorded.
066. Plan scheduling and initial backup acceptance
Check scheduling and retention actually exposed for the engine/method in Advanced Settings and Schedules. Compare Full-base and dependent log/differential/incremental-chain retention with capacity; do not assume every method applies to each engine. In an approved small test, record task result, repository output and catalog method together.
Expected resultThe selection and relevant acceptance evidence are recorded.
077. Complete database and application acceptance
Use the separate engine restore guide to validate database startup, schema, sample queries, row counts and application access on an approved isolated target. Active, Last Backup or a success notification alone is not content acceptance. Record backup identity, method, time and the required chain in the report.
Expected resultThe selection and relevant acceptance evidence are recorded.
COMMON QUESTIONS
Does a successful task mean the application is ready?
Not by itself. Engine integrity, required log chains, data queries and application access need separate validation; HA/topology acceptance is assessed separately.