Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the UX of the backup restore process #4946

Open
andrewdavidwong opened this issue Apr 3, 2019 · 4 comments
Open

Improve the UX of the backup restore process #4946

andrewdavidwong opened this issue Apr 3, 2019 · 4 comments
Labels
C: core P: major Priority: major. Between "default" and "critical" in severity. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. ux User experience

Comments

@andrewdavidwong
Copy link
Member

andrewdavidwong commented Apr 3, 2019

The problem you're addressing (if any)

When restoring a dom0 backup, it is not obvious to many users how to replicate the old qvm-backup-restore behavior prior to #2271, where configuration files from the backup will take effect in dom0. In reality, it's simple:

$ mv home-restore-2019-04-01-etc/* .   # move all normal files out
$ mv home-restore-2019-04-01-etc/.* .  # move all hidden files out

The problem is that many users (understandably) don't know to do this.

Describe the solution you'd like

An option for qvm-backup-restore and the GUI so that the user can choose to do this sort of restore, where the contents of the backup are restored directly to dom0's /home.

Where is the value to a user, and who might that user be?

This benefits less-technical users and any user who effectively wants the contents of a dom0 backup to override dom0 on the current (restore target) machine.

Describe alternatives you've considered

An alternative is just to document the procedure. I leave it up to the devs to decide how to proceed.

Additional context

This discussion thread shows a real case where the feature would have been useful to a user, and the ensuing discussion provides a lot of context for this feature request:

https://groups.google.com/d/topic/qubes-users/CymcbLRGwpg/discussion

Relevant documentation you've consulted

N/A

Related, non-duplicate issues

Related: #2271, #1106, #3975

@andrewdavidwong andrewdavidwong added T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. labels Apr 3, 2019
@andrewdavidwong andrewdavidwong added this to the Release 4.1 milestone Apr 3, 2019
@awokd
Copy link

awokd commented Apr 11, 2019

How about an "Overwrite" checkbox on restore? If dom0 is selected, it would restore to the appropriate place in ~. If VMs, it would clobber per your suggestion #3975 (comment).

@andrewdavidwong
Copy link
Member Author

andrewdavidwong commented May 26, 2019

Ideally, we would have a series of steps in the restore process where each situation is explained to the user, and the user is allowed to make a decision. Here are some examples (checked boxes are the suggested default options):


Would you like to restore the dom0 home directory from your backup?
(The files in this directory control various desktop configuration settings in dom0.)

  • Yes
  • No

There is already a dom0 home directory on this system. Which dom0 home directory would you like to use?

  • My current system's
  • The dom0 home directory files already on this system will be left alone.
  • Your dom0 backup will be restored into a new subdirectory.
  • Your dom0 desktop configuration settings will not change.
  • My backup's
  • The dom0 home directory files already on this system will be replaced by the files from your backup.
  • The dom0 home directory files already on this system will be moved into a new subdirectory.
  • Your dom0 desktop configuration settings will change to the settings from your backup.

If there is already a qube on this system with the same name as a qube being restored:

  • Assign a new name to the qube being restored

For example, if there is already a qube named work on this system, when we restore a qube from your backup that is also named work, we will rename the restored qube to work-1. After the restore, you will have both work (which was already on this system) and work-1 (which was just restored from your backup).

  • Replace the existing qube with the qube being restored

Caution: Each replaced qube will be permanently deleted. This action cannot be undone.
For example, if there is already a qube named work on this system, and a qube that you want to restore from your backup is also named work, we will delete the work qube currently on this system and restore the work qube from your backup. After the restore, you will just have one work qube (the one restored from your backup). The work qube currently on this system will be permanently deleted.


I'm increasing the priority of this issue, since we've gotten further reports of users being confused by the current restore process, e.g.:

https://groups.google.com/d/topic/qubes-users/rE_bfOhPdaU/discussion

CC: @marmarek, @marmarta

@andrewdavidwong andrewdavidwong added P: major Priority: major. Between "default" and "critical" in severity. and removed P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. labels May 26, 2019
@andrewdavidwong andrewdavidwong added the ux User experience label May 26, 2019
@andrewdavidwong andrewdavidwong changed the title Provide qvm-backup-restore option to move dom0 backup contents into dom0's /home rather than subdirectory Improve the UX of the backup restore process May 26, 2019
@tasket
Copy link

tasket commented Jun 14, 2019

To implement overwrite for dom0, I'd suggest keeping the present code but adding one more step that does an mv from the restore subdir to the home dir (and then remove the restore subdir).

@ninavizz
Copy link
Member

This feels related to many things I'd like to address in a future consolidated "Q Manager" experience in #6483.

@andrewdavidwong andrewdavidwong removed this from the Release 4.2 milestone Aug 13, 2023
@marmarta marmarta removed their assignment Mar 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: core P: major Priority: major. Between "default" and "critical" in severity. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. ux User experience
Projects
None yet
Development

No branches or pull requests

5 participants