Quick query - I’ve got a samba/cifs share set up and its taking hourly snapshots - and this is working fine. I did a rollback a couple of hours, as a test - and this also worked fine (I had to delete the samba share as instructed).
What I did notice however was that once I’d rolled back a couple of hours - (there were 20 on file), the snapshots disappeared from the list on the web page - so it said no snapshots available. Going to the command line and doing a btrfs subsystem list, the snapshots were visible - however, these also were removed when the next hourly snapshots were taken. New snapshots made after appear in the snapshot list.
Small addition to this - I spotted that the docs say you can access old versions of this by enabling shadow copies, and when you right click-properties, you should be able to see previous versions of the file…?
I’ve got shadow-copy enabled and snapshots present (taken every 5 mins), but there’s no entries under ‘previous versions’?
Windows 10 client, accessing the share via ip address e.g. \192.168.1.55\myshare\myfile.txt
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:
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:
Many thanks for all the info - certainly a lot to chew through (I’ll probably need to read through two or three times I think to take it all in )
With regard to the snapshots disappearing issue - what you say makes total sense now I understand how you’re doing it - I was thinking (as an example scenario) ‘I can rollback to 2 hours old, then if that’s not good I can roll back another couple of hours’ - as you say, the snapshot is promoted to replace the actual share, and so as the promoted snapshot doesn’t have snapshots, then it effectively loses the old versions.
As a thought would it be possible to either
when a snapshot is created, to (re)create the snapshots on the snapshot, so that if it is promoted, then the ‘old’ snapshots would still be available (or alternatively only do that just before a particular snapshot is promoted), or
offer the option that an alternate share could be created which is based on a snapshot - so that you’re able to access the snapshot itself, to check/decide before the promotion / restore
More items to add to (I’m sure a large) pile…
I’ll do a bit more investigating on the Windows 10
I realised that in the samba share setup, the ‘prefix’ that is mentioned, needs to be the same ‘prefix’ that is mentioned in the create snapshot configuration… just wondering if there’s a reason why it couldn’t automatically pick up the snapshot prefix for samba from the snapshot definitions?
As such, I can now see that previous versions exist - unfortunately, windows is saying that I don’t have permissions to view the file… that’s next (I’m currently connecting with ‘ROCKSTOR\carl’ with ‘carl’ as the admin user)
)