Backup

The backup is possible in following places:

1. Same disk
   In this case, if you lose a device, you lose everything
2. Flash disk
   You must do manual procedure (which is hard for most users) and in this case the backup can’t be automated, however this is safest way of doing backups.
3. Email
   On a first approach, this look’s like the best way, but it has many disadwantages … You must have a smtp server to send emails or you can use sendmail utility which is not available in all operating systems by default, that means that the whole system is becoming OS dependent.
4. Blockchain
   It’s not the best decision to floodfill the blockchain by enumerous backups and in other hand it’s the most complicated way to backup because you must also check the awailability of funds and pay commission.
5. Other place
   FTP, special device needs separate code, API and manual config.
6. Current service node
   This is the best decision.
   1) The probability that the service node will fail together with your device is very small.
   2) If the file is encrypted and the filename is random the node owner will never know what’s inside this file.

Backup

1. Generate SEED and generate KEY from seed
2. Write down the SEED
3. Backup all the local keys (users.json, my-nodes.json and backup.json) to the encrytped file with random name (gdhex.356)
4. Upload gdhex.356 to service node
5. Write down the LINK to this file

Restore from backup

1. Upload gdhex.356 from service node using backup LINK.
2. Restore backup key from seed
3. Decrypt local keys (user.json, my-nodes.json and backup.json) from encrypted backup file gdhex.356.
4. Regenarate user keypair
5. Update Blockchain NVS record with user data and public key.

Prev. artice about client and node communication