Configuration Backup and Recovery

Starting with v8.5, SQL Backup Master encrypts the sensitive parts of its configuration – cloud storage credentials, database and account passwords, and stored authorization tokens – and binds that encryption to the machine that created it. This is a meaningful security improvement, but it changes how you move or recover a configuration. This article explains the new behavior, how to keep a portable backup of your configuration, and – importantly – why losing your configuration never prevents you from restoring your databases.

What changed: your configuration is tied to its host

SQL Backup Master stores its settings in a small set of files under C:\ProgramData\Key Metric Software\SQL Backup Master\. In earlier versions, the secrets inside those files were encrypted with a fixed key built into the product, which meant a copy of the files could be decrypted on any machine. In v8.5, those secrets are instead protected with keys that are unique to the host (using the Windows Data Protection API together with a per-installation key). The practical effects:

• A copied configuration file is opaque off-host. If someone obtains a copy of your Jobs.xml or settings files, they cannot read your stored credentials on another machine – the encryption keys never leave the originating host.
• You can no longer migrate configuration by copying files. Dropping a configuration file from one machine onto another will fail to load, with a message indicating the configuration is locked to the machine that created it. Use the Export/Import feature described below instead.

Keep a configuration export as a second copy

SQL Backup Master can produce a portable, password-protected copy of your entire configuration. We recommend creating one as part of your routine and keeping it somewhere safe – it is the supported way to move settings to a new machine, and a convenient way to restore your job definitions quickly after a rebuild.

To create an export, open the Tools screen and choose Configuration export, then:

• Choose a location for the .sbmconfig file.
• Set a master password (minimum 12 characters) and confirm it.

The resulting .sbmconfig file is encrypted with your master password and is fully portable – it can be imported on any v8.5 (or later) installation, on any machine, via the Configuration import option on the same Tools screen. On import you will be prompted for the same master password, and the secrets are re-protected under the destination machine's own keys.

Store the master password carefully. The export is protected by that password alone, and there is no backdoor or recovery mechanism – if the password is lost, the export cannot be opened. For the same reason, treat the .sbmconfig file as sensitive: anyone with both the file and the password can read its contents.

Recovering your configuration

Which recovery path applies depends on how you are bringing the machine back:

• Full system restore (recommended for disaster recovery). If you restore the entire machine from a system-image or system-state backup – including the Windows registry and system files – the host-specific encryption keys are restored along with everything else, and your SQL Backup Master configuration loads normally with no extra steps. This works even when restoring to replacement hardware.
• New machine, clean reinstall, or data-only restore. If you reinstall Windows, build a new host, or restore only the data folder (not the full system), the original encryption keys are not present and the old configuration files cannot be decrypted. In these cases, import your .sbmconfig export to bring everything back. If you don't have an export, simply re-create your jobs and re-enter their credentials – SQL Backup Master will be fully operational again.

This is why a periodic .sbmconfig export is worthwhile: it turns the "new machine / reinstall" case from a re-entry exercise into a quick import.

Losing your configuration never puts your data at risk

It is worth stating plainly: your backups do not depend on SQL Backup Master's configuration to be restorable. SQL Backup Master writes standard backup files to your storage destinations; it is a convenience layer for scheduling, transferring, and restoring them – not a proprietary container that locks your data inside the product. Even if you were to lose your configuration entirely, with no export on hand, you can always recover your databases manually:

• Download the backup file from its storage destination (using the provider's own console or any standard client).
• If the backup is compressed, extract it with any standard archive tool. If you configured an archive password on the job, you'll need that password to extract – so record your archive passwords somewhere safe.
• Restore the resulting .bak file with SQL Server Management Studio (RESTORE DATABASE) or through a fresh SQL Backup Master installation's recovery tools.

In other words, a lost configuration costs you convenience – you may have to re-enter settings or restore by hand – but it never traps your data. The databases in your backups remain fully recoverable.

Recommended practices

• Create a .sbmconfig export after significant configuration changes, and keep a recent copy off the SQL Backup Master host.
• Record your export master password and any per-job archive passwords in your organization's secrets store or password manager.
• Include the SQL Backup Master host in your regular system-image / system-state backups, so a full restore recovers the configuration automatically.
• Test your recovery path once – either a full-system restore or a .sbmconfig import on a spare machine – so there are no surprises on the day you need it.

Getting help

If you're planning a migration to a new host, recovering after a failure, or unsure which recovery path applies to your situation, please reach out to SQL Backup Master support and we'll be glad to help.