[IPCop-devel] [ ipcop-Feature Requests-3588715 ] make restore more foolproof

Feature Requests item #3588715, was opened at 2012-11-20 03:03
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=3588715&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Next major version
Status: Open
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: make restore more foolproof

Initial Comment:
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.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=3588715&group_id=40604