Verifying restore path before actual restore starts

This is really small and niche case, but gave pretty bad UX. Even I have to admit that this problem is 100% caused by invalid user error.

–restore-path=
Restores files to instead of their original destination.
Top folders are removed if possible.

The restore-path value and user rights are only confirmed when actual restore starts. In my case, it took about two weeks to get the error, that the restore-path is invalid. That’s quite annoying, because the intermediate work wasn’t saved, and it took extra two weeks to get the restore to run with correct path.

Sure, any smart admin, would make sure that the path is right in that case, as well as write permissions are set correctly. Or even test restore with limited data set. But if we acknowledge the fact that users are sloppy and stupid (as I am), it would be possible to provide better UX by checking the restore path viability earlier in the process.

  • Thanks

I must be missing something…why did it take two weeks? Did you script a restore but just not run it for two weeks?

Well, that’s because of the “legendary database rebuild” and recovery process, which can take a while with 2 TB backup set as we know on this forum already. And that happens before the restore-path is verified. Well, rebuild was a success, but the restore-path was invalid. Due to ahem, invalid user (me).

So this was a single operation, like you were doing a restore direct from remote data with no local database? Otherwise it seems like two operations to me - recreate local database then do a restore operation after that completes.

It does seem like a good idea - Duplicati should test the restore destination for access/validity before the restore job is submitted.

I always do all of my tests without the local database. Why? I’ve found out that with the database everything can seem to be good, and without it, you can’t restore. And I’ve strongly objected against that, because… Yeah, you know what it means. You’ve got disaster recovery backups and when disaster strikes you can’t recover. But I’ve said everything I’m going to say about that in the other thread. Personally I find that the most disturbing feature with the current versions, and it makes me sweat at night.

Well, I know way too well stupid users and lazy developers. I do almost daily wear shoes of both user groups. Users say that program didn’t warn about that and it doesn’t work, and developers say that users are stupid because they don’t use the program correctly.

Btw. In my case, there wasn’t user rights management issue, but the path I referred to was non-existing, and Duplicati didn’t even create it, even if it could have created it. But if I think about the stupid users, also verifying the rights would be a good idea. I did assume I would have that path, but I forgot that another script which I use for restore testing did delete the directory completely, because at the start of the script it tries to create the directory. I just thought the script would empty the directory after testing previous backup restore job.

Agreed - absolutely good idea to test restores this way. Also I test full database recreations every now and then. Have been working on just that this week, actually. Better to catch problems and try to resolve them before you actually have a disaster. :wink:

Fortunately I have not experienced that level of problems at all… I have no idea why you have been so unlucky.

In any case I think the subject of this thread is a good idea. Can you submit it as a feature enhancement request on github?