SUMMARY
SQL backups continue to try to run against a database that no longer exists in production or was purposefully taken offline.
ISSUE
SQL backups continue to try to run against a database that no longer exists in production or was purposefully taken offline.
There are 3 potential scenarios:- A single DB was removed from production, but the SQL instance itself and client server are still online
- The entire SQL instance has been removed, or, upgraded to a newer SQL release causing the instance ID to be changed and no longer able to be referenced
- The production server is no longer in production and can no longer be reached.
RESOLUTION
Scenario 1
In this scenario, the SQL schedules should still be visible in the UI under the registered SQL instance. However, the DB name may be left checked but grayed out and unable to be selected to remove the DB from the schedule. in this case, remote the schedule and create a new schedule that does not contain that database.NOTE: This issue in Scenario 1 has been corrected with the new Satori user interface, so SQL databases that have been removed will no longer be displayed as "greyed out".
Scenario 2
The SQL client may be visible in the UI, but the SQL instance containing the database will no longer be visible to access schedule configuration for that application. To resolve:
- Log into backup system UI
- Select "Jobs"
- In the legacy interface, select Reports > Schedule history Reports
- Locate the schedule name listed in the UI for the schedules that contain the database that is failing (this will be the schedule name in your schedule history or failure report emails as well)
Examples:
- "Server1 SQL System DBs"
- "payroll SQL Weekly Full Daily Diff "
Log into the Unitrends Appliance via SSH with Putty. It is recommended to make the window full screen.
Check the appliance database using the following command to list all configured schedules on the appliance:
psql -c "select schedule_id,name,description from bp.schedules"Comparing the names visually in output of the above to the schedule names you identified earlier, you should be able to match the names to a schedule_ID value located in the first column of output.
Lets say schedule IDs 25 and 46 matched your schedule names. To remove them:
psql -c "delete from bp.schedules where schedule_ID=25" psql -c "delete from bp.schedules where schedule_ID=46"The offending schedules will no longer run.
Scenario 3
If the server has been entirely removed from production, and you no longer want any backups of it at all, or, you want to remove it from the UI but the client will not delete because it reports the server is protected in one or more schedules, follow scenario 2 first to remove all the SQL schedules, remove any remaining file or baremetal schedules from the UI normally, and don't forget to also remove the client from any archive schedules after archiving any last backups you want to keep. You can then remove the client from the UI if you wish.CAUSE
If a database is to be discontinued in production, the recommended practice is to de-configure schedules in the unitrends UI for that database, instance, or client before removing the database from production. When this is not done, we will retain information to protect the database, but if it is no longer reachable, the UI is coded to not display the instance, and simple deletion or adjustment of the schedule is not possible.