Minivers: A Windows Minifilter That Backs Up Files Before Ransomware Touches Them

What Minivers Actually Solves

Minivers addresses a specific failure mode: a file is overwritten or deleted, and only afterward do you realize you needed the old version. The driver intercepts operations on files with certain extensions and creates a timestamped copy before the operation proceeds. That is a narrow job, and the project stays inside it. The README names doc, docx, xls, xlsx, and txt as the monitored extensions, so it is aimed at office documents, not source code or media files. The stated use case is ransomware protection, because ransomware tends to encrypt or delete files with those extensions. But the README itself adds a parenthetical: "not tested though." That honesty matters. Minivers is a defensive tool for a single machine, not a distributed backup system.

How the Minifilter Mechanism Works

Minivers is a Windows file system minifilter driver, which means it registers with the I/O manager and sees file operations before they reach the underlying file system. The README does not describe the callback registration details, but the behavior is clear from the design. When a monitored file is about to be changed, deleted, or renamed, the driver creates a backup copy first. The backup filename follows the pattern <original-filename>.YYYYMMDD_hhmmss_mmm.minivers. The timestamp includes milliseconds, which reduces the chance of collision if the same file is modified multiple times in one second. The driver also enforces that files with the .minivers extension cannot be deleted, controlled by the IMMUTABLE_BACKUP_FILES define set to TRUE. That immutability is a deliberate trade-off: it protects the backups from accidental or malicious deletion, but it also means you cannot clean up old backups without changing the define and rebuilding.

Getting It Running: Build-Time Configuration

There is no installer and no compiled binary in the repository. You must build the driver from source using the Windows Driver Kit. The README gives no explicit build commands, so you will need to open the project in Visual Studio with the WDK installed and build for your target architecture. Configuration happens by editing minivers.c. To add a file extension, you edit the DECLARE_CONST_UNICODE_STRING block near the top of the file. The README shows a snippet with a comment block that says "File extensions to be taken into account," followed by a declaration that is cut off in the material. To change the backup file extension from minivers to something else, you edit the line DECLARE_CONST_UNICODE_STRING(MINIVERS_EXT, L"minivers"). To allow deletion of backup files, change #define IMMUTABLE_BACKUP_FILES TRUE to FALSE. To stop logging the executable name that caused the change, change #define LOG_IMAGE_FILENAME TRUE to FALSE. Every one of these changes requires a rebuild and a driver reload.

The Logging Feature and Its Limits

The README states that Minivers logs the name of the executable which produced the change, controlled by the LOG_IMAGE_FILENAME define. That is useful for forensics: if a ransomware binary touches a file, the log will tell you which process did it. But the README does not say where this log is written. There is no mention of a file path, an event log source, or a debugger output channel. In a kernel driver, logging often goes to DbgPrint, which is visible in a debugger but not in a normal system log. That could mean the log is only useful during development, not in production. The absence of this detail is a real gap. If you need an audit trail that you can actually retrieve after an incident, you will have to read the source to find where the log goes, and possibly modify it to write to a file or an ETW provider.

A Genuine Limitation: The Immutable Backup Problem

The most obvious limitation is the immutability of backup files. With IMMUTABLE_BACKUP_FILES set to TRUE, you cannot delete a .minivers file through normal file operations. That protects against ransomware, but it also means your disk will fill up over time. Every change to a monitored file creates a new backup, and there is no rotation, no quota, and no automatic cleanup described in the README. On a busy document folder, the disk usage can grow without bound. To delete old backups, you must either change the define to FALSE and rebuild the driver, or write a separate tool that uses kernel-level deletion APIs, which is not provided. This is not a tool for long-running systems unless you have a plan for backup retention. The README does not address this at all.

Where It Fits and Where It Does Not

Minivers is the wrong tool if you need versioning across a network, or if you need to restore files from a remote location. It creates copies only on the local volume where the driver is loaded. It is also the wrong tool if you need to protect files with extensions outside the hardcoded list, unless you are willing to modify and rebuild the driver. The right use case is a single workstation where you edit documents and want a last-known-good copy before each save. It is a kernel-mode safety net, not a backup strategy. The README's mention of ransomware is speculative, and the author says it is not tested. In a real ransomware event, the driver would need to fire before the encryption writes, and the immutable backups would need to survive the attack. That is a plausible design, but the project has not proven it.

Alternatives and Their Different Approaches

A common alternative is a user-mode file watcher, such as a script using ReadDirectoryChangesW or a tool like Dropbox's versioning. That approach runs in user space, which means it is easier to install and debug, but it can miss fast operations or be bypassed by a kernel-mode attacker. Minivers sits in the kernel, so it sees operations earlier and cannot be easily tricked by user-mode processes. Another alternative is a Volume Shadow Copy Service (VSS) based backup tool, which takes snapshots of entire volumes at scheduled intervals. VSS gives you point-in-time recovery of many files, but it is coarse-grained and requires administrative setup. Minivers is fine-grained per file and per change, but it only covers a few extensions. The trade-off is between kernel-level interception with a narrow scope versus user-level monitoring with broader coverage but less reliability under attack.

Editorial conclusion

Adopt Minivers if you need a lightweight, kernel-mode guard for a handful of document extensions on a single Windows machine and you are comfortable rebuilding a driver from source. Do not use it as a ransomware defense for a fleet, because it has no configuration surface, no logging to a central store, and no recovery mechanism beyond the local .minivers copies. Before deployment, verify that your Windows SDK and WDK versions match the project's build expectations, and test the immutable backup behavior on a non-production volume, since the README explicitly says the ransomware use case is not tested. If you need policy-driven protection with central management, look at a commercial endpoint product instead.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases