Restore files via Powershell ToolKit

[connoisseur]

Long story short

We have a lot of Cryptoware incidents on our fileserver SVM:s.

Is there a way to find and restore *.encrypted files via NPTK?

What I´m looking for is a way to do file level restores on thousands of files in a folder/subfolder without restoring unaffected files located in the same.
Maybe one can use NPTK to do some kind of SnapRestore, targeting only *.encrypted files?

Do you have any idea?

I´m new to PS, but I got it installed and working.
I can connect to both cluster and SVM.

[JGPSHNTAP]

^^

if this is CIFS, using powershell for CIFS .. what about snap restore... restore whole volume.

[connoisseur]

That´s the problem.

Sometimes not all files are affected in a cryptoware attack.

And usually the customers don´t allow us to restore on folder level.

Say they have 10 qtrees in that volume.

And in that qtree they have X number of folders.

If 1 folder has ten thousands of files and get affected, but only 80% of the files are decrypted.
the customer only want the affected files restored.. not the whole folder.

That´s my dilemma..

Otherwhise I just would have done a restore from OCUM

[asulliva]

Hello!

Copying my response from elsewhere...

Using regular PowerShell cmdlets to search a CIFS/SMB share for particular files will be the most efficient way. Once you have the list of files you could FlexClone them from a snapshot back into the current file system. I created an example of how to do this on this NetApp Community thread.

Andrew

[connoisseur]

Thanks Andrew!  (just saw that you are the guy from practical-admin.com  .. cool)

Anyhow..
As I said, I´m very new to PS.

A regular "Get-Childitem" command should do the trick to find the files..

So far I´m good.

But when it comes to the NPTK, I find it a bit difficult.
First, If I get a list from the GCI command where the output finds the correct path to the files, it´s still only the SMB path.

So I need to find the correct volume/qtree path etc in the controller to get to the next step.

Next I need to find the version where the file isn´t infected.. maybe that needs to be done manually.. or could one use the create timestamp from the *.decrypted file in some way.
Then I thought about if, in someway, one can use the command below in a PS script:

snap restore -t file /vol/svmvolume/qtree/folder/file -s nightly.0

Today we use the following way.
We find the point in time where the files are OK, clone that snapshot and then mount it and share out the volume to a "restore" share.

Then mount the infected area to U: (for exampel) and the restore to Y:.

Then we use robocopy to receive the filename and use PS to copy the to destination.

#robocopy 'U:\Folder' null /l /e /fp | select-string 'decrypted' | out-file c:\temp\decrypted.txt

$x=get-content c:\temp\decrypted.txt
 
$i=$null
$J=$null
foreach ($i in $x){
 $i=$i.trim('.decrypted')
  $i
  $j=$i -replace "u:" , 'y:'
  $j
  copy-item "$j" -destination "$i"
}

I just thought if that can be done through Snap Rrestore in NPTK, It might go a little faster?

We have also worked with

To list the encrypted files below script is used:

#robocopy 'U:\folder' null /l /e /fp | select-string 'decrypted' | out-file c:\temp\decrypted.txt

To restore the files from backup:

robocopy "\\NAS\restore_share$" "\\NAS\original_path" /COPYALL /DCOPY:T /B /SEC /E /R:0 /W:0 /log:"c:\temp\output.txt" /nfl /ndl /TEE

[asulliva]

There's a number of ways to map a UNC path to the volume on the NetApp, but arguably the easiest is to simply do it by hand...create a simple hash which contains the values:

$uncMap = @{
    'share1' = 'vol1';
    'share2' = 'vol2';
}

From there it's just a lookup by name.  Over time, depending on the number of volumes/shares and how many get added or removed, this could get tedious to maintain, at which time it may be more prudent to use the cmdlets to build the list in realtime..."Get-NcCifsShare" should be useful here.

To find the usable version of the file there's two ways I can think of off the top of my head...1) as you mentioned, based on the create time of the corrupted file, or 2) check each snapshot, in youngest to oldest order, until you find a valid file.

Using FlexClone to get the data from the snapshot will be faster than restoring it to another volume and then copying it back.  It doesn't have to have the same name as the original when the FlexClone happens...for example you could name it "file.encrypted.restored".

You mentioned "snap restore -t file" from the command line...the equivalent to this with the PowerShell Toolkit is the "Restore-NcSnapshotFile" cmdlet.  The downside here is that you can't rename the file on the restore operation, the upside is that you don't need a FlexClone license, but the speed should be equivalent between a Snap Restore and a FlexClone.

Andrew