License reset for 30-day trial

I would like to try Duplicacy (again) as I was never able to run it properly in my first trial. Unfortunately my computer is listed as having expired for the 30-day trial. Here is the License attribute from my mac’s preferences:

defaults read ~/Library/Preferences/com.acrosync.mac.duplicacy.plist License

7b2245646974696f6e223a22547269616c222c2245787069726174696f6e54696d65223a313531363337343631302c22486f7374223a2276656e7573222c224c6963656e73654944223a2232666165383338373266653031306439366537656461363139303335646635396436316231386566386465353132613039393134323632303632633831343435222c224c6963656e736565223a22222c2252656e657754696d65223a313531363337343631307d0a

I’m a CrashPlan refugee, and have been unhappy with both Arq & Duplicati. I’m hoping to give Duplicacy another shot…

Thanks

What I did in similar situation (and I too ran out of trial time by the time I got disappointed in every single other backup tool) is use open-source and free for personal use CLI version, setup filter list and use it for a few months. Then I realized that not only duplicacy is way better than completion but that I don’t really need a GUI front-end anymore - since I have already periodic backup setup via launchd will all filters debugged and configured.

I went ahead and bought license anyway to support the devs, but that is another story.

Thanks for the heads up. I downloaded and ran the CLI version and now realize my mistake: I was using a path vs. name for the repository! I’m now running my initial backup. Any pointers to developing the launchd scripts would be most appreciated, as I am familiar with creating those (and Unix command line in general). I’m also trying to monitor my progress, but have been unable to find duplicacy CLI log entries. Any help with that would also be appreciated. I’m already impressed with how much less CPU usage is being consumed, compared to Duplicati…

I can describe my setup that works very well for a few months now. I’m backing up to SFTP share with key-based authentication.

My duplicacy repository is my home folder /Users/myusername and hence all configuration and other data duplicacy keeps is in ~/.duplicacy/

All other duplicacy related stuff (including SSH keys, launchd daemon, scripts, etc) I also keep there.

My preferences file looks like so:

    {
        "name": "edited",
        "id": "edited",
        "storage": "sftp://username@server//Root/Path/to/duplicacy/storage",
        "encrypted": true,
        "no_backup": false,
        "no_restore": false,
        "no_save_password": false,
        "keys": {
            "ssh_key_file": "/Users/myusername/.duplicacy/id_rda_duplicacy"
        }
    }
]

I have put launchd plist in the same folder and just made a symlink to it under /Library/LaunchDaemons/

The plist looks like so:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
        <dict>
                <key>Label</key>
                <string>com.edited.duplicacy</string>
                <key>ProgramArguments</key>
                <array>
                        <string>/Users/myusername/.duplicacy/gobackup.sh</string>
                </array>
                <key>LowPriorityIO</key>
                <true/>
                <key>WorkingDirectory</key>
                <string>/Users/myusername</string>

                <key>StandardOutPath</key>
                <string>/tmp/duplicacy.stdout</string>
                <key>StandardErrorPath</key>
                <string>/tmp/duplicacy.stderr</string>

                <key>StartCalendarInterval</key>
                <dict>
                        <key>Hour</key>
                        <integer>0</integer>
                </dict>

                <key>Nice</key>
                <integer>-20</integer>
                <key>ProcessType</key>
                <string>Background</string>
        </dict>
</plist>

You can call duplicacy directly by the launchd, but for experimentation I’ve put all relevant code into .sh file under the same .duplciacy storage and call it from there.

It looks like this for me:

#!/bin/bash

cd /Users/myusername
caffeinate -s nice duplicacy backup

# Retention
# After two weeks keep a version every day
# After 90 days keep a version every week
# After one year keep a version every month
caffeinate -s nice duplicacy prune -keep 31:360 -keep 7:90 -keep 1:14
caffeinate -s nice duplicacy prune

Note, you can safely remove “caffeinate” and “nice” from there - but I left it there for occasions when I run that .sh directly.

Another note - duplicacy is so ridiculously fast that caffeinate is not really needed :slight_smile:

Third note - stdout and stderr as you can see from the plist are redirected to /tmp/duplicacy.*

@MrMole, I’ve reset your trial license and you should be able to restart a new trial for the GUI version. But, if the CLI version works for you then there is no reason to switch to the GUI version (which is just a simple GUI wrapper on top of the CLI vrsion).

@saspus thank you for your support! You may want to submit your scripts to https://github.com/TheBestPessimist/duplicacy-utils.

Thank you both so much! I’ve figured out the logging now, after a bit more careful research, and very much appreciate the launchd-plist+shell-script! I would have done something similar, but this saves me a LOT of time getting started. So far I’ve only had one failure, trying to backup a VMWare image, which may have been due to permission errors… But the smaller CPU-footprint and speed of operation are quite impressive thus far. I’ve seen others comparing Arq & Duplicati vs. Duplicacy and think I’m now on the right track :wink: I’ll give the GUI a shot and will most likely get a licensed version once my testing is complete. I really do appreciate the help…

The following init command is recommended for backing up VMWare images:

duplicacy init -c 1M -max 1M -min 1M -max 1M repository_id storage_url

Setting all 3 chunk size parameters to the same value makes Duplicacy switch to the fixed-size chunking algorithm which works more efficiently with virtual machine images. This is exactly what is being used by Vertical Backup, a special edition of Duplicacy that runs on VMWare ESXi.

I was thinking it had to do with chunk sizes, as I had a failure with a 2GB movie that was quite similar. I’ll incorporate that. Hopefully I won’t have to start over, but perhaps would have to re-init from scratch? I’ve also modified the launchd plist script to run every 3 hours vs. 1/day. In fact, I think the ‘StartCalendarInterval’ may not be exactly right (as I understand the man page for launchd.plist) since it could run every minute of the 0th hour as currently written? Just wanted to mention that (not to look a gift horse in the mouth :wink:

I’ve also modified the launchd plist script to run every 3 hours vs. 1/day.

Good catch - I’ve copied from the wrong plist file apparently, sorry about that. My setup is slightly more complex that that - I have a separate repository for /Users and then each user gets its own repository under his/her ~ as well, all backing up to the same storage.

Per-user ones run once every hour but only for currently logged in user (owner of /dev/console). The one under /Users runs once a day at midnight, to pick up stuff like iCloud photos and mail that got synced for other accounts. Apparently I copied from that other plist and did a lousy job stripping it.

In fact, I think the ‘StartCalendarInterval’ may not be exactly right (as I understand the man page for launchd.plist) since it could run every minute of the 0th hour as currently written?

The way it works is similar to crontab - once the conditions are satisfied the job will run – once. Omitting the arguments (like I did not specify minutes/secods/days) means wildcard/any. So the way I understand it (and this seems to match with what is happening) this job would run when condition (hour=0 && minute=any && day=any && second=any) changes from FALSE to TRUE - i.e. likely at or shortly after midnight.

Hi again. I’m having very good luck with the CLI now. When I went to test the GUI version, however, I received an error about the encryption (for the config file) being the wrong version. How would I work around this:

2018-03-10 14:08:34.881 ERROR STORAGE_CONFIG Failed to download the configuration file from the storage: Failed to retrieve the config file: Unsupported encryption version 1

Does setting up the storage using the CLI ‘init’ command with the ‘-e’ option make it inconsistent with the GUI version?

Any advice most appreciated.

That is because the storage initialized by the CLI 2.0.10 version can’t be read by the GUI 2.0.9 version due to a change in the format of the config file. You can try the GUI 2.1.0 version in this thread: Version 2.1.0 beta is available for testing. If you download the installer from the links in that thread you’ll notice that it doesn’t have the beta tag anymore – it is now the official version and I just haven’t updated the website yet.

Thanks very much! That was indeed the problem. Everything is working very well now, with both the GUI and CLI. Backups and test restores successful. I will especially utilize the cross-computer deduplication feature by backing up several of my machines, which contain duplicates, to the same storage. Excellent!