Qubes GUI integration

[tasket]

Create a Qubes GUI backup & restore application based on Wyng.

Application for Qubes backup and restore should be easy to use, similar to qubes-backup, with very few additional steps needed by the user (such as selecting a date separately from VMs).

Core features:

• Create archives
• Backup, Restore and Verify VMs

Possible ways to implement:

• Adapt wyng-util-qubes so that it performs both CLI and GUI operations (reminiscent of AmigaOS utilities)
• Adapt wyng-util-qubes to operate as a Python module, supporting a separate GUI front-end
• New code, or a dedicated GUI fork of wyng-util-qubes

Possible additional features:

• Scheduling of automatic backups
• Change archive passphrase
• Restore criteria select-able by date then VM name, or vice-versa
• Resume interrupted backup sessions
• Support cloud storage
• Mount archived volumes for individual file retrieval

Funding:

This work would be funded by grant(s) as proposed by @tlaurion

Blocking:

• Issue Operate as a python module #37

Related:

• [Contribution] qubes-incremental-backup-poc OR Wyng backup QubesOS/qubes-issues#858
• Please push wyng-backup as default backup tool for qubes-os! wyng-backup#102
• v0.9 release timeline wyng-backup#197

[tasket]

A note about adapting wyng-util-qubes, or using it as a way to understand the data model...

Backup should be easy to do since its driven by the VMs present in the system, and its simple to pass user selections to the existing backup code. Restore will require some study; most of the util's complexity is to support this function where archived qubes.xml data that changes over time must be mapped to Wyng volumes (which are also changing) and then to local volumes. In addition, users will probably want the option of starting their restore selections either by choosing a backup date then choose from available VMs at that date, or the reverse, choosing VMs then the date.

The first 35 lines of the restore code show how metadata about archive contents are initially retrieved. In particular, the collections 'wsessionqubes' and 'available' contain the select-able session dates and VMs, respectively. This should give you an idea of the possibilities for selecting content from Wyng archives. @marmarta

PS - I suggest before going forward that some time be spent using wyng with wyng-util-qubes. They can be easily installed by grabbing each from their 'src/' dirs and placing them in the same dir in your PATH, such as /usr/local/bin. PPS - They can actually be placed together in any dir.

[kennethrrosen]

Here's a quick mockup, kennethrrosen@f6f1bad , something I made as a proof-of-concept for personal use and which runs into the challenges of restore mentioned above. It assumes wyng and wyng-util-qubes are in ~/bin/

[deeplow]

Excited to see some momentum on this.

My two cents: Any GUI (re)design should start by looking at the state of the art (probably Apple's time machine) and seeing how they seamless (i.e. painless) backups. I experimented with this a bit and and once setup, (assuming the backup is done to a hard drive) the backup starts automatically as soon as the disk is plugged in. No need for user confirmation. As long as it is plugged in, it regularly performs differential backups.

[marmarta]

Excited to see some momentum on this.

My two cents: Any GUI (re)design should start by looking at the state of the art (probably Apple's time machine) and seeing how they seamless (i.e. painless) backups. I experimented with this a bit and and once setup, (assuming the backup is done to a hard drive) the backup starts automatically as soon as the disk is plugged in. No need for user confirmation. As long as it is plugged in, it regularly performs differential backups.

I think that while this is a good idea (to have the process as automated as possible), I think we should first start with a working manual backup system, then expand it. Especially as the manual update process will always have to be a thing.

Here's a quick mockup, kennethrrosen@f6f1bad , something I made as a proof-of-concept for personal use and which runs into the challenges of restore mentioned above. It assumes wyng and wyng-util-qubes are in ~/bin/

Thank you, this looks very helpful!

As for the implementation, I would vote for a GUI frontend as an addendum to wyng-util-qubes (probably least work on the backend side, but needs to be kept up to date if CLI interface changes) or the Python module option. A realistic list of first-release features would be, I think:

• create archive, set password
• backup VMs
• verify backup
• restore backup by VM name and date

With the rest of the proposed feature list coming next (maybe within the same grant, sure, but I think we should keep it simple for the first iteration).

[tasket]

@marmarta I'm leaning towards a separate GUI app that uses wyng-util-qubes as a module. Since date-time is a factor in selecting objects and Qubes has more than one volume-naming format, there is a lot mapping that has to occur. This is already figured out in the util.

Using a module, it may also be possible to add Wyng support to existing qubes-backup relatively cleanly.

[tasket]

Created issue #37 for adapting wyng-util-qubes as a python module.