User:Senya/Account Backup And Restore: Difference between revisions

From diaspora* project wiki
Line 84: Line 84:
* User is sent an email containing information regarding: Where to restore in case of problems? What information to store (the pass phrase)
* User is sent an email containing information regarding: Where to restore in case of problems? What information to store (the pass phrase)
* Schedule initial sync immediately.
* Schedule initial sync immediately.
=== Pod reads NodeInfo from other pods ===
* Update information of pods wanting to receive backups
* If no backup pods previously existed, add backup pod to all existing users who didn't opt out and schedule initial sync


== Pod schema changes ==
== Pod schema changes ==

Revision as of 11:06, 11 October 2015

Work in progressWork in progress:This article is a work in progress, it may contain incomplete or inaccurate information. There may be additional information on the talk page.
NoteNote:This is a proposal, not an accepted specification.

Description

Proposal specification to deal with two problems:

  • Dying pods (ie losing your account due to pod disappearing)
  • Pod migration (ie not being able to move pods)

High level concept

  • Users are backed up automatically to pods who opt-in to receive backup data
  • The restore process migrates the user to the pod he/she is restoring on
  • Backup data is encrypted to protect the private key contained
  • Backup is automatic and after the user chooses a pass phrase, the user doesn't have to do anything else, except store a piece of information

User stories

User creation

  • User arrives at user creation.
  • User is asked to give a pass phrase for backups. User can opt-out, which ends this user story.
  • Pass phrase is stored in user table in plain text (so it can be used to encrypt).
  • Backup pod is chosen from available pods automatically and stored in user data. In the case of no available backup pods, exit here.
  • User is sent an email containing information regarding: Where to restore in case of problems? What information to store (the pass phrase)
  • Schedule initial sync immediately.

Manually choosing a backup pod

  • User goes to settings.
  • User chooses to a new backup pod from a list of available pods.
  • User chooses a pass phrase.
  • User is sent an email containing information regarding: Where to restore in case of problems? What information to store (the pass phrase)
  • Schedule initial sync immediately.

User data restore

  • User follows link to restore page on backup pod (for example /restore_backup)
  • User gives email and pass phrase.
  • User is sent an email which needs to be verified by opening the link.
  • User is asked to provide a password and username for their account.
  • A local account is created on the backup pod and linked to a possible profile.
  • Backup pod sends out "I've moved" federation messages to all known pods, signed with the users private key.

Receiving a moved message - remote pod

  • Pod verifies message against user public key (as normal)
  • Pod fetches new profile as per moved message
  • Pod replaces local profile with new information
  • Pod makes sure all locally stored content to this person points to the changed profile (should only require change of profile data)

Receiving a moved message - old home pod

  • Pod verifies message against user public key (as normal)
  • Pod fetches new profile as per moved message
  • Pod replaces local profile with new information
  • Pod removes local user, making the user now a remote user
  • Pod makes sure all locally stored content to this person points to the changed profile (should only require change of profile data)

Backup pod receiving a backup for the first time

  • Send email to user that backups are being received and instructions on how to proceed if migration is wanted.

Becoming a backup pod

  • Podmins enable "allow_backups_and_migration" in pod settings.
  • NodeInfo gets a new metadata entry to indicate pod accepts backups.

Receiving backups

  • Pod receives a backup message from another pod and stores it.
  • If a previous backup for the user already exists, replace it.

Automatic sync

  • Pods should send out backups of user data every X days to the backup pods.
  • When a backup is sent out, the next one should be scheduled in sidetiq for the next time.

Sync to backup pod fails

  • Increase failed count in user data.
  • If failed count is over threshold (default 3), choose a new backup pod from available pods.
  • User is sent an email containing information regarding: Where to restore in case of problems? What information to store (the pass phrase)
  • Schedule initial sync immediately.

Pod reads NodeInfo from other pods

  • Update information of pods wanting to receive backups
  • If no backup pods previously existed, add backup pod to all existing users who didn't opt out and schedule initial sync

Pod schema changes

Backup data

Pods need a new model "backups" to contain backups from remote pods. This should be uniqued on email and any new backups should replace the current one.

  • email
  • content (encrypted)

Pods don't need to even know where the data is from - just email and the actual encrypted backup.

User data

Users need some extra flags:

  • backup pod
  • backup pod failed sync count
  • pass phrase

Backup pod is the domain.tld where the backups are sent. If it changes, it should be updated.

Backup contents

  • Profile
  • Aspects
  • Contacts
  • Followed tags
  • Public and private key