Copy, Export, And Import Alert Configuration


Mini DBA lets administrators reuse alert configuration instead of manually recreating thresholds, enabled states, notification routing, custom alerts, and maintenance decisions on every monitored server. This is especially useful for managed service providers, multi-engine estates, standard production templates, and environments where development, test, and production servers should start from the same alert policy.

Mini DBA copy alert configuration screenshot placeholder

What Gets Copied

Alert configuration copy works with alert triggers. Depending on the alert type and platform, the copied configuration can include:

  • Enabled or disabled state.
  • Major and minor thresholds.
  • Duration settings.
  • Evaluation frequency.
  • Notification options.
  • Major and minor recipients.
  • Major and minor recipient groups.
  • Custom alert query configuration.
  • Ignore lists and alert-specific filtering.

Copying alert configuration is an overwrite operation for the target server. Mini DBA replaces the target server's current alert thresholds and notification settings with the selected source configuration. Review recipient groups and customer-specific routing before copying a production alert policy to another server.

Where To Find Copy Config

  1. Open the monitored server.
  2. Select the server's Alerts page.
  3. Open Configure.
  4. Select Copy Config.

The Copy Alert Config modal shows the current server, database type, and current engine instance. It has two directions:

  • Source: copy all alert configuration from another same-type monitored server into the current server.
  • Target(s): copy the current server's alert configuration to one or more same-type target servers.

Azure SQL logical server alert pages are roll-up pages for child databases and elastic pools. Configure and copy alert triggers from the individual Azure SQL database or elastic pool alert pages instead of the logical server roll-up.

Copy From Another Server

Use Source when the current server should receive another server's alert policy.

  1. Open the target server's Alerts page.
  2. Select Configure, then Copy Config.
  3. On Source, choose Existing Server.
  4. In MSP mode, choose the Source Engine Instance if the source is on another connected engine.
  5. Select the Source Server.
  6. Select Copy From Server.
  7. Review the overwrite warning.
  8. Select Overwrite to apply the configuration.

Use this direction when onboarding a new server that should match an existing template server. Choose a source server with the same database type and similar operational role. For example, copy a production SQL Server OLTP alert profile to another SQL Server OLTP instance, not to a development reporting server with different workload behavior.

Copy To Multiple Target Servers

Use Target(s) when the current server is the source policy and you want to push it to several same-type servers.

  1. Open the source server's Alerts page.
  2. Select Configure, then Copy Config.
  3. Open Target(s).
  4. In MSP mode, choose the Target Engine Instance if needed.
  5. Use Filter target servers to narrow the list.
  6. Select one or more target servers, or use Select Visible.
  7. Select Copy To Selected.

This is useful after tuning a standard alert template. For example, after setting CPU, long-running query, disk space, and notification routes for a SQL Server production template, copy that configuration to other SQL Server production instances in the same customer or server group.

Copy Between Connected Engine Instances

In MSP mode, the copy modal can show Source Engine Instance and Target Engine Instance selectors when more than one engine is connected. This lets you copy alert configuration between connected engines without manually moving files.

Use connected-engine copy when:

  • Both engine instances are online and connected to the console.
  • The source and target servers are the same database type.
  • You want to copy directly from one customer, site, or engine estate to another.
  • You want the console to apply the copied triggers through the connected Mini DBA Engine services.

Before copying between engines, confirm the target engine owns the target servers and the notification recipients or recipient groups make sense in that target estate. Recipient names that are correct for one customer may be wrong for another.

Export Alert Configuration From An Engine

For offline transfer, backup, or migration between engine instances that are not connected at the same time, export the alert trigger database file from the source engine's app data folder.

The trigger configuration file is:

trig.db

Default engine app data locations are:

Platform Default app data folder Trigger file
Linux or container /var/lib/minidba-engine /var/lib/minidba-engine/trig.db
Windows service C:\ProgramData\MiniDBA Engine C:\ProgramData\MiniDBA Engine\trig.db
Azure App Service %HOME%\site\data\minidba-engine %HOME%\site\data\minidba-engine\trig.db

If the engine was configured with Engine:AppDataFolder, AppDataFolder, or the MINIDBA_ENGINE_APPDATA environment variable, use that configured folder instead of the default path.

To create a clean export, copy trig.db using your normal backup or file-transfer process. Avoid editing the SQLite file directly. If possible, avoid making alert configuration changes while the file is being copied so the export represents one consistent alert policy.

Import From A Trigger File

Use Import From Trigger File when you have a trig.db file from another Mini DBA Engine and want to copy one source instance's alert configuration into the current server.

  1. Open the target server's Alerts page.
  2. Select Configure, then Copy Config.
  3. On Source, select Import From Trigger File.
  4. Choose the exported .db trigger file.
  5. Select the source instance inside the file.
  6. Select Copy From Server.
  7. Review the overwrite warning.
  8. Select Overwrite.

Mini DBA reads the uploaded trigger file, lists source instances of the same database type, and imports the selected source trigger configuration into the current target server. The uploaded file is used as a temporary source for the copy operation; it is not a new live engine database.

Best Practices

  • Copy only between servers of the same database type.
  • Keep a known-good template server per platform and environment.
  • Review notification recipients after copying between customers, sites, or engine instances.
  • Use server groups to make target selection safer.
  • Check custom alert SQL before copying it to a server with different databases or schema names.
  • Confirm thresholds after copying to smaller, larger, development, or bursty systems.
  • Keep an engine data backup before large alert policy changes.
  • Document the source server, target servers, engine names, date, and reason for the copy.

Troubleshooting

If source servers are missing, confirm they are the same database type as the current server and that their engine is connected.

If target servers are missing, confirm the selected target engine is connected and that the servers are monitored under that engine.

If importing a trigger file fails, confirm the file is a Mini DBA trigger database named or exported from trig.db, the file is under the upload size limit, and it contains source instances for the selected database type.

If copied notifications do not route as expected, review Alert Recipients, Recipient Groups, and integration settings such as email, Slack, Teams, PagerDuty, or Jira.

Related Pages