Understanding the limitations of Snapshot RAID

Snapshot RAID is a great and flexible feature of FlexRAID but has inherent limitations that users should be aware of.

Snapshot RAID captures the changes to your data at scheduled times and synchronizes those changes to the parity data.
In between updates, there are vulnerabilities that should be properly understood.
Operations that change your data are: renames, moves, deletes, edits, and adding new files.
The only operations that you should concern yourself with are those that might compromise the recovery process if a drive was to ever fail while the RAID is synchronized. FlexRAID knows how to deal with some of these operations and recover 100% despite them.

  • Renames will NEVER compromise recovery
  • Moves including moves to different drives that are part of the RAID will NEVER compromise recovery
  • Deletes will compromise recovery UNLESS the operations are done through the storage pool and FlexRAID’s proprietary recycle bin feature is turned on
  • Edits WILL compromise recovery
  • Writing new files to your RAID will never compromise recovery, but you risk losing these new files (and only those new files) if the drive they are on fails before you have a chance to synchronize the RAID

Further more, Snapshot RAID is not affected by things like disk de-fragmentation and you can copy back into the RAID data that was previously deleted or edited in order to help restore another drive. You can even copy one drive to another drive (when upgrading to a larger drive) without having to re-create the parity data.

So to recap, if your RAID is un-synchronized, you risk losing some of your newly added files.

If using the FlexRAID storage pooling feature with the recycle bin feature turned on, your ONLY other risk are edits (changing the file’s content) as renames, moves, and deletes won’t be an issue.

FlexRAID also features a Real-Time RAID implementation to be used for cases where your data is frequently being edited.

More notes on the limitation of Snapshot RAID

1.Edits WILL compromise recovery
– If the edited data is only on the failed drive, then data will be restored on the failed drive as it was at the time of the last snapshot
– If the edited data is on other drives, recovery will be compromised and the restored drive will sustain random corruptions up to the size of the data edited on the other drives

2. Deletes will have the same effect as edits UNLESS FlexRAID’s proprietary recycle bin feature is turned on

3. Writing new files is safe (and so are recording, streaming data, and downloading to the RAID)

4. Use of Snapshot RAID
– Data that is edited infrequently (move, rename, add, and delete [if recycle bin mode is on] are not edits and are safe operations)
– Data that is edited frequently such as data database files and metadata files should be excluded from the Snapshot RAID using the exclusion property
– When using the Storage Pooling feature, you should create a folder in the pool where frequently edited data would go and exclude that folder from the Snapshot RAID
– When using movie and music cataloging tools, make sure to exclude the metadata they create in your media directory
– Editing MP3 tags will edit the MP3 file and is considered an edit that needs to be immediately synchronized
– You should always sync the RAID immediately after massive data edits

So yes, Snapshot RAID is only for archival type data (movies, music, downloads, documents not being edited, etc.), which for the typical user will be 95% or more of his/her data.

Be Sociable, Share!

7 Responses to “Understanding the limitations of Snapshot RAID”

  1. Randall October 21, 2011 at 9:48 AM #

    Wait, if I move a file off a drive thats raided wouldn’t that be the same as a delet when I go to recover?

    • xliv October 24, 2011 at 1:56 AM #

      Of course, moving it off the drive and deleting is the same. When we say move here, it means move within the drive.
      It’s better to use the forum for questions, they’ll be answered way quicker!

  2. fuugus October 31, 2011 at 12:03 PM #

    what exactly is the meaning of “edits WILL compromise recovery”?.. will the files be:
    a) corrupt / non readable
    b) in the old state (before editing)
    c) in the new state (after editing)
    d) lost
    or will the whole recovery process fail!.. leaving the whole data on an unoperational part (the broken disk) completely lost?

    • xliv November 7, 2011 at 9:38 AM #

      Some files (nb depending on the amount of data edits you’ve done) will be corrupted. Rest of the data will be restored just fine.

  3. Blair January 22, 2012 at 8:08 AM #

    How often does sync occur? For instance, would implementing CDP using a service like CrashPlan to continuously replicate changed data to a backup drive (or the cloud) mitigate the risk of losing data between syncs?

  4. JazJon July 28, 2012 at 8:04 AM #

    What if we want to only use FlexRaid SnapShot, and not pooling too. I’m going to use Drive Bender for the pooling. (duplication disabled) and then use SnapShot raid for protection. Should I schedule the Update for more often then once a day? The drives will have Videos/Pictures/Music only on them.

    P.S. I was trying to better understand how parity raid works and found this great article

  5. download4004 September 11, 2015 at 10:44 AM #

    I have a few questions about the Universal Recycle Bin, as I understand that the prupose is to avoid an issue if a HDD crashed between 2 updates and files have been removed :

    – if a file is deleted and then a new file is added with the exact same name but different size, before updating parity,, is there any issue or confusion in case of recovery ?

    – in case of file edit, is it safer to delete the old version then add the new version to preserve the recovery ability ?


Leave a Reply