#528 make restore more foolproof

[Anonymous]

Backup and restore is very inflexible. If users misunderstand or deviate even slightly from the instructions, they will be frustrated. Some ways to "fix" this are

1.) I'd like to suggest that the encryption key be tar'd alongside the DAT and TIME file into a single backup file. That wouldvprevent lots of user problems with forgetting to export the key file. (For example: the ability to backup directly to a mounted USB KEY, but not being able to export the encryption key in the same way seems like a problem to me. Instead, they need to use a different process [unmount, put USB in the web administrator's computer, and export key] to get a "complete" disaster recovery backup.) This feature request opens up a bigger can of worms though, because now the encrypted key needs to be stored in /var/ipcop/backup, so it can simply be copied to the USB. And the encrypted key needs to be updated during password changes, or if the backup.key is somehow changed.

2.) If #1 is rejected, I'd liek to suggest using *.key for restores. Many users want to rename the backup.xx.key file. The backup prefix looks unnecessary, and when told that they must rename the DAT file, and that the KEY file must be the contain the exact same hostname/domainname, they tend to rename the KEY file as well. For that reason I'd also suggest that the exported KEY file be named hostname.domainname.backup.key (and then the files stay together in sorted-by-name lists as well). If multiple KEY files exist, try them in preference order (hostname..., backup..., x.key) and check each time if the unencrypted DAT file is a valid tar. The KEY ought to be used during USB-MOUNT restores also.

[Anonymous]

Detail on logic flow needed to implement this feature request