On workstations, running a full hard drive scan is a routine process — it usually happens in the background and requires no user input. Things get trickier with servers, especially after a security incident. In such cases, the entire storage system (sometimes many terabytes) may need to be scanned urgently, and this has to be done without compromising data integrity or causing major performance issues for users.
To help with that, we’ve put together some practical recommendations. While the examples here refer to ImgConverter Endpoint Security, the same principles apply to other EPP/EDR solutions.
Preliminary checks
Verify the system setup of the machine that will handle the scan. It should run the latest OS version and be able to properly access all the target disks — including support for long Unicode file names, very large files, or partitions with case sensitivity. To speed up the process, use hardware with a strong multicore CPU, plenty of RAM, and fast local storage for temporary files.
Also make sure disk access is fast. Ideally, the scanning system should connect directly to the storage or via a high-performance interface (preferably SAN-class protocols).
Review your backups. Scanning shouldn’t alter the data, but a fallback plan is always essential in case something goes wrong. Check the latest backup dates and their integrity, ensure recovery procedures have been tested, and confirm that current backup sets are actually usable. If not, weigh the risks and consider creating a fresh backup of the most critical data before you begin.
Understand the storage setup and data type. This helps you fine-tune scan settings. For instance, is the system using RAID, and what kind? Will running tasks in parallel improve performance? If independent drives are available, you may want to distribute scanning across multiple computers. The type of data also matters: scanning lots of small or compressed files is resource-heavy, while large files in safe formats (like video, database tables, or untouched backups) put less strain on the system.
Preparing for scanning
Pick the right time. Schedule scans during low-traffic periods — nights, weekends, or maintenance windows. If possible, isolate the storage from users during the process, or at least inform them of possible slowdowns.
Ensure sufficient free space. Some files may need to be unpacked (archives, disk images), which can temporarily require a lot of space.
Adjust quarantine settings. If many suspicious files are detected, the quarantine might fill up. Reserve enough space to prevent automatic deletion of older samples.
Define exclusion rules. To save time, you can exclude data unlikely to be risky — such as very large files, install packages, or unchanged backups. But keep in mind that malicious fragments can sometimes hide in unexpected places, so be careful with exclusions.
Clean up temporary data before scanning to avoid wasting resources on irrelevant files.
Scan settings
Adjust the configuration based on your environment, but general best practices include:
- Allocate enough CPU and memory. If the server is offline, you can use up to 80% of resources. If it remains in use, lower the limits to avoid disruption.
- Enable iChecker and iSwift to skip unchanged files and accelerate scanning.
- Turn on safeguards to prevent overload, such as blocking simultaneous scan tasks and scanning only new/modified files.
- Disable scanning of password-protected archives to avoid interruptions.
- Set a file-size limit for scanning, based on your earlier assessment.
- Keep heuristic analysis at a medium level for balance between performance and detection.
- Default to quarantine for infected files.
- Enable detailed logging so you can review exactly what was scanned and the results.
More details can be found in our support documentation for Windows and Linux.
Running the scan
Start small: scan a subset of data (under a terabyte) to measure performance impact and total run time. Check logs for errors or bottlenecks and adjust the configuration before scaling up.
We recommend splitting large storage volumes into separate tasks (e.g., by disk). This reduces the chance of a scan taking too long or failing entirely, forcing a restart. If possible, run tasks in parallel on independent storage systems.
Keep an eye on system load and scan progress. Intervene if anomalies occur, and review logs after every task to ensure nothing was missed.