NetBackup SQL Restore: Fix Partially Successful Logs

A NetBackup SQL Server restore can show "partially successful" even when the database files and transaction logs appear in the expected directories. In the reported case, the real problem was the restore batch template: several sections still needed comments removed, destination paths updated, and the final recovery state set correctly.

That is why SQL restore troubleshooting must separate file placement from database recovery state. Seeing .mdf and log files on disk proves that part of the restore ran. It does not prove the entire restore script completed as intended.

Why can a restore work and still be partially successful?

NetBackup evaluates the restore operation, not just whether some files appeared. A batch script can complete one portion of the recovery while another section is skipped, commented out, malformed, or left in the wrong recovery state.

The administrator in the discussion created a move template and set transaction logs to remain unrecovered. The database and logs appeared in the expected location, but the job still returned a partial-success condition with unclear User and Inf messages.

A NetBackup participant advised checking the batch script itself. The key fix was to remove comments from the required sections, update the target paths, and set the recovery state correctly for each stage.

That is a good troubleshooting order. Validate the script syntax and restore sequence before assuming the media, SQL Server, or backup image is bad.

What should be checked in a NetBackup SQL move template?

Check every MOVE section that maps original SQL Server files to their restore destination. NetBackup's SQL Server documentation shows that a generated template can contain commented TO lines and placeholder paths that must be edited when the database is moved.

The important detail is repetition. A restore involving a full database plus differential or transaction log images can have several sections that need consistent edits. Fixing only the first .mdf path is not enough if later log restore blocks still contain template comments or old destinations.

Review the logical database file name, the physical target path, and whether the relevant line is active rather than commented. Do the same for data files and log files.

Save a clean copy of the final script. A restore template is production recovery code. Treat it like code, with version control or at least a known-good runbook, rather than an ad hoc file edited during an outage.

What does NORECOVERY do during transaction log restore?

A SQL Server restore sequence normally keeps the database in a restoring state while additional backup images still need to be applied. In NetBackup templates, that means intermediate steps should use the equivalent of SQL Server's no-recovery behavior so the next differential or transaction log can continue the chain.

The final step is different. Once the last required log is applied, the database needs to be recovered so SQL Server brings it online. If the last step is left unrecovered, the files can be present and the restore can still look unfinished from the application's perspective.

The Reddit administrator reached exactly this second-stage problem. After getting the script to run, the database was still not online even though recovery had been specified in transaction-log sections. That is a reminder to verify the recovery state of the final restore operation, not simply every block independently.

Use SQL Server itself to confirm the database state after the NetBackup job completes.

Why is the Web UI recovery workflow easier?

NetBackup Web UI recovery points reduce the number of manual template edits for supported SQL Server workflows. Current documentation lets an administrator select a full, differential, or transaction-log recovery point and choose a specific recovery point, another point in time, or a transaction mark.

That is especially useful when the goal is point-in-time recovery rather than a complex database move. The UI can guide the restore sequence and destination selection without requiring the operator to edit every batch-file section by hand.

The participant in the discussion called the batch method "oldschool" and suggested the Web UI because it performs more of the recovery setup automatically. That is a reasonable choice when the NetBackup version and SQL configuration support the Web UI workflow.

Do not delete the script knowledge, though. Batch templates remain useful for repeatable automation, complex alternate-path moves, and environments where the recovery must be documented outside the UI.

How should point-in-time recovery be validated?

Define the exact target before starting. "Restore yesterday's database" is vague. "Recover the database to 14:04:30 before the bad transaction" is testable.

Confirm that the full backup, any differential, and the required transaction log chain exist through that point. Then perform the restore using the supported NetBackup workflow and verify the final database state in SQL Server.

After the database comes online, run application-level checks. Verify expected tables, recent records, logins, jobs, and dependent services. A database marked online can still be the wrong recovery point.

This is why the recovery-layer approach in the VM versus database backup guide matters. A VM restore can return the server, while a transaction-log restore answers a much more precise database question.

What logs and evidence should you save after a successful restore?

Save the final working template or document the exact Web UI choices. Record the backup IDs or recovery points used, the restore destination, stop time, recovery state, and the SQL Server verification that proved success.

Also capture why the original job was partial. If the root cause was commented template sections, document that explicitly. Otherwise the next administrator may treat the same warning as media corruption and start a much larger investigation.

For critical databases, repeat the recovery in a test environment. The Proxmox Backup Server guide covers a different platform, but the operational principle is the same: recovery procedures become reliable only after they have been exercised.

Measure restore time as well as correctness. A script that works but takes six hours to diagnose during every incident still misses the operational goal.

What would I do with a partially successful transaction log restore?

I would stop changing storage or backup policies and inspect the restore definition first. For a batch restore, I would compare every MOVE, target path, comment marker, and recovery-state field against a known-good template and the current SQL Server layout.

If the goal is a standard point-in-time recovery and the NetBackup release supports it, I would also test the Web UI recovery-point workflow because it reduces manual editing. After the restore, I would verify that SQL Server shows the database online and that the data matches the intended point.

A partially successful message is not automatically a failed recovery. It is a signal that the workflow completed only part of what the script asked for. Find the missing step before you rerun the entire chain.