Full Mist Backup

[alexvandesande]

• Export private keys
• Export the mist UI local storage on request
• Export every added tab local storage on request
• Put all on a single encrypted file (maybe M of N in case they lose one key)
• Develop a manual export/import tool
• In the future, develop an automatic export to some external file on a safe place on the system
• In the future, develop automatic encrypted backup to swarm

[eburgel]

On my Windows 7, there is no Ok button, to make the save.

[hiddentao]

This relates to #555. We need to do this work sooner rather than later.

[hiddentao]

Users should be also be able to restore from a backup from within the UI. For that to work properly we need to be able to effectively shutdown and then restart the geth node (we restore the folder during shutdown). That architecture needs to be solid (which means we can't have issues like in ethereum/meteor-dapp-wallet#152 (comment))

[hiddentao]

When doing a restore, if the user is running geth separately we won't be able to restart it from within Mist. Ideally we would be able to restart geth via an RPC/IPC command or have it reload its keystore, etc. The mgmt interface doesn't currently have anything like that.

More thoughts...

• If we could restart geth via its API then there is argument to be made for having the backup and restore functionality put straight into geth, thus benefiting users who use geth from the command-line too. Mist would then just have the code for doing scheduled backups (which internally would simply call into geth's API at the scheduled times).
• If we shifted the functionality into the geth node then what about the other nodes like eth? if we're only focussing on geth going forward then this isn't an issue, otherwise the others will also need to support these commands.
• if we didn't shift this functionality into geth then we could either a) tell the user to restart their node instance once restore has completed in order for the changed data to be loaded, or b) tell the user to shutdown the node and restart Mist on its own in order for Mist to be able to do the restore. The (b) option in this instance clearly sucks.

The above issues are relevant for when we want to restore. If we're just talking about doing backups then we can certainly have Mist do all the backup logic.

[alexvandesande]

But we can restart from within mist, if Mist started the node. I believe anyone who is tech savvy enough to run their own node is savvy enough to restart it when prompted.

On May 3, 2016, at 23:36, Ramesh Nair notifications@github.com wrote:

When doing a restore, if the user is running geth separately we won't be able to restart it from within Mist. Ideally we would be able to restart geth via an RPC/IPC command or have it reload its keystore, etc. The mgmt interface doesn't currently have anything like that.

More thoughts...

If we could restart geth via its API then there is argument to be made for having the backup and restore functionality put straight into geth, thus benefiting users who use geth from the command-line too. Mist would then just have the code for doing scheduled backups (which internally would simply call into geth's API at the scheduled times).

If we shifted the functionality into the geth node then what about the other nodes like eth? if we're only focussing on geth going forward then this isn't an issue, otherwise the others will also need to support these commands.

if we didn't shift this functionality into geth then we could either a) tell the user to restart their geth instance once restore has completed in order for the changed data to be loaded, or b) tell the user to shutdown geth and restart Mist on its own in order for Mist to be able to do the restore. The (b) option in this instance clearly sucks.

The above issues are relevant for when we want to restore. If we're just talking about doing backups then we can certainly have Mist do all the backup logic.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub