Quick answer
A virtual-machine snapshot records a point-in-time view of a VM or its disks within a virtualisation platform. It can be useful for a quick rollback, but what it depends on and how long it remains available vary by platform. A backup is a recovery copy created and retained under a backup process. Its usefulness depends on what it covers, where it is stored, how long it is kept and whether it can be restored.
Neither label alone proves independent storage, off-site protection, application consistency or a successful restore. Check the actual service design and test the recovery route. One terminology wrinkle: Proxmox Backup Server calls each saved backup restore point a “snapshot”, so that product’s use of the word does not mean it is a hypervisor VM snapshot.
What a VM snapshot and a backup are for
A VM snapshot is usually most useful before a planned change when you may need to return the VM or disk to its earlier state. The snapshot’s storage and lifecycle are controlled by the provider’s platform. Depending on that design, it may share storage, account, administrative access or failure risks with the VM. Do not assume a snapshot can be downloaded, moved to another provider or kept after a VM is deleted.
A backup is intended to give you one or more recovery points after data is changed or lost. Backups can be file-level or VM-level, full or incremental, and kept on local or remote storage. An incremental upload can still represent a complete restore point when the backup system maintains the references it needs. “Backup” does not automatically mean a separate company, account, data centre or country: verify the actual destination and access boundary.
Use a snapshot for a short-term rollback only when the provider confirms how it works and how to restore it. Use a backup plan for recovery over time, and check its coverage, retention, security boundary and tested restore procedure. For important systems, a backup in a separately controlled failure domain can reduce risks that a copy beside the VM would share.
A running server and its database may need extra care
A point-in-time disk capture of a running server may be crash-consistent: the operating system and database see a state comparable to an unexpected power loss. That can be recoverable, but it is not the same as proving that an application completed every write cleanly. A database, queue, uploaded file and external service may not all represent one coordinated moment.
For an application that needs a consistent recovery point, identify the database and files that must agree. Use the application or database’s supported backup method, or arrange a suitable quiesce or write-pause with the responsible operator. Confirm the method’s limits, then test the recovered application on an isolated target. A storage snapshot can be part of that process; it does not by itself prove application consistency.
Also distinguish a product’s “snapshot mode” for making a backup while a VM is running from a separately retained VM snapshot. In Proxmox, for example, a VM backup process can use an internal snapshot mechanism for consistency while the resulting backup is stored by Proxmox Backup Server. The words describe different layers of that workflow.
What the Novasean VM Start schedule specifies
Only when an accepted order incorporates the VM Start with Managed OS schedule, the included arrangement is a scheduled daily VM/server backup to Proxmox Backup Server in the same Netherlands data centre as the Proxmox cluster. The schedule covers the supplied VM virtual disks within the service allocation and specifies retention settings of three most recent, seven daily, four weekly and six monthly points. Those settings can overlap; they do not promise 20 distinct restore points, and missed or failed jobs can reduce what is available.
This is a same-data-centre backup, not a geographically independent copy. Separately mounted remote storage, an external database or service, local devices and changes not yet present in a completed backup are outside the stated VM-disk coverage. The schedule does not promise application-consistent database recovery, a recovery point objective (RPO), a recovery time objective (RTO) or a restoration deadline. The customer retains root access, is responsible for applications and databases, and validates the application after recovery.
The schedule does not promise a separate customer-managed VM snapshot feature. Do not infer that a panel control, snapshot add-on, backup entitlement or Virtualizor feature is available to your account: your accepted order and actual permissions determine that. For an included restore, contact support with the affected VM and the desired available recovery point; the operator confirms the point and obtains your instruction before a destructive restore, except where immediate action is lawfully required.
Choose a recovery point for the failure you expect
- Undo a change made moments ago: ask whether an authorised, recent snapshot exists, what it includes and whether it can be restored without losing later writes.
- Recover a deleted file or older database state: check whether the backup contains the required files or database export and whether its retention still includes a point from before the deletion.
- Recover after losing a VM, node, account or data centre: ask whether the backup is outside that same failure boundary and how you would obtain access if the primary account or platform were unavailable.
- Return a working application: confirm database consistency, external dependencies and the isolated restore test. A booting VM alone is not proof that the service works.
One mechanism may not cover every failure. Choose the recovery point by its contents, age, destination, access path and demonstrated restore—not by whether the provider calls it a snapshot or a backup.
Questions to ask before relying on a snapshot or backup
- Which files, disks, databases, configuration and external data are included or excluded?
- Where is each copy stored, and what storage, provider, account, administrator and location risks does it share with the source?
- How often are recovery points created, what retention applies, and how can you confirm the specific point completed?
- Who can initiate a restore, which targets are available, and could the action overwrite newer data?
- Has a recent restore been tested on an isolated target, and which application checks passed?
Keep application-level exports or an independent copy where your service terms leave those responsibilities with you. For the procedure, see how to check a backup recovery window, how to prepare an application-consistent backup and how to test a restore without overwriting production.
Frequently asked questions
Is a VPS snapshot the same as a backup? No. A VM snapshot and a backup are different recovery mechanisms, although vendors sometimes use “snapshot” to name a retained backup restore point. Check the provider’s exact definition, storage and restore process.
Can a snapshot replace an off-site backup? Not unless the actual design places a recoverable copy outside the relevant failure boundary and the service terms confirm it. Many snapshot arrangements depend on the VM platform; verify instead of assuming.
Does a backup guarantee a working database? No. Check how the backup captures database writes, what it contains and whether the restored application passed a test. A successful job alone is not an application test.
Does every Novasean VPS include snapshots? No general snapshot entitlement is stated here. For the VM Start with Managed OS service, use the backup arrangement only if the accepted order incorporates its current schedule. Other services may have different terms.
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.