AV software finds trojan in temp backup file


Just starting to experiment with Urbackup, which I’m running on a server with three clients on the same home network.

Backing up one client last night, the AV software on the server picks off one of the files in \Backup\urbackup_tmp_files and puts it into quarantine. The risk reported was Trojan.Gen.

I strongly suspect it’s a false positive, the client PC is scanned regularly and is clean. But better safe than sorry. How do I find the original file which caused the error? The filename that caused the alert is just a seven digit number. Is there someway to use this filename to trace the original file the software tried to backup?

Apologies if I’m missing something obvious, but I’m new to this. The backup was over 1TB of data so it’s hard to know where to start!



Do a search for the filename on the client machine.

Thanks for your reply. My problem is the temporary backup file (that has caused the alert) seems to exist only on the server. There is no file of the same name on the client.

If I understand correctly the process seems to be: Client sends file to be backed up to server > File is saved in temporary folder with a new filename (in this case 1861240) > Temporary file is processed and placed into the backup

What I need to work out is the relationship between the name of the temporary file (1861240) and the original file name, so I can carefully check the client PC.

Thanks again.

Could always browse the logs for anything that looks suspicious; run Malware Bytes or a few other Anti-Virus/Anti-Malware programs on the problem computer and see if any of those give you a false positive.

I highly do NOT recommend putting on every Anti-Virus program under the sun to check if it is a false-positive or not, but you could see if there is something that could read the contents of that temp file – whether the UrBackup team knows or if there is a program floating around that can analyze that file, I don’t know.

Theoretically this should cause the file backup to fail with an error message if the virus scanner blocked the file access.

If it did not you should be able find the file by running a on-demand scan on the file backup directory…

By the way, I would disable the on-access scanning (at least for the backup storage folder) and if necessary schedule on-demand e.g. nightly scans.

Thanks for the replies. Although the server seems to have finished copying files from the client, the backup has not yet reported complete. Urbackup is still processing many of the backed-up files. I presume is completed I can either see whether it reports completed or not and go from there.

Why would it be better to disable the on-access scan of the backup storage folder? To speed-up the backup process?




The backup failed. These messages were in the log:

Error opening file “\?\E:\ServerFolders\Backup\urbackup_tmp_files\111111” from pipe for reading file. File: temp_fn ec=2
Waiting for file transfers…
Waiting for file hashing and copying threads…
Saving file metadata…
Metadata file and “E:\ServerFolders\Backup\CLIENT\161024-1000\C\test\doc.dll” do not exist. Skipping applying metdata for this file.
Not all folder metadata could be applied. Metadata was inconsistent.
Writing new file list…
All metadata was present
FATAL: Backup failed because of disk problems (see previous messages)

The temp file 111111 matches the name of the file the antivirus reported as a Trojan.

Does the line I’ve highlighted in bold identify the original file ( i.e. the one Urbackup turned to the temporary file flagged as a Trojan, in this example doc.dll) ?