New restore option request

[MartijnV]

Background info:
2 of our customers got infected with a cryptolocker last week, infecting alot of files on their global network share.
After isolating the virus we deleted all the encrypted files, then tried to restore the missing files using a File Level Restore. This is where we ran into a problem.
Choosing overwrite could possibly overwrite newer files so we went with keep. This option however restored everything into a new folder (Sharename-restored) and we ran out of free disk space.
So we ended up restoring subfolder by subfolder which ofcourse consumed alot of our time.

Is it possible to add a new file level restore option to restore only newer files, not overwriting existing files?
It could save alot of time in situations like this.

[marco.horstmann]

Hi Martijn,

an option would be restore files with robocopy. if you start FLR explorer the disks
of the VM will mounted in C:\VeeamFLR folder.

Here an example I had in my mind. Never tested this. But maybe it's a workaround for your situation.

Code: Select all

robocopy C:\VeeamFLR\Disk\pathX\ \\fileserver\share\pathX /e /b /copyall /minage:<N> /r:3 /w:1 

/e copy all files
/b backup mode
/copyall copy all attributes
/minage:<N> Specifies the minimum file age (exclude files newer than N days or date). N specifies the number of days. Otherwise, N specifies a date in the format YYYYMMDD.
/r:3 number of retrys
/w:1 time wait between retrys

[benyoung]

Is there any risk here of infecting the backup environment at all given the disks are mounted if the machine you are restoring from has a virus such as in the example in this post where Crypto was found?

[ekisner]

A virus needs to be executed by something. "Code" is no different from "data" until you try and execute it. Copying file contents should be safe. In all cases, an antivirus will never be a bad thing (whether it's a good thing or not depends on whether it prevents infections!).

On an aside, this is one thing I've always loved about *nix.. chmod +x... I truly wish Windows would implement it. Without execute permission, you simply cannot execute a file. You could literally download virus.exe from the internet, and until you give it execute permission it'll just be treated as raw data. I also wish they'd implement root jails. Hell there's a lot of things I wish they'd implement...

[veremin]

Is there any risk here of infecting the backup environment at all given the disks are mounted if the machine you are restoring from has a virus such as in the example in this post where Crypto was found?

Nope, as you cannot modify a content of backup anyhow, even when Windows FLR is running. Thanks.

[ekisner]

The actual VBKs could indeed be encrypted by cryptolocker. Probably not the ones open and part of the restore, but anything that's not locked could absolutely be overwritten. The contents inside of the FLR would be safe, as you say, but benyoung was referring to the environment (the B&R server, the VBKs/VIBs, etc). At least that's my take on it.

To test this, I backed up a VIB, then inserted characters into the original VIB using notepad, the save took. I of course then replaced the edited VIB with the backup copy.

[veremin]

The actual VBKs could indeed be encrypted by cryptolocker. Probably not the ones open and part of the restore, but anything that's not locked could absolutely be overwritten. The contents inside of the FLR would be safe, as you say, but benyoung was referring to the environment (the B&R server, the VBKs/VIBs, etc). At least that's my take on it.

That is absolutely true, but since this thread was talking about Win FLR restores, I assumed benyoung was concerned with content of backup files.

As to protecting backup files themselves against cryptolocker or similar, check out recommendations provided in this thread.

Thanks.

[benyoung]

Sorry guys didnt see the replies here - i was indeed talking about the backup environment, specifically a multi tenant environment where there are lots of differing security practices, av engines etc among the clients so we default to never restoring the file locally but wanting to utilise the rest api to allow https downloads of selected files through our own customer portal. Looking at how this process works it seems that it fires up an FLR and uses the temp directories to extract and stream the files from disk

If this is the case this is where i am concerned around possible infection to our backup infrastructure as opposed to infecting/modifying the contents of the backup files themselves