SQL Backup Recovery

Yes. Backups go bad in predictable ways: power loss mid-backup, a failing disk under the backup folder or a copy that was cut short over the network. Univik reads the damaged .bak at a low level and recovers the tables and rows that survived. The more of the file that is intact, the more it brings back.

Often yes. Try the native ladder first: RESTORE VERIFYONLY tells you the backup is damaged, RESTORE HEADERONLY shows what the file claims to contain and RESTORE WITH CONTINUE_AFTER_ERROR attempts a salvage. That last option still fails on header or media damage and leaves missing pages behind. Univik takes the other route. It reads the .bak as a file, with no server and no RESTORE, then salvages what is readable.

Yes. When a backup was cut off partway through, Univik reads the part that made it to disk and recovers the tables held in it.

Yes. Plain backups work, MS_XPRESS compression is handled at every transfer size and the ZSTD compression that arrived with SQL Server 2025 is decoded too.

SQL Backup Recovery works on the .bak backup file. SQL Database Recovery works on the live MDF data file, for corrupt databases, deleted records and dropped tables. Use this page for a backup and that one for a database.

Every release from SQL Server 2000 up to 2025 is covered, with 2008, 2012, 2014, 2016, 2017, 2019 and 2022 in between. The recovery detects the version from the backup itself.

Yes. Univik opens the .bak in read only mode and never writes to it. Every recovered result goes to a new file, so your original backup stays exactly as it is.

Yes. The recovery reads views, synonyms, stored procedures, functions, triggers, assemblies, user defined data types, rules, defaults and sequences straight from the .bak file. Each object is scripted as T-SQL without restoring the backup, so the rebuilt database matches the moment the backup was taken.

The usual suspects are Msg 3241, the media family on device is incorrectly formed, Msg 3013, RESTORE DATABASE is terminating abnormally, Msg 3183, a read error inside the backup set and the cyclic redundancy check failure that surfaces as operating system error 23. Each one means RESTORE has hit bytes it cannot trust. The recovery does not depend on RESTORE, so these errors do not stop it.

That is a striped media set, made when the BACKUP command lists more than one DISK target. The data is spread across every file in the set and no single stripe holds the whole database, so keep all the parts together and load the full set. The recovery works through the stripes as one backup.