MaxBack Restore and Autorecovery
MaxBack provides automatic database recovery for scenarios where the backup tool does not use VSS restore.
The problem
Many backup tools do not perform a VSS restore. Instead, they restore the entire VM or perform a bare metal recovery. In these cases, the Windows VSS Service is never informed that a restore has happened, so the VSS Writer cannot prepare the database for recovery.
Without intervention, the database would be in an inconsistent state after such a restore — it was prepared for backup but never told the backup completed.
Autorecovery
Autorecovery solves this by automatically detecting restores and setting the database into a valid recovery state.
How it works:
- During backup, the VSS Writer stores a detection flag in the snapshot (during the Freeze event)
- After the snapshot is taken, the flag is removed (during the Thaw event)
- When the database host starts after a VM/bare metal restore, the restored snapshot still contains the flag
- The VSS Writer detects the flag and automatically sets the database into recovery state
Once in recovery state, you can apply transaction log files for point-in-time recovery before bringing the database back online.
Startup Scripts
You may have to apply log files manually before starting the database. If any automatic startup procedure opens the database, no more log files can be applied.
If you use startup scripts to start SAP or the database automatically after reboot, update them to check whether the database is already in admin state before opening it.
Enabling Autorecovery
Autorecovery is enabled via the EnableAutorecovery option. See Configuration. It is enabled by default in the Veeam and Azure Backup configuration sets.
Manual Autorecovery
You can also trigger autorecovery manually without a full VM restore — for example, when restoring only data volumes for a system copy:
maxback.vssclient db autorecovery -m <path to datavolume directory>
See the command-line reference for all options.