disParity

disParity » General Discussion

1. Phatty2x4
   Member

   So far - this is a great start to great piece of software.

   I like the fact that I can control when the recovery set can be created and updated.

   Two requests:
   1)I know you've come a long way on the verify. Is it possible to have the verify what it has discovered as corrupted? This would go a long way as to determine what needs to be restored.

   2) A detailed recovery method where single files could be recovered. This could be via GUI or command line. I am testing with large sets of data (750GB to 1 TB). I happen to have an additional 1 TB for the moment so I can test. I will soon need this drive for space, so recovering a 1 TB drive won't be possible in the near future.

   Verify of the corrupted file and method of single file recovery would be a massive help in promoting this product.

   Posted 6 years ago #

2. Roland
   Roland

   When verify encounters an error, it immediately checks the MD5 hashes of the all the files involved in the erroneous parity block against the saved hash values. It prints out all the files involved and whether the hash values match or not. In theory, if a file has become corrupted, this process should identify the corrupted file.

   The only thing disParity can't check is whether the parity data itself is corrupt. To do this I'll have to change the format of the parity files to include block checksums. This will force everyone to regenerate their snapshots after upgrading, so I've been putting it off.

   Once I get a basic GUI up and running for disParity I will definitely have it support selective recover, that's high on my list for a GUI feature.

   For now, if you don't have a drive large enough to do a test recovery, note that you can use the "test" command which simulates the exact same process as a recover, only it doesn't actually write the files out to disk.

   Posted 6 years ago #

3. cartman
   Member

   Maybe if the program could export to a text file a list of all files and directories of a disk, and then the user would edit that file and leave whatever he needs to recover, feeding back that list to disparity?

   Posted 6 years ago #

4. Phatty2x4
   Member

   Looking back at my request for verify, I see that I needed to add a little more.

   When doing the verify, it would also be nice to see if there are any files missing in addition to being corrupted.

   Example:
   Say I have a folder with a few hundred files. A few files get deleted. When running verify (using ver 11), disparity detects the deletes, then alerts me "Changes detected on <drive letter> that will cause verify to fail. Run update first" - This is good. I now know that there are missing/damaged files.

   It would be helpful if the verify command would alert as to what files where now missing. I would hate to run an update and potentially loose those files.

   Running the test option, while helpful, can be time consuming. For me, test would crash on the first missing file. If I could see the files, I would decide whether I needed to have them recovered - which then leads into the single file recovery method.

   Posted 6 years ago #

5. Roland
   Roland

   These are great suggestions guys, keep 'em coming if you have 'em. I like the idea of printing out what files have changed, I can add that output as part of "verbose" logging mode.

   Posted 6 years ago #

RSS feed for this topic

Reply

You must log in to post.