I'm not sure that I completely understand the --import option. Does this option serve a similar function as the pool recycle bin in FlexRAID?
For those not familiar with that option in FlexRAID, it's a replacement for the Windows recycle bin. Files deleted from the pool are instead moved to a hidden directory, and are only deleted after the next successful parity update. In the event of a failure before that update occurs, these files can be used to increase the probability of a full recovery that may not have been possible if they were immediately deleted and parity wasn't updated.
So would this work as a parallel in SnapRAID, where a nightly sync script deletes the "recycle bin" contents after every successful sync? How does -i fit into the check and fix commands?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The normal trashcan in Windows (as I understand you are using) works well together with snapraid.
If you put something by mistake in the thrashcan then you can just go into the trashcan and select to restore the files again. Snapraid will recognize them and all is good.
This works also in scenario where a disk breaks down and needs some of those files to restore(fix) the broken disk.
After sync Snapraid cannot help you restore the files, but you can still restore them from the trashcan.
I can only think of one scenario where --import option might be usefull.
If you have moved files to another disk and a different disk breaks down before you have synced.
In that scenario the missing files might be needed to restore the broken disk and then you can tell snapraid where to look for the missing files.
Not 100% sure though as I have so far never experienced such a scenario and have never found any need to test it :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, that isn't really what I'm trying to ask. The recycle bin built into Windows isn't a part of this scenario at all, since it will be completely disabled, no files will go to the Windows Recycle Bin. Besides, files deleted over a network share bypass the Windows Recycle Bin anyway, so it's worthless on a file server.
Let's say I'm using FlexRAID. It has its own feature that in some ways mimics the Windows recycle bin (which again, is disabled). Any time a file is deleted from the virtual pool, that file is moved to a hidden+system folder under the root of the source drive called flxr instead of actually deleting it. These files are left alone until I run an update task. While update is running, it ignores the contents of the flxr folder so it recognizes that these files are missing. It updates the parity information to remove these files from the parity data. Once an update is successful, the flxr folder contents are permanently deleted. If there's a drive failure before I get a chance to run an update, and it finds that it needs the data from one of those deleted files to complete a restore, it will still be available in the flxr folder.
Now if this flxr functionality did not exist, any time a file is deleted it essentially "corrupts" your parity data because now files that it relies on for restoration from parity calculations are now gone. Your chances of a fully successful recovery are greatly diminished.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you delete or modify any file then all files which share parity blocks with the deleted file have 1 less parity available. If you only have 1 parity disk that means you have no redundancy at all for any of the affected files until after next sync.
The available options are:
A. Don't delete files, instead manually move them to a trashcan or ignored folder so that you can restore them if needed and then manually delete them after sync.
C. Add an extra parity disk.
(The extra parity will stand in as replacement for the deleted files and the original parity will be used to recover broken disk if needed)
D. Sync more often
(this is not really a solution but it decrease the probability for the bad scenario)
A is the recommended practice.
If A is not realistic then go for option B, C or D.
(B is on the todo-list for Andrea to investigate for future snapraid versions)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am actually using 4 parity drives (currently 20 data), and I plan to continue using the standalone pooling feature of FlexRAID so I will still have its built in recycle bin feature. Then I can make my own script to empty the flxr folders after each successful sync, and if/when I need it, I'll be able to use -import function on those folders. This is basically a fully automated option A.
Option B looks a little more complicated than my plan.
Sidenote, I did try to search for posts about the import option, but all the results were for "important"!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure that I completely understand the --import option. Does this option serve a similar function as the pool recycle bin in FlexRAID?
For those not familiar with that option in FlexRAID, it's a replacement for the Windows recycle bin. Files deleted from the pool are instead moved to a hidden directory, and are only deleted after the next successful parity update. In the event of a failure before that update occurs, these files can be used to increase the probability of a full recovery that may not have been possible if they were immediately deleted and parity wasn't updated.
So would this work as a parallel in SnapRAID, where a nightly sync script deletes the "recycle bin" contents after every successful sync? How does -i fit into the check and fix commands?
The normal trashcan in Windows (as I understand you are using) works well together with snapraid.
If you put something by mistake in the thrashcan then you can just go into the trashcan and select to restore the files again. Snapraid will recognize them and all is good.
This works also in scenario where a disk breaks down and needs some of those files to restore(fix) the broken disk.
After sync Snapraid cannot help you restore the files, but you can still restore them from the trashcan.
I can only think of one scenario where --import option might be usefull.
If you have moved files to another disk and a different disk breaks down before you have synced.
In that scenario the missing files might be needed to restore the broken disk and then you can tell snapraid where to look for the missing files.
Not 100% sure though as I have so far never experienced such a scenario and have never found any need to test it :)
Well, that isn't really what I'm trying to ask. The recycle bin built into Windows isn't a part of this scenario at all, since it will be completely disabled, no files will go to the Windows Recycle Bin. Besides, files deleted over a network share bypass the Windows Recycle Bin anyway, so it's worthless on a file server.
Let's say I'm using FlexRAID. It has its own feature that in some ways mimics the Windows recycle bin (which again, is disabled). Any time a file is deleted from the virtual pool, that file is moved to a hidden+system folder under the root of the source drive called flxr instead of actually deleting it. These files are left alone until I run an update task. While update is running, it ignores the contents of the flxr folder so it recognizes that these files are missing. It updates the parity information to remove these files from the parity data. Once an update is successful, the flxr folder contents are permanently deleted. If there's a drive failure before I get a chance to run an update, and it finds that it needs the data from one of those deleted files to complete a restore, it will still be available in the flxr folder.
Now if this flxr functionality did not exist, any time a file is deleted it essentially "corrupts" your parity data because now files that it relies on for restoration from parity calculations are now gone. Your chances of a fully successful recovery are greatly diminished.
Yes that is correct.
If you delete or modify any file then all files which share parity blocks with the deleted file have 1 less parity available. If you only have 1 parity disk that means you have no redundancy at all for any of the affected files until after next sync.
The available options are:
A. Don't delete files, instead manually move them to a trashcan or ignored folder so that you can restore them if needed and then manually delete them after sync.
B. See Jens's Windows script at: http://sourceforge.net/p/snapraid/discussion/1677233/thread/a1707211/
C. Add an extra parity disk.
(The extra parity will stand in as replacement for the deleted files and the original parity will be used to recover broken disk if needed)
D. Sync more often
(this is not really a solution but it decrease the probability for the bad scenario)
A is the recommended practice.
If A is not realistic then go for option B, C or D.
(B is on the todo-list for Andrea to investigate for future snapraid versions)
I am actually using 4 parity drives (currently 20 data), and I plan to continue using the standalone pooling feature of FlexRAID so I will still have its built in recycle bin feature. Then I can make my own script to empty the flxr folders after each successful sync, and if/when I need it, I'll be able to use -import function on those folders. This is basically a fully automated option A.
Option B looks a little more complicated than my plan.
Sidenote, I did try to search for posts about the import option, but all the results were for "important"!
Hi Quaraxkad,
The --import option is present to handle safely the case of deletion of a lot of files. See this FAQ entry: http://snapraid.sourceforge.net/faq.html#delandbreak
Ciao,
Andrea