What Is Malware Scanning in Backup Software?
Malware scanning in backup software is a feature that checks backup data for viruses, ransomware, and other malicious code, so you can find an infected restore point before you restore it. It inspects the stored copy, not the live system, usually with an antivirus engine, so production keeps running normally. Without that check, a restore can bring the same malware back into a system you have just cleaned.
A scan can flag infected files or whole restore points, so an administrator can decide whether to restore, clean, or discard them. Many products run the scan automatically after a backup finishes or before a restore starts. Depending on the product, a scan covers the full disk or only chosen locations, such as system folders and user data. Scanning more takes longer, so the scope is usually a trade-off between depth and speed.
It is different from three related controls:
Antivirus on the source server protects the running system, but does not check what is already stored in a backup.
Backup encryption hides content from outsiders, but does not tell you whether the content is clean.
Immutable storage stops backups from being changed or deleted, but an immutable copy of infected data is still infected.
This guide explains why backups need malware scanning, how a scan works, where it can run, and what to do when malware is found. It also covers the limits of scanning and the best practices that make it useful.
Why Backups Need Malware Scanning
Backups are the last line of defense, so an infected backup removes the safety net you were counting on. Three problems explain why scanning matters:
Backups can be infected at the source. A backup is a faithful copy. If malware was on the server when the job ran, it is in the backup.
Restores can reintroduce malware. CISA's StopRansomware Guide warns that dropper malware must be identified before you rebuild from backups, or the compromise continues.
Attackers target backups. The same guide notes that many ransomware variants try to find and then delete or encrypt accessible backups. Storage-side protection helps here, as explained in this guide to protecting backups from ransomware.
For example, suppose malware enters a server on Monday and starts encrypting files on Friday. Every backup from Monday to Thursday already contains the malware. Restoring Thursday's backup without a scan would restart the attack.
Because some threats stay hidden before they run, older restore points can be infected too. A scan helps you find the most recent clean restore point instead of guessing.
How Does Malware Scanning in Backup Software Work?
A backup scan reads the stored backup data in an isolated environment and checks it with an antivirus engine. It then reports which files or restore points are infected. Most products follow four steps:
Pick the data to scan. The scan targets a backup job, a backup set, or a single restore point.
Open the data in isolation. The backup is mounted or read in a separate area, so malware inside it cannot reach production systems.
Run the scan engine. An antivirus engine compares the files with its detection rules and flags matches.
Report and mark the result. The report lists infected files and marks the restore point, so the administrator can decide what to do next.
Scan scope matters here too. A full-disk scan is thorough but slow, while a targeted scan of key folders is faster but can miss infected files elsewhere.
When Does the Scan Run?
After the backup finishes. This finds infection early and records which restore points are clean.
Before a restore. This stops an infected restore point from reaching production.
On demand or on a schedule. This re-checks older restore points after the virus database is updated, because new definitions can catch threats that older ones missed.
How Does the Engine Detect Malware?
Antivirus engines use one or more of three detection methods:
| Method | How it works | Strength | Limit |
|---|
| Signature-based | Matches files against a database of known malware fingerprints | Fast and accurate for known threats | Misses new or modified malware |
| Heuristic | Looks for suspicious code patterns and traits, even without an exact match | Can catch variants of known threats | Can produce false positives |
| Behavior-based | Watches what a file does when it runs in a sandbox | Can expose unknown threats | Slow, so it is rarely used on full backups |
Because signature-based detection depends on its database, the virus database must be updated regularly. ClamAV, an open-source antivirus toolkit, is one example: it identifies malware with signature databases and keeps them current through automated updates.
Where Can Malware Scanning Happen?
Where the scan runs decides how safe it is and how much it costs. Backup tools use one of four approaches:
| Approach | How it works | Impact on production | Main risk |
|---|
| Scan on the source system | Antivirus runs on the live server | Uses production CPU and disk | Does not check what is already stored in backups |
| Mount the backup and scan externally | The backup is mounted on another host and scanned by that host's antivirus | Low | The scanning host must be hardened, because it opens infected data |
| Scan in an isolated scan environment | The backup is attached to a separate scan VM or sandbox, and the engine runs inside it | None | Needs extra compute for the scan environment |
| Restore the full system, then scan | The whole system is restored first and scanned afterward | High, and the slowest option | Infected data is already restored before it is checked |
Scanning in an isolated environment checks the real backup content and keeps infected data away from production. The trade-off is the extra compute needed to run the scan.
What Happens When Malware Is Found in a Backup?
When a scan finds malware, the backup tool should stop you from restoring that data unchecked. Administrators usually choose one of three responses:
Stop the restore. This is the safest choice, because nothing infected reaches production. You then restore from an earlier clean restore point instead.
Clean first, then restore. The malicious files are removed from the backup data before the restore. This keeps the latest data, but it depends on the engine finding every infected file.
Restore to an isolated environment. The data is restored to a test environment with no network access, so you can inspect it and see what is affected before anything moves to production.
Whichever you choose, record which restore points are infected, work out when the infection started, and fix the source system first. Otherwise, the next backup copies the malware again.
Limitations and Common Challenges
Malware scanning lowers risk, but it does not guarantee a clean restore. Plan for these limits:
Unknown threats. Signature-based detection misses malware that is new or modified.
False positives and false negatives. A clean file can be flagged and an infected file can pass, so results need human review.
Encrypted content. Password-protected archives and files encrypted by a user or by malware cannot be inspected inside.
Time and resources. Scanning a large backup takes compute and time, so scans can lag behind backup jobs.
Outdated virus databases. An engine with old definitions misses recent threats.
For these reasons, scanning works best as one layer next to immutable storage, offline copies, and regular restore tests. NIST's guide to protecting data integrity against ransomware treats backups as one of several layers.
Best Practices for Scanning Backups
These habits make backup scanning dependable:
Scan after every backup and before important restores. The first scan finds infection early. The second is your last check before data reaches production.
Scan in an isolated environment. Do not open possibly infected backup data on a production server or a general-purpose host.
Keep the virus database current. Turn on automatic updates, or load offline updates when the backup server has no internet access.
Keep several clean restore points. Longer retention gives you more clean copies to fall back on if an infection went unnoticed for weeks.
Follow the 3-2-1 rule. Keep three copies on two types of media, with one copy offsite. This guide to the 3-2-1 backup rule explains each part.
Protect the backup storage. Restrict write access and consider immutable storage. See immutable backup storage and cloud backup ransomware protection for options.
Alert and test. Send an alert when a scan fails or finds malware, and rehearse a full restore regularly. CISA also advises testing backup integrity and availability on a regular basis.
How Vinchin Supports Malware Scanning
Vinchin Backup & Recovery scans backup data for malware inside a dedicated, built-in scan virtual machine, not on production systems. The antivirus engine is integrated into that scan VM through an SDK. When a scan starts, the backup data is mounted to the scan VM and checked from inside it. Several scan jobs can run in parallel, each in its own scan VM.
Its main malware scanning features are:
Engines. ClamAV and Kaspersky, with online or offline virus database updates.
Coverage. Scheduled VM backup, whole-machine backup, and CDP real-time backup.
Automatic or manual scans. Turn on malware detection when you create a backup job, and Vinchin creates a linked verification job once the backup data is generated. You can also scan existing backup sets by hand.
Scan policy. Set the number of scan threads, scan the full disk or specific targets, and choose whether to stop at the first malware found or scan all unscanned restore points.
Reports and alerts. Each scan produces a visual report, and email alerts notify administrators.
If malware is found, Vinchin records where the infected files are and lets the administrator choose how to handle the restore:
| Option | What happens |
|---|
| Terminate the restore | The restore stops, so production is not exposed |
| Clean, then restore | Malware is cleaned from the backup data first, then the restore runs |
| Restore to a no-network environment | Data restored to an isolated virtualization environment with no network (virtualization only) |
Want to see malware scanning in action? Download Vinchin Backup & Recovery and test it with a 60-day free trial on your own backups.
FAQ
Q1: How often should backups be scanned for malware?
A1: Scan after every backup for critical systems, and scan older restore points again after each virus database update. New definitions can catch threats that older ones missed.
Q2: Should you scan a backup before or after you restore it?
A2: Scan before. A pre-restore scan keeps infected data out of production, while a scan after the restore only tells you the damage is already done.
Q3: How is scanning a backup different from scanning the source server?
A3: Source scanning protects the running system, while backup scanning checks the stored copies. A backup can still hold malware that the source scan missed or that arrived before the engine had the right definitions.
Q4: Can malware in a stored backup activate on its own?
A4: Normally no, because backup data is inactive until it is restored or opened. That is why scans should read the data in an isolated environment instead of on a production host.
Q5: Does immutable storage make malware scanning unnecessary?
A5: No. Immutability stops a backup from being changed or deleted, but if infected data is written first, it stays infected and locked until the retention period ends.
Conclusion
Malware scanning in backup software checks stored backup data in an isolated environment and flags infected restore points before you restore them. It is not a complete defense, because it can miss new threats and cannot inspect encrypted content, so use it together with immutable storage, the 3-2-1 rule, and regular restore tests.
A backup tool with built-in scanning, such as Vinchin Backup & Recovery, can make that check part of every backup job.
