I can chip in on this one, though only from memory unfortunately due to time constraints with other pending Rockstor concerns. This is by design / ‘is an artefact of’ it’s underlying mechanism, ie btrfs snapshots. Each subvol, be it a share or snapshot, is it’s own file system (sort of) but there still exists a hierarchy between them: ie a snapshot of a share has the share as a parent but they are still independent. This hierarchy defines which share (btrfs subvol) a snapshot was parented / taken from. But the snapshot is still a subvol in it’s own right. And Rockstor’s rollback facility is not so much a simple move back in time as it is a shift sideways to one of these snapshots. The share is essentially supplanted by one of it’s prior snapshots. And the nub here is that these snapshots, being independent of the parent share, do not have any snapshots themselves: hence your observations. I.e. each snapshot is an offshoot of it’s parent at that time, not the parent and all it’s prior, at that time, snapshots; as those snapshots do not belong to each other but to the parent alone. Thus when you select a snapshot to rollback to you loose all other snapshots. They are not sequential backups including each and every prior backup in turn they are independent and thus can stand alone.
I think what we need here is better visibility / clarity on exactly what this rollback is. We should maybe make clear that a revert looses all prior snapshots. It may be something we can engineer our way around but the current mechanisms to deal with this are already fairly complex so I’m reluctant to make them any more complex. The btrfs system itself is verging on magic as it is and we get an enormous amount of capability that Rockstor itself is only able to ‘humanly’ surface a fraction of and so we have ended up with this mechanism as it stands.
I would strongly advise that you upgrade to at least the last released testing version, which when it was last updated was essentially 3.9.2-0 by another name (ie 3.9.1-16): see the intro section of:
for the history and current state of our update channels. Short of it is you might as well be running 3.9.1-16 (alias 3.9.2-0) and if at all possible the lastest stable release which is now 45 odd releases on from the last testing channel release. The stable channel also helps with Rocktor’s sustainability which may be another concern. But as to your observation and my above comments the nuts and bolts of that mechanism are now much cleaner: but essentially work the same way.
The most recent code that accomplishes this ‘rollback’ can be seen here:
The code is mostly well commented and so should be completely accessible.
Note however that this is the far more modern and less buggy variant of what you are currently running and the last pull request to affect this mechanism directly was:
Which was quite significant.
Once you are running something a little more recent I would also suggest that you take a look at the clone mechanism; which as is visible from that code link, is the sister mechanism to the potentially misleadingly named ‘rollback’ mechanism (referenced in code comments as a ‘supplant’).
Yes this is due to them being snapshots of the newly ‘promoted’ snap-to-share subvol, as is intended.
I’m actually unsure if this ‘rough edge’ still exists in latest stable. Sorry but working on many other elements of Rockstor that need my attention and the code is very different now.
Thanks highlighting this potentially poorly named / intercommunicated functionality and your suggestions on how we might re-label / explain this ‘feature’ would be welcome. I’ve though a few times myself that this was misleading but just haven’t gotten to concentrate on it to get it clarified. We a somewhat guided by trying to stick to basic btrfs capabilities to keep our task workable and sometimes we don’t do as well as we would like in translating the various magics.
Take a look at newer versions of Rockstor and check out the clone function for context.
Not sure if this is a bug on our side or if Windows 10 has move the goal posts again or what. I’d first check if your scheduled snapshots configuration has the “Make snapshots visible” option ticked which is tool tipped as “Make snapshots visible to the end user.”
I know we have an access denied’ issue with snapshots, ie see the following thread: