Key Points
- NinjaOne Backup is VSS aware, meaning applications and databases that support Volume Shadow Copy Service can be backed up in an application-consistent state as part of a standard image backup, with no special configuration required.
- Microsoft SQL Server is VSS aware, so a normal image backup produces a viable, restorable copy of the database without any extra steps.
- Not every application is VSS aware. For those, a script-generated backup file (like a SQL BAK file) gives you a clean, application-native copy to protect alongside your image backup.
- SQL databases running in Simple recovery mode can have their transaction logs purged automatically at each checkpoint.
- Image backups can be mounted to recover individual files, like a single database file, without restoring the entire image.
Backing up a Windows server is straightforward until you get to what’s actually running on it. A database doesn’t sit still the way a static file does; it’s mid-transaction, mid-write, and constantly changing. A backup taken at the wrong instant can leave you with a copy that looks complete but won’t restore cleanly. NinjaOne’s Backup® handles this through application awareness, using Microsoft’s Volume Shadow Copy Service (VSS) to do some of the heavy lifting.
How application-aware backup works
VSS is a Windows service that coordinates with applications to create a shadow copy — a snapshot of a volume at a specific point in time — without stopping the application or interrupting users. Applications that support VSS use something called a VSS writer, which tells the snapshot process how to freeze the application’s data in a consistent state before the copy is taken.
NinjaOne Backup interfaces directly with these VSS writers as part of a standard image backup. For any VSS-aware application, that means the backup captures the application in an application-consistent state automatically, with no separate backup job or special scripting, just a normal image backup that happens to also protect what’s running on top of the OS.
That being said, VSS awareness in the backup tool doesn’t override the application vendor’s own guidance, and you should check what the vendor recommends for backing up their specific application, since some have additional requirements beyond what VSS alone covers.
SQL server: The VSS-aware example
Microsoft SQL Server is VSS aware by default, using its own built-in VSS writer. A standard image backup of a server running SQL Server produces a usable, restorable copy of the database with no extra configuration.
A couple of things worth knowing about how this plays out in practice:
- Log truncation in Simple recovery mode: SQL Server truncates its own transaction log automatically at each checkpoint when the database runs in Simple recovery mode.
- Log truncation in Full recovery mode: In Full recovery mode, the log only truncates when a transaction log backup runs. A full database backup won’t do it, and neither will your image backup, so the log keeps growing until something actually backs it up. If your databases run in Full recovery mode, you need a SQL maintenance plan that includes log backups, not just Full ones, which is part of the SQL-native backup routine covered below.
- Granular file recovery: With NinjaOne image backups stored in Hybrid or Cloud-only destinations, you can mount the image and pull an individual file — like a specific database file — without restoring the full image. This matters when you need only one file back and don’t want to spin up a complete restore to get it.
Handling applications that aren’t VSS aware
Not every database plays nicely with VSS. Here’s two common examples.
MySQL is not VSS aware. As a result, the standard approach used by NinjaOne is to run a script to generate a backup of the database first, then backing up that resulting file with either an image or a file/folder backup job.
QuickBooks Desktop is also not VSS aware. A standard image backup still produces a crash-consistent copy, but not a guaranteed application-consistent one. We recommend leveraging QuickBooks’ own internal backup tool, scheduled to run on its own, for a more reliable, application-native copy. When you do, NinjaOne Backup simply protects the file that tool produces, on top of the image backup already covering the machine.
The pattern across both is the same. When an application doesn’t support VSS, let the application (or a script) produce a clean, application-native backup file first, then protect that file with your normal backup job.
Why a BAK file still has a place
Even for SQL Server, which is fully VSS aware, there’s a case for also generating a dedicated backup file. A pre-script can run SQL Server’s native backup command to produce a BAK file, which NinjaOne Backup then protects like any other file.
This gives you a second, more flexible recovery option alongside the image backup. Here’s a few reasons this is worth setting up.
- Faster, more targeted restores: Restoring directly from a BAK file with SQL Server’s own tools can be quicker than restoring an entire image just to get the database back.
- Tighter recovery point objectives: SQL-specific backup jobs and maintenance plans can run more frequently than your image backup schedule. If you need a shorter recovery window than a daily cloud image backup allows, you can run SQL backups more often and protect just those backup files with a file/folder backup job.
- A backup that lives independently of the OS: A BAK file is portable and understood natively by SQL Server tools, which makes it useful for scenarios like migrating a database to a different server, not just disaster recovery.
If you go this route, it’s worth storing your SQL-specific backups and maintenance plans on a volume that isn’t covered by your image backup job, then using a separate file/folder backup job to protect just those files. That keeps the two backup strategies cleanly separated instead of overlapping.
Why application awareness matters for recovery
A backup that completes successfully isn’t the same as a backup that restores successfully, and that gap is exactly what application awareness closes. VSS support means your image backups capture SQL Server in a state that’s actually usable when you need it, without extra work on your part. For the applications VSS doesn’t cover, the same principle still applies: let the application produce a clean copy of its own data, then back up that copy.
Getting this right means the difference between a bad day spent trying to recover a database that looked backed up but wasn’t, versus a simple routine restore.
