Feature request: Restore files from client

It would be wonderful if we had the ability to restore files from the client side. Forgive me if I am wrong, but currently to restore files you have to log in to the web interface of the server and download the files from there, or copy them from the proper server directory? @uroni, is the possibility of restoring from the client side on the feature roadmap? Is there a roadmap that we can look at somewhere?

1 Like

This would be a nice feature… +1 from me.


I don’t get it. The files don’t reside on the client. It makes a lot more sense to me to restore files from the web interface. The “client” is more of an agent.

An agent that could download the files from the server… Ever use any of the online backup services? Or Dropbox? Or Google Drive? I just want to cut out the step required on the server side, and make the clients more self-service.

I see where you’re coming from. I personally love all of the security of needing to go to the interface for major tasks and being able to lock down the client.

Yeah, but as long as each client can only access its own backup and that is tied back to its UUID, it should be fine. It could even be a permissions feature also that would have to be enabled? On the off chance that you have to restore a large volume (like another Cryptolocker attack), it would be a pain to first copy all the files to another directory or FTP share and then copy them again to the client. It would double your time to recovery. The only way I can think of around the double copy is if you were to open the UrBackup interface on the client and then copy directly to it. That is not super secure though, leaving an open webpage to all of your backup information active on a client you might not have control of for several hours as you copy them back over. Even worse for internet clients.

You can start a huge directory downloading as a zip and then close the interface…

1 Like

Nifty, did not think about that. Recent experience has shown Chrome to stop the download when you close the page. That must have been site-specific. Still, it would be nice from a sysadmin standpoint for people to serve themselves. Especially if you are backing up workstations and such.

So, if there was a link on the client that would go directly to the Web Interface for that specific client’s backup, would that solve this?

If it also authenticated them, perhaps? Like use of a token that is burned after a number of hours?

makes sense. I would think that would be the easiest way to add a feature like this. If we wanted to even go lower tech (simpler to code), we could just use un/pw auths on the website that were assigned to specific clients.

I don’t know how much work this would take, but it’s a thought.

Yeah, or now that I think about it we could just pass the client internet auth key to the webserver for authentication. As all of this happens over SSL, I would not think it to be a concern as that is what it does when it negotiates a connection for a backup.

It would likely require a bit of work in the Apache configs though and make the install a bit more complex. Still manageable though.