Your virtual NAS offers two things called backup, at two different layers. One of them dies in the same accident as the NAS itself. This guide is about telling them apart before it matters.
Snapshots feel like the professional option — one click and the whole machine is 'backed up'. But a snapshot sits on the same host and the same datastore as the VM it protects, so it survives experiments, not disasters. This guide separates the layers honestly: what snapshots are for, why they are not backups, and the Hyper Backup routine that leaves the host and therefore actually counts.
👆 Judge a backup by what disaster it survives — anything stored on the same host dies with the host (summary panel, recreated for illustration)
A virtual NAS has two layers, and each offers something called backup. ESXi offers snapshots and clones of the VM. DSM offers Hyper Backup of your folders and settings. The trap is that the hypervisor-layer tools feel like the stronger option — one click, whole machine — while quietly living on the same host, usually the same datastore, as the thing they protect. A datastore failure, a host failure or one bad deletion at the ESXi level takes the NAS and its 'backup' together. A copy that dies in the same accident as the original was never a backup; it was a spare tyre stored inside the burning car.
Snapshots are excellent — at their real job. A snapshot is a short-lived restore point for changes you are about to make: before a DSM update on this kind of install, before a risky settings experiment, before testing a package. Take it, make the change, test, then delete the snapshot within days. Left running, snapshots grow, slow the VM's disks, and create the worst illusion in virtualisation — an old, forgotten restore point mistaken for a backup strategy. Rule of thumb: if it is older than the change it protected, it is clutter, not safety.
The copy that counts is made by DSM itself and lands outside this host:
Proportionality keeps this sane. A pure learning lab with throwaway files needs only snapshots and a DSM config export — ten minutes of setup. The moment the lab starts holding anything with real value — test copies of office data, a media library you spent weekends building — it graduates to the Hyper Backup rule, no exceptions. And the ceiling never moves: DSM is Synology software, licensed for Synology hardware. Running it inside a virtual machine like this is a lab and learning exercise — some Synology services and packages may refuse to run or break, a DSM update can break the install, Synology support does not cover it, and it must never be the only place an office keeps its data. Backup discipline cannot promote a lab into a production NAS.
Build the lab from the video first — then protect it with the routine in this guide, not with snapshots alone.
▶️ Watch Full VideoAgainst a bad change, yes — that is exactly what snapshots are for. Against the host or datastore failing, no: the snapshot is stored with the VM and is lost in the same event. Data protection needs a copy outside the host.
Days, not months. Take it before a change, test the change, then delete the snapshot. Old snapshots grow, slow disk performance, and get mistaken for backups — the two failure modes this guide warns about.
A Hyper Backup task to a destination outside the host — an external drive, another machine or cloud storage — covering your folders and DSM configuration, plus one test restore to prove it works.