Why restore needs so much time of verifying remote data

I have to admit that this has made me laugh, thanks. Yes, that’s a beginning, and then recreate the database, and hope that the stars align (the file and directory rights will not I think). It’s just that’s well, a bit long and complicated, it’s not exactly available out of the box and there is no warranty it will work well enough for all uses, so it’s just better to say that it’s not supported officially.

i havent decided yet, how to restore. Preferred way was to do all stuff on the server. But if it crashed and i need my data it would be nice to have the possibility to use other systems like windows. And like i understood restore is possible on other systems.

You are welcome ;-).
The idea comes from other backup software, where the absolut pathes to the backup folders was stored inside the config and from there the backup internal stores only the relative pathes. I like this concept to have the possibility to change pathes without changes in the backup (only config) to have it as much flexible as possible.

Sorry for this offtopic. Its not 100% needed for me. But maybe it helps to think of the architecture.

I think the way that works is that if Duplicati and its database gets moved and finds an OS mismatch, backup will be refused but restore will be allowed, but obviously you need to tell it new restore folder.

Restoring files if your Duplicati installation is lost

however if you want to be sure Direct restore from backup files works cross-OS, please try it.

Duplicati Destination is portable this way, even between types of storage, as names and storage are separated. I’m not quite sure how one would pull this off on the Source side. Paths could be anywhere. Duplicati does break a Source path into a folder (shared by other paths) and a file name to save space.

EDIT:

For a specific example, I have a backup with 67101 rows in its File SQL view, but underneath that is a 6074 row PathPrefix table with OS-specific prefix to get to the folder, and 67101 row FileLookup table giving the end part. It doesn’t have drive letters, but it’s a little OS-specific because a folder gets slash final character, and direction is OS-specific. This final slash also shows up (but isn’t obvious) in Filters.

The Remotevolume table has simple file names, and the destination folder comes from the server DB.

I created this issue:

It should not be too hard to fix, but there is some special handling of extended paths that needs to be taken care of.

1 Like