Does "Restore on Demand" work for anybody -- with encrypted media sets?

[Maser]

As far as I can tell, "restore on demand" does not work if the media sets are locked (ie, if they are AES-256 encrypted and you follow the default prompt to "remember password for scripted access")

 

If I manually open the console and unlock the media sets, then the clients can see their backups and run a restore.

 

But if the media sets are locked -- the client doesn't seem to be able to initiate an "unlock" to see the backup history -- because it's not "scripted" access.

 

 

Or am I missing something obvious? (It seems wrong to me to leave encrypted media sets as "remember password for any access", but maybe that's what needs to be done?)

 

- Steve

[David W Lee]

Steve, what you have observed is the current design.

[Maser]

OK -- but consider this a request for an "enhancement" -- because it's a flawed design in this respect.

 

I have 8 media sets -- all of them are fairly large. If I leave all of them unlocked, it can take the console up to 5 minutes to actually populate anything (the IOS app actually works better here).

 

So, when I set up new media sets with Retro 10.0.1, I had left them accessible via script only -- which lets the console open in 15-30 seconds as expected.

 

 

So, if a client is allowed (by the engine) to actually do restore on demand, then the client should be able to send a "temporarily unlock" signal to the engine for this purpose -- otherwise the media sets should stay locked.

[David W Lee]

Thanks. We are collecting feedback and will see how to improve this.