Single-item restore is not Russian roulette

The classic recovery ticket: “we need one config file from last Tuesday's backup of VM X.” It always arrives at the worst possible moment — the service is down, the clock is running, and the only copy of that file lives inside a multi-hundred-GB VM image backup.

Full-VM backup is still king — and that's exactly the point

Image-level backup of whole VMs remains the main disaster-recovery use case: it is the only thing that brings an entire system back after ransomware, storage loss or a botched upgrade. The real question is what happens when you don't need the whole VM — just one file out of it. Single-item restore should come from the same image backup you already have, not from a second file-level job that doubles your backup window, and not from an agent fleet you now have to manage.

The Russian-roulette way

Sub-par backup solutions — Bacula among them — answer that ticket by mounting entire VM disks: restore or attach the full image, then work through open-source mounting stacks (libvirt, libguestfs, guestmount, ntfs-3g…) that the backup vendor itself does not support, until — hopefully — a filesystem appears. In practice that means:

• Several minutes to hours per attempt on real-world disk sizes;
• Windows disks not supported by default — NTFS needs extra third-party packages nobody validated against your backups;
• Unsupported tooling: when the mount fails, you debug it yourself, by trial and error, mid-outage;
• A kernel attack surface: parsing an untrusted filesystem image with the host kernel's own drivers.

Each spin of that cylinder might work. During an outage, might is not a recovery plan. And you will not find a Gartner-quadrant leader whose single-item restore story is “hand-mount the disk images with unsupported open-source tools.”

The NGBackup way: the backup indexes itself

NGBackup's Granular Restore turns a VM image backup from a black box into a browsable filesystem. The numbers below were measured in July 2026 on a production deployment (~80 vSphere VMs):

• Open a 17 GB VM image in ~1.3 s. As each backup job finishes, the Storage Daemon builds a persistent disk map of where every guest block lives inside the backup volumes. The expensive scan happens once, at backup time — not at restore time. Opening the same image without the map took ~20 minutes: a ~900× improvement.
• One file out in 0.6 s, streamed from the web console and SHA-256-verified identical to the source.
• Chain-aware: browse the VM as of any incremental point — the engine composes the Full plus the CBT deltas on the fly. No synthetic full, no staging datastore.
• Every NGBackup VM plugin speaks it: VMware vSphere, Proxmox VE, Microsoft Hyper-V, Nutanix AHV, Apache CloudStack and OCI Compute all write the same self-indexing image format — granular restore works across your whole fleet, whatever the hypervisor.
• Windows and Linux disks are first-class: NTFS, ext and btrfs are parsed by NGBackup's own userspace readers. No mount(2), no loop devices — a malicious filesystem image can never reach the host kernel.
• Agentless and read-only by construction: nothing installed inside guests; sessions expose list/stat/get and nothing else, are ACL-gated at the Director, ticketed and fully audited.

One console, six recovery modes

In NGBackup's Restore Studio, Granular Restore sits alongside Complete VM Restore, Database Restore, Point-in-Time and the other recovery modes — full-VM disaster recovery stays first-class, and single-item is one click on the very same backup. Pick a job, the file tree appears in about a second, click the file, download.

Stop spinning the cylinder. Book a free POC or get the software and time your own 0.6-second restore.