For native SQL Server point-in-time recovery, establish a valid full/differential/log sequence, the required keys and the exact transaction boundary before restoring to an isolated destination. This guide provides inspection and planning checks, not an executable production restore runbook. A readable backup is not proof of a recovered application.
The reference environment is SQL Server 2022. The procedure is source-researched and untested; rehearse it with synthetic data in an isolated lab first. No database was restored for this article, and no NetLeverage point-in-time recovery capability is implied.
Define the point you actually need
Record the database, the unwanted business operation and the last acceptable state. Preserve the incident evidence before trying to repair the application. A request such as “before the import” is useful only when it can be connected to timestamps or known transaction identifiers.
Microsoft describes the point-in-time result as the latest committed transaction at or before the requested time. A transaction that began earlier but committed later is not an earlier committed business result. The point-in-time restore documentation also explains the recovery-model boundary: a log backup containing bulk-logged changes cannot be stopped at an arbitrary point within that backup. Recovery must reach its end.
Write the time zone and clock source alongside the requested time. Compare the application’s timestamps with the SQL environment rather than assuming every log records the same local time. Daylight-saving transitions and incorrectly synchronised clocks can make a seemingly precise request ambiguous. Where the exact boundary is uncertain, preserve enough evidence to compare separate candidate restores.
Agree what will happen to legitimate work committed after the selected point. Restoring an earlier database does not reverse email, payments, files or records already sent to another system. Reconciliation is a business decision that belongs beside the restore plan.
Identify the available backup sets
A full backup provides a database starting state. A differential contains changes relative to its differential base. Log backups provide the ordered log records needed to move recovery forward. The restore overview describes these as a logically correct restore sequence, not a collection selected by the newest filenames.
Build a manifest for every candidate set. Include source server and database identity, backup type, start and finish, media location, encryption dependencies and the log sequence information. A log sequence number, or LSN, identifies a position in the database log. It helps distinguish a usable sequence from unrelated backups that happen to share a name.
The following read-only query is an author-written inventory example against the instance’s existing backup history. Have the DBA authorise access to msdb. It has not been executed here. Substitute the exact approved database name; a denied query or missing history is a visibility limitation, not evidence that backups do not exist.
SELECT b.database_name, b.type, b.backup_start_date, b.backup_finish_date,
b.first_lsn, b.last_lsn, b.checkpoint_lsn, b.database_backup_lsn,
b.recovery_model, b.is_copy_only, b.has_backup_checksums,
b.database_guid, b.family_guid, b.first_recovery_fork_guid,
b.last_recovery_fork_guid, b.media_set_id,
m.family_sequence_number, m.physical_device_name
FROM msdb.dbo.backupset AS b
LEFT JOIN msdb.dbo.backupmediafamily AS m ON m.media_set_id = b.media_set_id
WHERE b.database_name = N'LabOrders'
ORDER BY b.backup_start_date, b.backup_set_id, m.family_sequence_number;
The column definitions come from Microsoft’s backupset reference. D, I and L identify database, differential and log backups respectively. Use media_set_id to correlate msdb.dbo.backupmediafamily, including each family and its physical_device_name R3. database_guid changes on restore; family_guid identifies the original database family. The media join can return several rows per backup set. These fields support investigation, not a universal equality test for chain validity.
History is an inventory aid. It does not prove the referenced files still exist, remain readable or reached the recovery location. Another SQL instance may have no local history for these backups. Microsoft’s restore workflow therefore allows selection of backup devices directly. Inspect the actual media through the supported restore interface and reconcile it with the manifest.
Inspect the media without restoring a database
Untested SQL Server 2022 metadata checks, for a DBA-approved recovery instance. These read backup media; they do not restore a database. Microsoft requires CREATE DATABASE permission for these statements, and the SQL service must be able to read the files. Use an already authorised DBA role, not a new broad grant R1, R2. The path and set number below are illustrative: use Position from the header for the intended set.
RESTORE HEADERONLY FROM DISK = N'D:\RecoveryLab\LabOrders.bak';
RESTORE FILELISTONLY FROM DISK = N'D:\RecoveryLab\LabOrders.bak'
WITH FILE = 1;
For striped media, identify every required family. Compare header database/family and recovery-fork identifiers with history, then record every logical file and size from FILELISTONLY. A recorded physical_device_name is historical and may be stale; verify the actual recovery media R3.
STOPAT supplies the chosen time in a reviewed restore sequence; NORECOVERY allows further logs. Microsoft also recommends STANDBY when investigating an unknown stopping point. These are restore-state choices for the isolated DBA plan, not additional read-only checks S1.
Choose a sequence that reaches the boundary
Select a full database backup whose endpoint is earlier than the intended recovery time. If using a differential, confirm that its base belongs to that selected full backup and that it does not carry the database beyond the target. Do not pair the newest full and newest differential by name alone.
Then identify the log backups needed to reach the requested point, in their supported sequence. Check database identity and recovery history as well as time. A database recreated under the same name, or backups from a different recovery branch, cannot be safely joined through naming conventions.
Ask the DBA to review the chain rather than inventing a universal equality test between adjacent LSN fields. Backup types and recovery history affect how those fields relate. A restore planner and a real isolated restore provide stronger evidence than a spreadsheet that merely finds matching numbers.
If the available logs end before the required point, say so. Recovering the tail of an accessible transaction log may preserve additional work, but that is a separate incident-specific operation. It can affect the source database’s state and must be reviewed before an original-location restore. This article provides no executable tail-log or overwrite command.
Prepare an independent rehearsal destination
Use a separate SQL instance or an explicitly approved separate database with unique file destinations. Record the server identity and every destination path before accepting a restore. Keep the source database, original backup media and original files outside the write scope.
Provision enough storage for the restored database and its working requirements. A compressed backup’s file size is not the restored database’s capacity requirement. Review the full data-file inventory, including secondary data files, rather than assuming one MDF and one LDF cover every database.
Provide the actual recovery operator with controlled access to the media and any required keys. A successful test performed only by the original administrator may hide a missing recovery permission or secret. Never place credentials or private keys in the evidence manifest.
Keep scheduled jobs, outbound integrations and application traffic isolated. A second database can still be contacted accidentally by an application using a broad connection configuration. Conversely, an isolated database with no authentication dependency cannot demonstrate the complete business service. Record those dependencies explicitly.
Inspect before executing the restore
In SQL Server Management Studio, connect to the verified destination and open the database restore workflow. Select the actual backup devices when the destination lacks their history. Review the destination name, the required backup sets and the specific time in the timeline. Microsoft documents these selections in S1.
On the SSMS Options page, inspect Take tail-log backup before restore, any option to leave the source in restoring state, and Close existing connections. The latter sets the affected database to single-user mode. A rehearsal must not back up, change or disconnect the live source; prefer a separate instance and reject any script that does so. Do not blindly clear a tail-log requirement during real incident recovery: that needs its own DBA decision S1.
Generate the proposed script for DBA review. Check file relocation, recovery state and the selected time across the entire sequence. Stop if it targets an existing production database, uses unexpected overwrite behaviour or introduces an unexplained backup set. Do not treat the wizard’s default destination name as approval to replace that database.
During a multi-stage restore, NORECOVERY leaves the database available for further restore steps but unavailable for normal use. Final recovery makes it usable and prevents applying more log backups to that completed sequence. Recovering prematurely can therefore require restarting the rehearsal from the appropriate backup. The state transition is part of the plan, not a cosmetic wizard choice S1, S2.
Microsoft documents RESTORE VERIFYONLY as checking backup completeness and readability; it also checks backup checksums when present. It does not restore the database or establish the integrity of its internal data structures. A successful verification must not replace the rehearsal S4.
Prove the recovered business boundary
After the DBA runs the reviewed sequence in the lab, preserve each restore result and the actual selected backup identities. A database reporting online is an intermediate milestone.
Check representative records on both sides of the intended boundary. The accepted record should exist; the deliberately later lab record should not. Use a documented application query or workflow with known expected values. Do not assume a single row count proves that related records, balances or documents agree.
Have the DBA perform the appropriate integrity assessment separately. Then validate application access under its intended identity, read a representative object, and exercise a synthetic transaction where permitted. Record which external dependencies were excluded from this test.
Report the measured recovery execution interval and any access or preparation time separately. Do not turn a prepared lab restoration into a claim about full incident outage. Preserve failures and retries because they identify work that a real recovery plan still needs.
Decide what the result supports
The rehearsal supports a statement about this database, these backup sets, this target point and these acceptance checks. It does not prove every retained point, every database or every disaster scenario.
If the sequence fails, retain the exact SQL error and the selected media identities. Resolve a missing set, wrong base, unreadable file or absent key before changing the requested recovery point. Choosing an older point is a separate data-loss decision, not a way to conceal the failure.
Before any production recovery, agree authority over writes, application shutdown, reconciliation, traffic return and future backup protection. Keep the successful lab evidence with that plan. An isolated rehearsal is preparation for a reviewed operational decision.
Limitations
Scope is native SQL Server 2022 backups. SQL Server 2025 behaviour, marked-transaction recovery and production overwrite/tail-log procedures are not validated here. Media inspection and VERIFYONLY cannot establish logical integrity or business correctness.
Acceptance checklist
- Backup identity, recovery forks, every media family and key dependency recorded.
- Destination instance/files and every SSMS option reviewed without touching the live source.
- Isolated recovery and records on both sides of the selected boundary checked.
- Integrity, application access and separately measured recovery/preparation times recorded.
Learning notes
- A backup filename does not establish database identity or chain membership.
- Readability checks and a usable restored application answer different questions.
- The recovery point determines which later business work needs reconciliation.
Related reading: Restore a TDE Database Without the Original SQL Server; The Database Restored, but the Application Cannot Log In; SQL Server Reports Corruption: Preserve Evidence First.
Sources and review status
Sources accessed 30 October 2026. Exact displayed dates, scope and claim mapping are in the accompanying evidence file. Revised after independent review; independent recheck pending. All examples remain untested and no lab validation is claimed.
- Restore a SQL Server Database to a Point in Time (Full Recovery Model) - SQL Server | Microsoft Learn
- Restore and Recovery Overview (SQL Server) - SQL Server | Microsoft Learn
- backupset (Transact-SQL) - SQL Server | Microsoft Learn
- RESTORE VERIFYONLY (Transact-SQL) - SQL Server | Microsoft Learn
Additional revision sources: