FR: Use minimal number of levels during restore

[Hofer-Julian]

borg extract recreates the whole file tree of the backup in the current working directory. These are sensible defaults for system backups, but maybe less suitable for Vorta which is focused on user data. This is discussed in https://github.com/borgbase/vorta/issues/431 and https://github.com/borgbase/vorta.borgbase.com/pull/4.

I suggest to change Vorta's current behaviour, so that uses the common root of all files/directories to extract as starting point.

An alternative would be a checkbox, but I personally would like to reduce the number of options to a minimum.

[m3nu]

If this is really needed, I'd make it a checkbox. E.g. "Strip common parent folders before extracting"

[Golddouble]

This would be very helpful. Otherwise we always first have to restore the folders/files into a temp folder and after we have to move the files, where they must actually be.

Or how do you experienced Vorta users do a recovery? Are you able to recover your data in one step without a temp folder? Very interested in this. Thank you.

?

[Hofer-Julian]

If you extract to "/" you don't need a temp folder

[ThomasWaldmann]

extracting to non-empty target directories might lead to a mixup of present files and restored files.

[Golddouble]

@Hofer-Julian Thank you. I was not aware of this. This is a very helpful hint. I have tried it out. Works fine. So as we have this possibility, I no longer find this enhancement proposed in this thread absolutely necessary.

extracting to non-empty target directories might lead to a mixup of present files and restored files.

Enhancement: Maybe there should be added the following features into Vorta:

1) . When restoring into "/" and there are files in this target, that are not in the backup: Then this files should be moved to a folder "Files that were not in the backup -date of restoring-". (Of course the folder structure should be kept. (So not only the files, but also the corresponding folders should be moved there).

This way we would have a clear restore without losing anything. And this would be a fast way to decide what files, that were not in the backup, could be deleted, because we have all this files in one folder. We do not have to search them manually by comparing the files in the backup with the files in the target manually.

2) Maybe also this: When restoring into "/" and there are files in this target, that are never than in the backup: Then this files should be moved to a folder "Files that were newer in the target -date of the restoring-". (Of course the folder structure should be kept. (So not only the files, but also the corresponding folders should be moved there). -> This would prevent to lose anything important.

Or you nevertheless implement the enhancement proposed in this thread with the checkbox and combine it with my enhancement requests 1) and 2).

[ThomasWaldmann]

@Golddouble that pretty much sounds like overengineered, unexpected behaviour.

The task of a restore is to restore files, not move existing files around on your filesystem.

And as it is just "unpacking" a backup archive, you can not expect sync-like behaviour (like deleting existing files or directories) either.

So the easiest and most reasonable way to deal with that is to extract into an empty directory. If you want your files elsewhere afterwards, you can still move them.

[Golddouble]

@Golddouble that pretty much sounds like overengineered, unexpected behaviour.

... you can not expect sync-like behaviour (like deleting existing files or directories) either.

I agree.

Other suggestion for my -enhancement suggestion 1)

This files should not be moved. But nevertheless Vorta should save a list with the files in the folder of the repository where the backup is stored. For example in ... /media/user/externalHDD/VortaRepository/FilesThatWereNotInTheBackupButAlreadyInTheTarget

The list should be in a *.txt file in the form of Regex syntax. For example: /home/user/folder1/File1|/home/user/folder2/File2|/home/user/folder3/folder4/File3

If you want your files elsewhere afterwards, you can still move them.

So we can then copy this Regex syntax from this *.txt file into a search program like FSearch and become then exactly the list with this files. Then we can delete them in one step or individual files or we can move them.

Maybe when a restore process is finished, Vorta could pop up a message like: "There were X (number) Files in the target, that were not in the backup. They are logged into *.txt. Do you want to open this log-file?" yes/no

-enhancement suggestion 2)

If you want your files elsewhere afterwards, you can still move them.

This would not be possible with these files, because they are overwritten by the restore process.