Start with an isolated recovery test
A restore can replace data and affect connected clients. Test the recovery set on an isolated, approved environment before a production recovery. Keep restored schedules, email delivery and endpoint connections inactive until the recovery owner authorizes them.
Identify the backup date, expected recovery point, application release, SQL version, files and any required encryption keys. Preserve the current production state under the incident plan before deciding to replace it.
Restore the database with the DBA
In an existing SQL administration tool, select the intended restore target and backup set, then review the destination database and file paths. For a rehearsal, use a separate target so the live database is not overwritten. Follow Microsoft’s restore procedure; the required backup sequence depends on the recovery model and desired point in time.
Have the DBA validate version compatibility, recovery state and any required certificates or keys. Do not enable overwrite or discard a required log backup simply to bypass a restore error.
Reconnect the matching application
- Restore the approved matching application release and its coordinated App_Data/configuration set.
- Review the license, service configuration, endpoints and web mode for the recovery environment.
- Have the administrator update the database connection through the supported configuration process.
- Start and check GoMyidServer and GoMyidCore when the recovery plan permits.
- Verify both the login page and registration/database check; a login response alone does not establish data recovery.
Validate data and behavior
Use an authorized reviewer to inspect expected groups, users and representative report records from the recovered period. Check that sensitive configuration files remain protected and that no unintended mail or endpoint connection occurred during the rehearsal.
Record elapsed recovery time, the newest recovered data, missing intervals and unresolved differences. A restored database with an incompatible application version is not an accepted recovery.
Return to service deliberately
Have the recovery owner approve cutover, network access and resumption of collection or schedules. Validate one pilot endpoint before broad reconnection. Keep the recovery record and investigate why restoration was needed. If any acceptance check fails, follow the incident plan rather than repeatedly restoring over the same target.