-something- decided to remove just about everything from one of my shares (I haven’t figured out what yet). Luckily I have a snapshot from a few days before, so I thought I was saved. However, I cannot figure out how to restore the snapshot.
Detailed step by step instructions to reproduce the problem
I have removed the SAMBA and NFS shares for the share and also disabled both services. I then tried to select the snapshot and “Rollback”,
However, the “Rollback” button stays greyed out, so I cannot use it. In the documentation it mentions creating a clone, which I tried, however, the clone is the exact same size as the current share, not the size of the snapshot.
I don’t know how to recover my snapshot now.
Web-UI screenshot
Snapshot, size 1.7TB, “Rollback” button greyed out
I’m surprised there has not been a response yet. However, I think you need to include what version of Rockstor you are running, if it is native install or in VM, hardware used, etc.
How did you go about making a clone from the snapshot? If it was via the clone button in your first screen shot while viewing the snapshots tab for the Share Multimedia; then that is a clone of the Multimedia Share in it’s latest form, i.e. not what you are after. The tick indicated against the snapshot causes the RED “Delete snapshot” button to appear. It does not enable this snapshot as a Clone target. But yes this is a UI confusion for sure. We plan to re-do all of the Web-UI as we move past the next Stable release.
Just trying to clarify things reall. The problem as you say is the Rollback button inactive (greyed) when there are snapshots to rollback to!!
From a quick experiment I can confirm that, wright or wrong, readonly snapshots (default) do not offer rollback targets:
In the above toy example the Rollback button only appeared after I added the second rw snapshot, it was greyed out after only adding the ro (default) snapshot. Also we see an additional icon next to the rw snapshot with the mouse-over text of “Clone snapshot”.
After the above example the big orange Rollback button at the top of the screen presented the following page:
So Rollback is offered for read-write snapshots, but not read-only snapshots.
Apologies for having little time here on the forum currently as I’m working on some exciting changes ready for the next Stable release. Hopefully folks here on the forum can help steer a path through for you. But there at-least exists a subvolume created from the Share at a prior time. You just have to be careful not to loose that subvolume in any experimentation you may end up doing.
Hope that helps - at least with some context and possibly a way through here with some by-hand intervention possibly.
No worries about the timing, i’m glad you answered.
You might consider clarifying in the documentation that snapshots can only be cloned (and rolled back?) when they are read-write snapshots. Or even better, in the UI when you make the snapshot, because this is quite important information to have at the time of snapshot creation.
Anyways, I have been digging further the past few days and I am really confused.
I found the snapshot on disk, and it still contains all files, so I am able to manually copy them back. However, in my attempt to do so my disk filled up, which is quite odd, because it should end up taking the same amount of space, or slightly less than it was originally.
I then realized that the disk shows 60% use, even though I cannot “see” the files. So it seems that for some reason the filesystem still thinks the files are there. They should have been overwritten by the copy though, so it seems the disk space is taken in another form, or with trash or whatnot.
We can, if more developer time emerges, also address the Web-UI side - but we are heading for a front-end re-write once we have the next Stable release out so our limited developer time is likely going to be soaked up by that - which will hopefully enable far easier front-end changes than we are currently able to support with our current by-hand front-end JavaScript arrangements.
The df disk free tool is not fully btrfs aware. You are better off using the specific btrfs one:
btrfs fi usage /mnt2/rock-pool/
Where “rock-pool” in the above example is the name of the Pool, i.e. where we mount Rockstor managed pools. One could equally look at the system pool via its default mount point:
btrfs fi usage /
Within our Web-UI we have some work to do regarding accurate space reporting as, akin to df, we have some catching-up to do with quotas for example. Snapshots and active Copy-On-Write (COW) etc make these calculations tricky to attain. Btrfs also allocates in chunks that are not always fully utilised. And there can, on very full btrfs filesystems, be contention between what is needed to handle the COW and the associated metadata, i.e. there is some emergency reserve for metadata under the system label in the above command.
