Pre-Issue Stuff:
Long-time user of Gravity and now Reflector. Thank you for all of the work and effort you've put into this product.
I didn't see any forum posts about this particular issue. I imagine this problem is something that doesn't happen that frequently. If there is a forum post about this issue, apologies, and please feel free to point me there.
Information:
Windows:
EditionWindows 10 Pro
Version22H2
Installed on1/24/2021
OS build19045.2486
ExperienceWindows Feature Experience Pack 120.2212.4190.0
Cobian Reflector:
v2.3.5
Source Disk:
3x 4TB Western Digital Red, RAID 5, using Windows Storage Spaces
Destination Disk:
Western Digital My Book 25EE 8TB
Job Information:
Mirror 5x source directories to a destination directory. No compression or anything else fancy. Straight copy.
Problem Statement:
1. During the execution of a backup, the source (virtual) disk serving the data that was in the process of being backed up, went offline. Why the disk went offline remains to be seen, though I have some suspicions - almost certainly not related to Cobian Reflector.
2. When the disk went offline, the existing files that were queued up failed to backup, naturally.
3. After this though, the next set of sources due to be backed up could also not be found.
4. Because the sources could not be found, and because Mirror task flag was checked, those sources were wholly deleted.
Thoughts:
This behavior seems problematic.
It's one thing for the disk to be connected and the folders no longer existing, causing the non-existent folders to mirror to the destination. The Mirror task would have done exactly what it was supposed to do.
It's another thing entirely for the whole volume to be have gone offline/be missing, and the lack of volume cause the "empty" source directories to mirror to the destination.
The failure mode when an entire volume goes offline should probably be for the task to critically fail and stop, rather than continuing on.
Fortunately, the virtual disk came back online in Windows (manually, by me)... seemingly without issue or data loss (though this is not an easy thing to confirm). I have removed the possibly-offending software (Corsair iCue) I think caused the issue, and I am running another backup to get back to a state where the things I want protected are in fact protected.
I can provide the log file upon request, if there is a way to communicate it securely. I am not keen to just upload it to a public forum, even though I've done my best to sanitize it. This can be a secure repository of your choosing, or I can share a google Drive link via Direct Message.
Questions:
1. Would the setting "Cancel if Volume Shadow Copy fails" have properly handled this issue?
2. Is there some other setting I should have enabled to mitigate this issue?
3. If this is a bug or functional oversight, is there a place to submit bug/feature requests outside of the forum?
Thank you.
Long-time user of Gravity and now Reflector. Thank you for all of the work and effort you've put into this product.
I didn't see any forum posts about this particular issue. I imagine this problem is something that doesn't happen that frequently. If there is a forum post about this issue, apologies, and please feel free to point me there.
Information:
Windows:
EditionWindows 10 Pro
Version22H2
Installed on1/24/2021
OS build19045.2486
ExperienceWindows Feature Experience Pack 120.2212.4190.0
Cobian Reflector:
v2.3.5
Source Disk:
3x 4TB Western Digital Red, RAID 5, using Windows Storage Spaces
Destination Disk:
Western Digital My Book 25EE 8TB
Job Information:
Mirror 5x source directories to a destination directory. No compression or anything else fancy. Straight copy.
Problem Statement:
1. During the execution of a backup, the source (virtual) disk serving the data that was in the process of being backed up, went offline. Why the disk went offline remains to be seen, though I have some suspicions - almost certainly not related to Cobian Reflector.
2. When the disk went offline, the existing files that were queued up failed to backup, naturally.
3. After this though, the next set of sources due to be backed up could also not be found.
4. Because the sources could not be found, and because Mirror task flag was checked, those sources were wholly deleted.
Thoughts:
This behavior seems problematic.
It's one thing for the disk to be connected and the folders no longer existing, causing the non-existent folders to mirror to the destination. The Mirror task would have done exactly what it was supposed to do.
It's another thing entirely for the whole volume to be have gone offline/be missing, and the lack of volume cause the "empty" source directories to mirror to the destination.
The failure mode when an entire volume goes offline should probably be for the task to critically fail and stop, rather than continuing on.
Fortunately, the virtual disk came back online in Windows (manually, by me)... seemingly without issue or data loss (though this is not an easy thing to confirm). I have removed the possibly-offending software (Corsair iCue) I think caused the issue, and I am running another backup to get back to a state where the things I want protected are in fact protected.
I can provide the log file upon request, if there is a way to communicate it securely. I am not keen to just upload it to a public forum, even though I've done my best to sanitize it. This can be a secure repository of your choosing, or I can share a google Drive link via Direct Message.
Questions:
1. Would the setting "Cancel if Volume Shadow Copy fails" have properly handled this issue?
2. Is there some other setting I should have enabled to mitigate this issue?
3. If this is a bug or functional oversight, is there a place to submit bug/feature requests outside of the forum?
Thank you.
Statistics: Posted by thesmall — 06 Feb 2023, 17:21 — Replies 3 — Views 17