Restoring one database can recover application data without replacing unrelated websites and mailboxes. The selected database is returned to the recovery point and current data can be overwritten. This is not a merge of old data with new orders, bookings or account changes.
IN THIS ARTICLE
Prepare for the change
Identify the exact database, application and backup timestamp. Export the current database and preserve it outside the account. Decide how to stop new writes and what to do with legitimate transactions created after the recovery point. For a busy business application, test restoration separately first.
01 Restore one Plesk database without replacing the whole subscription
- Open Backup Manager and choose a completed backup containing the database. Review its scope and engine compatibility.
- Select individual-object restoration and the database object type, then select only the intended database. Read the overwrite behaviour before proceeding.
- Put the affected application into an appropriate maintenance state and pause workers or scheduled tasks that can write independently of the website.
- Supply the correct backup protection password where requested and start the restore. Monitor the complete result, including database-user or credential warnings.
- Check the restored schema and representative business records. Reconcile later legitimate data through an application-supported process before allowing new writes, if that is part of the recovery plan.
How do I check the restored database?
Test the application login, reads and a controlled write. Compare important record counts or business totals with the intended recovery point. Verify database credentials and background jobs, then reopen service deliberately and monitor errors.
If the change does not work
If access fails after restoring without the original protection password, some restored credentials may have changed and need authorized replacement. Do not repeatedly restore over newly resumed customer activity. If the chosen point is wrong, use the preserved current export or another verified backup through a planned recovery. A code rollback may also be required when database schema and application release no longer match.