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. Find the correct engine and database record
Find the SQL Server job under Home → Backups → Backup List. Compare source host, instance/database, method and Last Backup. A Not Yet Backup entry is not a usable point. Do not treat a VM image or another SQL engine’s catalog as the same restore path.
Expected resultThe selection and relevant acceptance evidence are recorded.
022. Validate the point and dependent chain
In Action → Restore, open the correct instance/database and Full point. Where applicable, match differential/log/incremental pieces by method and time. All files required for the requested time and repository access must be available. Calendar selection alone is not PITR; automatic log replay or point-in-time recovery was not executed in this inspection.
Expected resultThe selection and relevant acceptance evidence are recorded.
033. Check destination options in the installed release
The inspected MSSQL target code splits dbname by / and disables Different Location when there is more than one segment; eligible single-database records offer Original Location and Different Location. Do not treat this condition as a blanket guarantee for multi-database/AG records. The Different Location form requests Database Name and Instance; it does not guarantee restore to another server.
Expected resultThe selection and relevant acceptance evidence are recorded.
044. Prepare the isolated target and encryption dependencies
With the DBA, define a supported destination SQL Server release, new test database name, data/log capacity and access privileges. Check TDE certificates/keys, login/SID, collation and file-path dependencies. Do not assume overwrite of a same-named database. Automatic AG join/seed was not verified in this inspection.
Expected resultThe selection and relevant acceptance evidence are recorded.
055. Review Summary and the final action
Compare source database, backup ID, method/time, selected instance and destination name. Stop for missing chains, conflicting names or unclear overwrite behavior. Execute final Restore only in a test plan with validated scope and data effects. No Restore was submitted while preparing this guide; a form preview is not proof of successful recovery.
Expected resultThe selection and relevant acceptance evidence are recorded.
066. Check engine state and recovery finalization
Compare EraBackup task results with the SQL Server error log and database state. The DBA must assess ONLINE, RESTORING and recovery-finalization decisions; do not assume automatic WITH RECOVERY before the log chain ends. Plan integrity checks such as DBCC CHECKDB on the approved test destination with the DBA; do not blindly resubmit to a failed destination.
Expected resultThe selection and relevant acceptance evidence are recorded.
077. Document data and application acceptance
With the data owner, compare test queries, schema, sample rows, consistency and application connections. Record actual recovery time and data loss, releases, backup chain and destination identity. Separate standalone-database acceptance from cluster/HA failover acceptance. No production connection or DNS cutover was performed while preparing this guide.
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.