Comments
Sort by recent activity
he can simply run the same script to run the restore
-full stop-
You're absolutely right petey, it was so obvious that I felt ashamed for missing the point [image] I fully agree with all your remarks.
Perhaps the winapi could be used to keep the context limited, but again this brings a lot of considerations and potential problems. / comments
he can simply run the same script to run the restore
-full stop-
You're absolutely right petey, it was so obvious that I felt ashamed for missing the point I fully agree with all your remarks....
> One solution would be to use a different encryption scheme for our restore password and our backup password
Exactly, the way it should be.
> but this could lead to confusion
I don't think it would lead to any confusion, esp. if the original password stays legal. Nothing in backup-restore procedures and generated scripts would have to be changed. But you would just have an option in the GUI to get a 'restore key'. And it would be as simple as using a new salt value in the encryption algorithm.
> I will log a feature request for our product manager and designers to look at for future releases.
Thank you / comments
> One solution would be to use a different encryption scheme for our restore password and our backup password
Exactly, the way it should be.
> but this could lead to confusion
I don't think it woul...