[Feature Request] save / restore options about openmediavault HOT 19 OPEN

When OMV5 is using Salt as config engine this should be more or less an easy task to implement.

EDIT: This comment is outdated, there are a bunch of issues (see some of them below) that block this feature.

from openmediavault.

#101

This is a major change, and it will help to finally have ability to restore settings if i am not mistaken.
Be aware omv5 will have no upgrade path, major redesign under

from openmediavault.

@votdev github shows issue linked with project "5.x" and status "awaiting triage" which seems incorrect. how to fix ?

from openmediavault.

using Salt as config engine this should be more or less an easy task to implement.

there have been several forum threads that would greatly benefit from having this feature available

searched OMV Forum using site:forum.openmediavault.org +configuration +new hardware

examples:
migrate from bananapi to PI4

htpc/media/storage solution is full, and I have decided to build my own nas/web/backup/file server

new hardware (new motherboard, new larger disks)

from openmediavault.

This script would enable to resolve OS issues outside of OMV's control easily

Benefits:

• remove the pressure for getting an issue resolved via forum posts
• protect user's time invested to configure OMV
• enable a support approach popular in IT cloud mgmt (if solution instance has issues, kill it and create new instance with no/very little manual effort).

Example:
apt-updates-packages-but-then-they-show-as-new-updates-again
email-notifications-stopped

from openmediavault.

This would not fix apt issues. OMV is just reporting what apt is reporting.

from openmediavault.

@ryecoaaron there is no expectation about fixing apt issues. the referred forum post is to support the expected benefit "protect user's time invested to configure OMV"

from openmediavault.

That wasn't clear since I don't think fixing apt issue by re-installing OMV is the correct approach.

from openmediavault.

I don't think fixing apt issue by re-installing OMV is the correct approach

well you are invited to post a solution for this specific issue but generally "Fix any unclear issue via reinstalling OMV" is a common recommendation given in the forum.
Unfortunately most users are unable to recreate their old configuration easily.
This feature would resolve that dilemma and has therefore the potential to avoid or at least reduce the number of interactions (question, clarification of missing info, suggestion for solution, follow-up, etc) for many forum support posts.

from openmediavault.

Most apt issues have solutions posted in another thread. I don't have time to answer every thread that is just a rehash of others. And don't ask me to find them. An OMV system in a broken upgrade state is not an apt issue.

You don't have to sell me on a config import. I think it is a good idea. Just going to be difficult to implement even with salt. People are going to try to use a config that is missing some or all of the drives from the backup file. Since most servers are dependent on shared folders which are dependent on drives, this will make it tough to restore.

from openmediavault.

You don't have to sell me on a config import. I think it is a good idea. Just going to be difficult to implement even with salt. People are going to try to use a config that is missing some or all of the drives from the backup file. Since most servers are dependent on shared folders which are dependent on drives, this will make it tough to restore.

In my experience knowing what was there is 90% of the solution to restoring it. Even if the drives and shared folders were populated, but non-functional or in an error state it gives a huge jump towards having a working system.

The raw xml has been helpful for this in the past (for me), but is definitely not the most user-friendly.

from openmediavault.

@ALL If a config backup/restore would be an easy task, then you can be sure that it would have been already implemented in OMV.

You don't have to sell me on a config import. I think it is a good idea. Just going to be difficult to implement even with salt.

Salt is the way to go this route, but rebuilding the configuration after an import is the easiest thing. With Salt it is now a simple omv-salt stage run all.

The biggest issue is keeping track of different database versions. Imagine a user has plugin version x and makes a backup. After a new installation the plugin is already at version y and the database structure for this plugin has been changed. Keeping track of this situation is the biggest problem, but solvable because OMV already has database migration scripts.

What happens with the drives? Imagine, the user replaces the disks because he thinks upgrading storage from x TiB to y TiB disk space is a good idea in this situation. Now the whole file system and shared folder configuration is incorrect, because the new disk has maybe no file system, or when there is a file system, the device file and UUID is different.

There are so many other topic that you have to keep in mind when you want to provide such a feature. And all those problems have prevented me from implementing a feature that is broken from the start.

from openmediavault.

all those problems have prevented me from implementing a feature that is broken from the start.

@votdev
Now with this revised statement it would make sense to delete #102 (comment)
because this comment created a wrong expectation

In my experience knowing what was there is 90% of the solution to restoring it.

fully share this view, so could a listing of shares, users & groups be achieved?

from openmediavault.

Another blocker are the users/groups. OMV does not store which users/groups are created via the UI, they are immediately created using system commands. So it is not possible to export and import them. The next problem is the user passwords, which are also not stored in the OMV database. Without these password it is not possible to re-build the SMB user store. Finally all shared folder privileges will be useless without having the users/groups on the new system.

Storing the users/groups that are created via the UI in the OMV database should be no problem, but storing the passwords there is really no good idea, even if they are stored encrypted (NOT hashed, because the need to be encoded into plaintext to re-build the SMB user store). But what happens with the users/groups that are created via CLI and OMV is able to process? OMV can't detect those.

Because of the security aspect i really don't want to store the passwords in the OMV database, but without users and their passwords a fundamental part of OMV is missing in the import/export feature, so this is another reason to do not implement this feature.

from openmediavault.

From above reply I understand that the current documentation regarding /etc/openmediavault/config.xml is not fully correct
"What is the file /etc/openmediavault/config.xml for?
It is the database configuration store file for openmediavault. When a change is performed in the web interface, the config value is stored and/or retrieved by RPC to/from this file."

Lets try to summarize the remaining open issues that seem to prevent making (design) documentation and actual implementation consistent first, then see if a solution can be found in the next step.

Open issues are:

• password for a user is only stored & controlled by OS
• on a different computer device files and UUID are different

Did I forget anything?

from openmediavault.

@votdev this issue is currently in Backlog for 6.x but from the conversation above I'd assume the assignment to be wrong.
Could you please review & update gh project assignment & labels?

from openmediavault.

This issue has been automatically marked as stale because it
has not had any activity for 60 days. It will be closed if no further
activity occurs for another 30 days.

from openmediavault.

This issue has been automatically closed because there has
been no activity for 90 days. We are sorry that we haven't been
able to prioritize it yet. Please feel free to reopen this
issue or create a new one. Thank you!

from openmediavault.

https://github.com/xhente/omv-regen is very close to achieving the goals defined in this issue.

There are from my view a few open issues with defaults and wording in documentation but they could be overcome.
More details in forum thread "omv-regen backup" triggers unexpected version upgrades

from openmediavault.