Hi @HarryHUK,
I unfortunately have not been able to find the time to try reproducing that behavior–very busy at work lately–but I can still try to give you additional pointers to look at what could have happened in case you’re interested. I’ll thus go back to how the config backup & restore works as that’s an important part.
First, here’s the link to our related documentation–for those who have not yet seen it:
https://rockstor.com/docs/interface/system/config_backup.html
The gist of the process is as follows:
- Backup: export select parts of Rockstor’s database, which thus includes settings and configurations that the user might have done to these select parts.
- Restore: use Rockstor’s API endpoints to re-instate these settings/configurations into Rockstor’s database the same way they happen when the user made these changes using the web-UI.
This means that these select parts of the Rockstor database will be in the same state as they were at the time the backup was taken. The config backup is thus a snapshot of these select parts of Rockstor’s database.
Thus, if something seems to not have been returned to what it was, the first thing to do would be to verify it was indeed included in the backup. As you mentioned that you already looked into your backup, I would be curious to know whether you can find the “Added storage” that was problematic in your case this your backup.
The way these specific “added storage” are identified in Rockstor’s database is by the "uservol" boolean flag–see the section describing the DVolume model in our wiki post. As a result, you could look for the "uservol": true string in your config backup JSON and see if you can find the share in question here.
Note that these are defined at the container level rather than rock-on level, as this is how volumes are bound in Docker. You can find more details in our wiki post linked above on that if you’re interested.
I’m glad you could get your system back to the way you want it anyway! These additional storage mappings (the “Add Storage” option in a Rock-on post-install customization) are the best way to share data (Shares) between Rock-ons and this what fits the “Docker-way”. I would thus recommend to go this route if you want/need to share “Shares” between two or more Rock-ons.
Hope this helps!