Document backup/restore procedures

[eloquence]

Clear backup/restore procedures are going to be a must-have requirement for wider production usage of SecureDrop Workstation.

[eloquence]

As a first step, @rocodes has offered to spend about a day on exploring the current options. We're interesting in questions like:

• Can a working SecureDrop Workstation be reliably backed up and fully restored using Qubes' own backup tools?
• If not, are there alternatives we should consider for a full system backup?
• If a full system backup/restore presents significant challenge, can we facilitate restoring data/configuration upon a reinstall?

This will guide our documentation efforts.

[eloquence]

@rocodes Can you post a summary of your findings so far to this issue?

[eloquence]

Cross-referencing progress update here: freedomofpress/securedrop-workstation#120 (comment)

[rocodes]

Circling back to this:

• As per Document backup policies for the workstation securedrop-workstation#120, a combination of the existing Qubes backup tooling, plus some additional tooling that backs up the required components from dom0 (if we decide we want to do this), would allow for a good backup-and-restore strategy, but see below note on security.
• The sdw backup/restore story should allow afford backing up custom qubes, most likely using the qubes gui backup tool, for users that customize the Workstation
• Whatever backup tooling we create should be reviewed carefully (see for example, paranoid restore mode, which doesn't restore anything to dom0). SecureDrop Workstation relies on settings (such as rpc policies and/or tags) that go beyond the scope of what Qubes would normally back up or restore to dom0.
• I think it's reasonable to break this into 2 goals: a quick/simple first pass at a backup and restore story (likely a partially manual process) and some docs, and then a followup at some point later on with a more developed tool (e.g. with gui integration) if we're happy with the workflow.

Scope of backup questions

• Do we back up:
  • sd-app, sd,dev, sd-gpg, sd-log, dom0?
  • appVms, all templates, dom0?
  • appVMs, templates, dom0, fedora32 template? (least sensible imo)
• Do we back up and restore dom0:
  • home directory, per current Qubes policy)?
  • elements of dom0 outside the home directory, such as rpc-policies, tags (including tags indicating copy-paste tags/preferences that users have set, etc.)?

[rocodes]

For the coming sprint, I can work on the 'first pass' part of this (basic workflow + documentation) but I think we should answer the scope questions, especially around things like what parts of dom0 we back up. As an aside, when trying to think about this: the restore workflow currently requires users to run ./sdw-admin --apply anyway.

[eloquence]

Thanks @rocodes. A first pass workflow that includes manual steps sounds like a great first step to me.

I think there are two Qs likely to come up from newsrooms:

1. My workstation broke, how can I get back up and running to a state similar to what I had before?
2. We've added a bunch of VMs for other stuff, how do we back up that data/restore it?

The first of these seems to me the most important to speak to clearly in the docs soon. Given that the server holds the same submission contents as the workstation, that's mainly the secrets that live in dom0, plus maybe the tag configuration and maybe secrets in vault. Re-installing the RPM and re-running sdw-admin --apply is IMO a reasonable ask for recovery. Does that sound reasonable / what would you & others propose?

[rocodes]

I'm adding a note (to myself?) to investigate https://github.com/tasket/wyng-backup for faster/incremental backup support in Qubes.

[nathandyer]

@rocodes Do you feel that #246 covers off this issue? Or is further expansion/research planned?