Some questions about restore

Support
#1

Hi,

performing a restore from Duplicacy Web Edition container that i run as root i noted the following things:

1- in my dirs i have some sub dirs called “custom-services.d” and “custom-cont-init.d”. These are not shown in Duplicacy to be restored, but after a restore they are there, so correctly restored. Why i can’t see these dirs in Duplicacy?

2- i perfomed two test restores of the dir /AppData/qbittorrent/config. I wanted to restore only the content of /config dir but instead the whole /qbittorrent/config was restored. Why the top dir was included? In the Web ui i selected the config dir the first time and also clicked on the little folder icon next to the name the second time. Both times also the top dir was restored.

3- when restoring the dirs i was discussing above, the /qbittorrent dir is owned by root. The content, /config and all subdirs are correctly owned by my user so permissions are restored correctly. Not using -ignore-owner.

4- after restore an empty dir .duplicacy was placed next to the restored dirs. What is that for?

Thanks in advance!

#2

It calls duplicacy list -files to get the list of files. Empty directories do not show up there because they don’t contain files. (It’s an explanation – not an excuse; it’s still needs to be fixed)

2 Likes
#3

May be this bug: QNAP files restored to a new location are inaccessible, CLI 2.7.2

1 Like
#4

Thanks for pointing this out.

My container is running on ARM tho.

If i understand this correctly this issue should disappear trying to restore from backups performed after the fix was implemented? My Web Edition is running on CLI 2.7.2 and I was restoring a backup from 15 Jan 2022 and the fix should be applied on Oct 2021. So don’t know why this is still happening.

Also from the mentioned post @gchen says:

Restore always preserves the folder structure. The destination folder is treated as another repository, the same way as the source directory.

So the issue pointed in my point 2 is intended to work this way? So no matter if i select a sub dir to restore, the entire directory structure will be restored?

#5

I doubt that would make a difference.

The fix only corrected the permissions on the selected folder and its descendents, not on the “extra” ancestor folders.

Yes. Note that the CLI restore command doesn’t provide a way to specify a destination. It restores to the current directory and expects it to contain a .duplicacy folder and have the same structure as the backed up repository. So when restoring to a different location, the destination (current) directory must look like it’s been initialized with a duplicacy init command, hence the .duplicacy and ancestor folders.

2 Likes
#6

So in my case I selected the /config subdir to be restored and the permissions are correct because of that fix. Instead the /qbittorrent main directory still has some kind of bug?

#7

I can understand the creation of .duplicacy on restore, but still can’t grasp why the entire directory structure should be maintained.

#8

Yes. The permissions on the ancestor directories are incorrect when restoring a repository subdirectory to a different location.

1 Like
#9

I presume because it’s technically easier to implement.

1 Like
#10

Hi @gchen if you have not already, could you please have a look at this issue?

Thanks!

#11

This is because qbittorrent wasn’t included in the directories to be restored. If you add this directory as the restore option (-- qbittorrent/) then the permission should be restored correctly.

It was a design decision to preserve the directory structure. This does lead to simpler implementation and can be convenient when, say, you need to restore two directories in different locations.

This does seem redundant. I’ll fix it in the next release.

1 Like
#12

Thank you!

You mean to add that exact string in the restore Options when restoring from Web Edition?