Quick answer
Before reinstalling a VPS, identify every database, create an engine-appropriate export and preserve it outside the affected disks. Restore it on an isolated compatible target with the required users, roles and files. Do not destroy the source until the recovery path is accepted.
Do not reinstall until the database can be recovered
An OS reinstall can remove the only database copy. Preserve a current engine-appropriate backup outside the VPS and test recovery with matching application files and configuration. A successful VM backup job alone does not prove database-consistent recovery.
First confirm who owns the application and authorises downtime and possible loss of recent changes. Do not click a Reinstall, Rebuild or Reset action because a backup job merely reports success. If any database, external dependency or restore owner is unknown, stop and inventory it before making a destructive change.
Find the actual database and its owner
List the application and environment, database engine and version, instance location, database names, authorised export account, storage or container volumes, and the person who can validate restored data. Check application configuration through an approved administrative route without copying credentials into a ticket. A database may run inside the VPS, in a container volume, on a separate VM or as an external managed service. Reinstalling this VPS affects those locations differently, but a separate database can still depend on files or secrets held on the VPS.
Record the last known good time and any writes that will continue during export. For a busy application, agree a write pause or a documented method to reconcile changes after the capture. Exporting database rows at one time and uploaded files at another can leave broken references; the application owner must define a consistent recovery point across both.
Capture a database export suited to the engine
Use the database vendor’s supported backup tool and a credential route that does not expose a password in a command line or shell history. For MariaDB, mariadb-dump creates a logical SQL export. Its --single-transaction option can capture a consistent state for transactional tables such as InnoDB, but it is not a universal guarantee for other storage engines or concurrent schema changes. Check whether stored routines and scheduled events need their documented export options; triggers and grants also need review. For PostgreSQL, pg_dump captures one database, not cluster roles or tablespaces. Plan a separate authorised capture of those cluster-wide definitions when the restored application needs them.
Run the method appropriate to the installed engine and version with sufficient read privileges, capacity and a destination outside the disk that will be replaced. Record the tool version, start and end time, database identity, exit status and any warnings. Check both a nonempty output and a successful exit status, and review warnings; even these checks do not prove a usable restore. Protect the export as sensitive customer data, transfer it through an approved encrypted route and restrict access and retention.
Test the recovery path before destroying the source
- Check the export inventory against the expected databases, schemas, tables and application records, plus the required roles, extensions, routines and events.
- Restore to an isolated, authorised test database using a compatible engine and version. Do not import into production merely to test. Read import errors and confirm object ownership and permissions.
- Connect a safe application test copy to the restored database and matching files. Validate a representative read and, where safe, a reversible write through the application.
- Record the tested point, restore steps, elapsed time, missing components and the application owner’s acceptance. Keep the source VPS and off-VM backup intact until the recovery plan is approved.
If the restore fails, the export is incomplete, or the application cannot read its data, correct that gap before reinstalling. A VM-level backup can be an additional recovery route only when the specific snapshot exists and its restore scope and application consistency have been checked.
Example: PostgreSQL data imports but the application cannot connect
A pg_dump export can contain the database while omitting cluster-wide roles. An import may restore tables but leave the application unable to connect with its required identity. Plan the authorised roles and permissions separately, then test the restored application without sending production jobs or messages.
If the dump opens but import fails or required roles, extensions or application files are missing, stop the reinstall. Resolve the failed recovery check while the original data remains available.
Common questions before a VPS rebuild
Does a VM backup replace a database export? Not automatically. Confirm the actual VM point, covered disks and whether the running database can recover consistently; an application-aware export may still be required.
Does pg_dump include PostgreSQL users? No. Roles and tablespaces are cluster-wide and need their own plan.
Can I leave the only dump on the VPS? No. A reinstall can remove it with the old guest disk. Preserve a protected copy outside the target and test it.
What should I send support? Send the service identifier, approved maintenance window, engine and version, affected application, backup method and test result, and the authorised restore owner. Do not send database credentials, raw dumps or private keys in an ordinary ticket; agree a secure transfer route if a file is needed.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.