Restore specific folder including subtree - pattern with /* does not work

There is something strange with pattern matching on macos.

I have the following structure:
and want to restore folder2 together with file2.

I create an empty folder to restore the substructure and init the backup.

mkdir root_restore
cd root_restore
duplicacy init ...

duplicacy restore -r 1 folder2/* This does not restore the files, error: “no matches found: 1/*”
duplicacy restore -r 1 folder2\* With backslash it works.

Why do I receive an error with the normal slash “/”.

Works fine (version 2.7.2 (175ADB)), macOS

/tmp % mkdir root
/tmp % cd root
root % mkdir folder1 folder2
root % echo hi > folder1/file1
root % echo hi > folder2/file2
root % mkdir /tmp/target
root % duplicacy init test /tmp/target
/tmp/root will be backed up to /tmp/target with id test
root % duplicacy backup
Storage set to /tmp/target
No previous backup found
Indexing /tmp/root
Parsing filter file /tmp/root/.duplicacy/filters
Loaded 0 include/exclude pattern(s)
Packed folder1/file1 (3)
Packed folder2/file2 (3)
Backup for /tmp/root at revision 1 completed
root % rm -rf folder1 folder2
root % ls
root % duplicacy restore -r 1 'folder2/*'
Storage set to /tmp/target
Loaded 1 include/exclude pattern(s)
Parsing filter file /tmp/root/.duplicacy/filters
Loaded 0 include/exclude pattern(s)
Restoring /tmp/root to revision 1
Downloaded folder2/file2 (3)
Restored /tmp/root to revision 1
Total running time: 00:00:01
root % find . -regex "^\./[^.].*"
root %

It is a good habit to enclose string in single quotes so that your shell does not try to expand. This is likely your issue here. Change

duplicacy restore -r 1 folder2/*


duplicacy restore -r 1 'folder2/*'

You have escaped * with a backslash and ended up passing folder2* to duplicacy, which is a valid pattern (star matches everything, including path separator)

Thanks for the quick response.
Oops!, I installed duplicacy via brew install duplicacy . Looks like it installed an old version (2.1.2). I did not compare the installed version number with the latest release of the cli version.

How to install the latest version on my mac? Is the another (easy) way other than to build from source?

Command Line Version

The command line version serves as the engine to perform all operations for the GUI versions. It can also be invoked directly from the command line or from a script. It is free for personal use, while commercial use requires a CLI license.

The command line version can be downloaded from our github repository.

root % brew info duplicacy
duplicacy: 2.1.2

==> Caveats
duplicacy has been officially discontinued upstream.
It may stop working correctly (or at all) in recent versions of macOS.

IIRC it is not published to the public repositories on purpose. I forgot why though :slight_smile:

You might also find this useful: Configuring duplicacy CLI on macOS with SIP enabled | Trinkets, Odds, and Ends

1 Like

Thank you for the link to the shell script. I was not aware about the difficulties to access specific folders on macos.
I played around with duplicacy all day. But the described solution with the app bundled sound very complicated. Not sure if this will work for me. Sounds like to many moving parts for a robust backup solution that has to work reliably in the years to come.
Is it realistic to wait for a simpler solution for macos users to use duplicacy? :slight_smile:

That scripting around is only needed if you want to run CLI version. (FWIW I’m using it myself, and it’s rock solid for year. I wrote that script for myself actually to simplify setup and throttle. You can do all that manually if you want).

You can use native GUI wrapper — Duplicacy Web — instead.

If you want to run Duplicacy Web to run under launchd and backup All Users on macOS with SIP enabled — you’ll want to read this: Spurious Duplicacy-web launches for example launchd plist and requisite command line arguments.

How do other tools like for example rclone handle the described difficulties on macos? Should be similar challenges for similar tools.

Rclone is not similar to duplicacy or any other backup tool. But otherwise you are right, this is not specific to duplicacy; it had to do with it being a CLI executable.

Other CLI backup tools do nothing about it eithet, nor can they: it is not possible to give naked executables access to sensitive user data location.

The only way to handle it is to wrap the CLI tool into app bundle (by creating native GUI, with Automator, or platypus). App bundle can be granted that access.