Choose a restore target
Choose the backup point and target before restoring. A same-VPS restore can overwrite current data; a listed copy does not prove application consistency.
Identify what is missing, its last good time and any valuable data still on the VPS. For one file or database, ask whether isolated or application-level recovery can avoid replacing the VM.
This guide assumes a backup point is visible or confirmed by the operator. If the expected point is missing, use the related missing-backup guide before planning any restore. A panel listing is evidence that a point is recorded; it is not proof that the application can be recovered from it.
Confirm the backup and who may restore it
- Identify the exact VPS and backup timestamp, including its displayed time zone. Compare it with the incident timeline and any later legitimate changes.
- Read the accepted service schedule for backup scope, retention and restoration responsibilities. A Virtualizor feature shown in vendor documentation does not mean it is enabled for your Novasean service.
- Check whether your authorised VPS panel offers a permitted restore action. For Virtualizor Backuply, end-user restore depends on the assigned backup plan; your actual backup system and entitlement may differ. An operator may need to perform the restore instead. Do not use an administrator procedure or credentials you have not been assigned.
- Agree with the application owner who approves downtime, who performs the VM restore and who validates the application.
For the currently described VM Start with Managed OS offer, Novasean describes daily VM backups stored in the same Netherlands datacentre; the accepted schedule defines scope and retention, and the customer team validates applications after recovery. Do not transfer those terms to another VPS or assume an off-site copy, a guaranteed recovery time or round-the-clock response.
For an accepted matching VM Start with Managed OS order, ordinary VM-level restore from an available included backup is in scope; confirm the actual point and customer instruction before an overwrite.
Preserve the current state before any overwrite
Stop at the confirmation screen until the source point and destination are unambiguous. Record current application versions, IP addresses, DNS dependencies, database state and recent changes. If the VPS is still accessible, arrange a separate current-state copy where feasible and verify how it could be used. Limit further writes only when the application owner agrees; an abrupt shutdown can itself lose transactions.
Restoring onto the original VPS may replace its current contents. Virtualizor also documents an administrator option to restore to a new VPS. Ask the operator whether an isolated target is available and suitable for testing before touching production. A new VPS can need different IP addresses, network rules, licences and capacity; do not redirect traffic to it until these are checked.
Select the recovery route
Isolated new VPS
Consider this when you need to inspect the backup or extract data while preserving the current VM. Confirm operator availability, separate capacity, access controls and test data handling.
Existing VPS
Consider this only when the agreed recovery point must replace the current VM state. Obtain explicit approval for the expected data loss and downtime; preserve recoverable current data first.
Application-level recovery
Consider this when only a database, account or file set is missing and a suitable application backup exists. Check application consistency and restore only the intended data.
Virtualizor documents same-VPS and new-VPS restore options for administrators; the available route for your account and service may be narrower. Do not treat a test restore on production as a safe verification method.
Illustrative choice: if production contains orders entered after the backup date, an isolated restore may allow comparison before any approved production overwrite. Record who will reconcile those later orders.
Run the approved restore and validate the workload
Once the operator and application owner agree on the backup point, target and rollback path, use only the authorised panel action or ask Novasean support to perform the operator step. Record the task identifier and wait for it to finish; a completed VM task does not confirm that the application is healthy. If the task reports an error, capture its status and stop rather than repeatedly restoring to the same target.
Check boot and console access, filesystem and database integrity, representative records, application login and transactions, external storage, scheduled jobs, outbound mail, TLS, monitoring and DNS from outside the VPS. Compare expected changes since the backup and plan how to replay legitimate transactions. Rotate secrets if the incident involved compromise. Keep the original and current-state copies until the application owner accepts the recovered result.
Give support a precise recovery request
Provide the service and VPS identifiers, incident time and time zone, visible backup timestamp, required data, whether production is still running, preferred restore target, approved maintenance window and named application tester. Ask Novasean to confirm the applicable entitlement, whether a new-VPS test is possible, the expected impact and the operator step. Keep passwords, private keys and raw customer data out of the ticket.
Can I press Restore as soon as a point appears? No. Confirm its age, target and effect on later data first. Will a VM backup restore my application perfectly? Not necessarily; application-consistent data and external dependencies need separate checks. Who verifies recovery? The application owner must test business functions; a managed service schedule defines any operator work.
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.