Does not restore all marked files when all-versions is on

[df46478]

Duplicati - 2.0.4.38_canary_2019-12-29

Settings:
• Backup retention: on
• Advanced options. all-versions: on
Bug:

1. Backup folder with 1 file.
2. Delete that file.
3. Copy any other file to the same folder.
4. Backup the same folder again.
5. Delete the second file.
6. When you try to restore 2 of these files at once, only the last one is restored, although both are marked for recovery.

“[Warning-Duplicati.Library.Main.Operation.RestoreHandler-MetadataWriteFailed]: Failed to apply metadata to file: “E:\aa”, message: The process cannot access the file ‘E:\aa’ because it is being used by another process.”

[drwtsn32]

@df46478

When you try to restore 2 of these files at once, only the last one is restored, although both are marked for recovery.

How are you doing that? In your scenario it seems that file A exists in one backup snapshot and file B exists in a separate one. Duplicati requires you to pick a backup snapshot and then pick from the files contained within - you cannot submit a backup job that lets you pick files from different backup snapshots.

@df46478

“[Warning-Duplicati.Library.Main.Operation.RestoreHandler-MetadataWriteFailed]: Failed to apply metadata to file: “E:\aa”, message: The process cannot access the file ‘E:\aa’ because it is being used by another process.”

If you have E:\aa folder open in Explorer or elsewhere, it can cause this error message. From what I’ve seen it means only the metadata on that folder wasn’t restored. Actual data should have been restored though.

[df46478]

@drwtsn32

How are you doing that? In your scenario it seems that file A exists in one backup snapshot and file B exists in a separate one. Duplicati requires you to pick a backup snapshot and then pick from the files contained within - you cannot submit a backup job that lets you pick files from different backup snapshots.

Yes, each file is obtained in a separate snapshot. But then this setting and the possibility of selecting all the files from all previous snapshots at once is misleading.

[drwtsn32]

Interesting, thanks for the clarification. I’ve never tested that scenario. I’ll give it a try when I get some time.

[ts678]

A Google search for “all-versions” at site:duplicati.readthedocs.io supports my hunch, which is that “search” means the FIND command, which is how one searches. You can try that at Commandline.

“Use this option to show all previous versions too” text suggests a find, which is also called list.

The RESTORE command also has a syntax which seems to say multi-version restore isn’t allowed:

--version=<int>
Restore files from a specific backup.

https://github.com/duplicati/duplicati/blob/master/Duplicati/Library/Main/Operation/ListFilesHandler.cs
looks like the only place AllVersions is used, so I don’t think it affects Restore, however I’m less sure whether Restore from command line can be persuaded to do multiple versions using a –version list… Such a request could be problematic. Which version wins if a file is in several (unlike in original post)?

https://duplicati.readthedocs.io/en/latest/04-using-duplicati-from-the-command-line/
shows commands where --version is specifically said to do multiple versions. Restore is the opposite, which means my guess is that you won’t be able to persuade it otherwise. You could certainly test it…

[xblitz]

mmh… I never try a multiple-version restore and I don’t know if it’s possible too but when one try to restore a file duplicati ask what it should do in case exist a file whit same name yet: overwrite file or add a timestamp in the name…

[df46478]

I use duplicati so far only through the web interface. The function to recover all files from different snapshots at the same time does not seem to work. So this is a bug. Hope to fix it.

[Christians]

Concerning the CLI: While I can FIND several versions of a file with --version1,2,3, I cannot RESTORE these versions in one go, only the first one of my versions is restored. Is this expected behaviour?

I want to restore several versions in one go and then compare them. When I individually restore them it works: I get a time stamp at the end, which is great.

2.0.5.1_beta_2020-01-18

[ts678]

@Christians

Is this expected behaviour?

According to earlier documentation clues, this only works with the find command.
That makes two people (including you) who confirm that restore lacks this ability.

For a small number of versions, doing what you tried seems a workaround for this.
Files that are already as they should be won’t even get downloaded again, but the
dating of file version is available if it’s necessary to have two versions sitting there.

[Teemoe]

I’ve tried this too…
It’s required to compare different files of different times, if i don’t know the right day of a file corruption.

[ts678]

@Teemoe

It’s required to compare different files of different times, if i don’t know the right day of a file corruption.

If file corruption changes file size, you can spot change time with --all-versions and The FIND command:

Running commandline entry
Finished!

            
Listing files and versions:
C:\backup source\short.txt
0	: 1/12/2021 8:06:23 AM 19 bytes
1	: 1/10/2021 5:33:57 PM 11 bytes
2	: 1/10/2021 3:32:56 PM 11 bytes
3	: 1/8/2021 7:53:09 AM 11 bytes
4	: 1/4/2021 3:44:08 PM 11 bytes
5	: 1/3/2021 8:05:40 PM 11 bytes
6	: 1/3/2021 7:29:13 PM 14 bytes
7	: 1/3/2021 7:28:48 PM 14 bytes

Return code: 0

The timestamps here are those of the backup version though (should match what restore offers), not file.

The above result fits especially well with all-versions short description in the options selector, which says

There’s probably no getting away from a manual exam of the files after the time of corruption is narrowed, however this sort of survey seems like it will cut time ranges down to where a few samples can be tested.