> Just to confirm doing a full hash check the log file will contain all files processed in the order they were checked
Yes the log file will show all the files as they are being hash checked. When you do a "Hashcheck All" it runs on all drives simultaneously, so you'll see a jumble of files from all drives go by, but you can't infer anything from the order. In fact looking at the log file is not going to tell you anything useful at all. The "Hashcheck All" command will tell you at the end about all bad files it found.
> Why is there no undelete on all drives option, such that it prompts for a drive to move the old files to before it performs the undelete !?
You could ask the same question about 100 other features that disParity should have but doesn't. It only does what I've had time to implement so far. The purpose of the "Undelete" command is to recover an accidentally deleted file. It may turn out to help in your case as well, but fixing widespread corruption is not what it was designed for, so it will take extra effort.
> Is it correct to see a green tick on one disk and to have 4 hash failures ?
The green checkmark means disParity thinks the backup is up to date for that drive as of the last scan (i.e. it did not find any, deleted, or modified files.) But there are cases where a hashcheck will fail even though a scan didn't find any changes, such as when a drive is starting to go bad, or perhaps in the case of your ransomware. During a scan disParity will only check to see if a file has changed if either its length or last modified time has changed. If both of those attributes are the same as last time, it's not going to re-hash the file on every scan; if it did, every "Scan" would take hours to complete. That's what the hashcheck feature is for: when you suspect something is going wrong that a normal scan isn't picking up.
> The issue I have is that I do not know which of the other disks needs to have undeletes to allow the hash checks to pass on the disk with the green tick.
I think you might be misunderstanding either what hashcheck does or how undelete works. A hashcheck simply recomputes the checksum for a file and compares it against the checksum from the last time the file was processed. No other disks or files are involved. It just examines a single file to see if its contents have changed (that's what a "hash" code is for; if even a single byte changes somewhere in the file, the file's hash value will change.) The main purpose of the hashcheck feature is to check for drive corruption. It doesn't really have anything to do with the backup or the parity.
Furthermore, if 2 corrupted or encrypted files from different drives overlap in the parity, you can't undelete one first in order to then undelete the other. Neither file will be recoverable. They are both lost and there is nothing disParity can do to help in this case.
Here is my advice, assuming I understand correctly what is happening (some malware has encrypted some of your files, either only on a single drive, or on multiple drives, right?) The first thing you should do is run the "Hashcheck All" command. It will take a while, but at the end it will give you a report of all files on all drives that failed. Now you have a master list of all files that got encrypted.
Now, let's say it finds 100 bad files. Pick one file, and either delete it, or move it to a temporary location. Run a "Scan" for that drive. The "Undelete..." option should now be available for that drive. Try "Undelete..." and see if it works.
If it works, then the file doesn't overlap with any other encrypted files. You can now repeat this process for the other files. To make it fast, you can try ordering the 100 bad files by drive, and deleting/moving all the files on a single drive at once, and then recovering them all with a single "Undelete..." command.