Duplicacy vs Apple Time Machine

I have been on Windows all my life but now I’m starting to explore the world of MacOS. One amazing aspect of the Apple world seems to be Time Machine.

It appears that if I had been on MacOS some years back, TM would have saved me countless hours of looking for a backup solution, finding crash plan, being annoyed with its resource use but not finding an alternative, then being forced to find an alternative due to its closing down and trying different solutions for about two years before finally finding duplicacy.

I suppose that Time Machine also had its hiccups but anyway: I’m happy with duplicacy and I guess I’ll continue using it because it allows me to use one storage across all my Win, Linux, and Mac devices. But here’s my question: apart from just that cross-platform thing, what are the benefits of duplicacy over TM? And, likewise, what are the advantages of TM? Should I use TM in addition to duplicacy?

You know I also came from crashplan, where I was a user for many years. When crashplan closed personal access, what bothered me the most was: ok, what about all those backups? And if I need a file from a year ago? The backups were “stuck” in a proprietary closed-source format, which I couldn’t even migrate out of the crashplan structure.

I chose Duplicacy for the robustness of the design, for being open source, and also for having an open format, which I store wherever I want, and if tomorrow I want to change the location of my storages (as I already did, from Wasabi to B2 ), I just copy the files.

And every day it surprises me with its speed … :yum:

Ok, TM is from Apple, “a little” bigger than crashplan, but if tomorrow you migrate to Linux or back to Windows…

1 Like

I use both Time Machine and Duplicacy personally. I consider Duplicacy to be my second line of defence for my MacBook, but it’s my first line of defence for my NAS drives, which Time Machine won’t back up.

Time machine is also my “local” backup, while Duplicacy is my “offsite” cloud backup.


I haven’t really started to dig into TM (counter to my expectations, I have a pile of issues to deal with before I can really start using my Mac. Dunno where that “Apple just works” mantra came from) but it is ny understanding that I can create a time capsule just about anywhere (intend to do so on my NAS), so it’s not quite as dependent on its mothership as Crashplan. It’s not open source, of course, but what’s more future proof: a time capsule on my NAS or a duplicacy storage on B2?

Can I interpret this as: Time Machine is easier to use for restoring the odd deleted file here and there?

1 Like

None of them, but a 3-2-1 backup strategy. In my case, a local storage and B2. And, thanks to Duplicacy, both use the same architecture.

This is the main missing feature of Duplicacy (directly view / select files on storage ), already mentioned several times here.

In my case, the files in use are synchronized with Google Drive, so if I need a recent version of a file I use the available functionality of GDrive.

For me it’s more to have a backup that can be used to fully restore the system if needed (Time Machine can be used to restore at boot natively by holding Command+R).

I rarely need to restore anything on my MacBook, but doing so from Time Machine is pretty convenient (especially if it’s a large file since it would be “local” for my use case).


Almost. Time machine relies heavily on filesystem support for attributes and hard links and while on DAS drives it’s easily achievable by formatting the volume with the supported filesystem witH NAS this is not the case — network access protocols simply don’t support all the complexity. To solve this time machine creates a disk image — sparse bundle — on the target and mounts it over network. Now it got local disk it can format and use as needed.

Hovever this being network mounted filesystem brings reliability challenges when network connection is flaky. To guarantee data integrity Time Machines requires support of certain SMB features form the host. When you first browse the SMB share macOS tests those features and places “time machine supported” hidden file (to avoid testing again).

You can of course trick the time machine to backup to literally anywhere — by manually creating a bundle, mounting it, and forcing tm to use it with tmutil setdestination — but that would be asking for trouble.

Furthermore, it’s highly desirable for time machine to be located on reliable storage. Time machine checks integrity periodically and of bundle is corrupted it will say so and ask you to start backup over.

You can mitigate this by making periodic snapshots of the network share time machine bundle resides on to revert back to uncorrupted version — but having reliable storage to begin with is of course better. So, consider btrfs or zfs.

And I agree with the above comment — time machine is great for fast local restores and system migrations. But with time machine your data competes for space with system data and this is not a good thing. Hence, I too complement time machine with duplicacy that only picks up user data and keeps forever version history in the cloud.

I used to use Synology devices to host a copy of a backup on-site but got rid of them recently in favor or 100% cloud storage (rclone mount with cache for general data and duplicacy with service account to google workspace into separate appdata folder. Hope the PR that facilitates that will be checked in eventually because maintaining my own branch of duplicacy is not ideal).


Wow, thanks for the elaborate explanation. I think I’m on the right path so far. I have a shared samba share on my Openmediavault NAS for which I turned “Support for Apple Time Machine” (or something like that) on. Haven’t tried it yet, but is sounds like it should work. Oh, and my NAS storage is using zfs, so even that box is checked. :sunglasses:


One quick point about non-Apple Time Machine destinations. Another thing you can do if your storage or NAS isn’t fully TM compatible is create an HFS+ sparsebundle on the storage and point Time Machine to that. An HFS+ sparsebundle supports all the symlinks, permissions, and attributes that Time Machine needs.

Time Machine is my primary backup, and likely always will be. It’s easy – you can effortlessly scroll through the versioning for individual files.

More importantly, is that for “Apple’s” apps, Time Machine elevates from a simple file based backup and is integrated into the UI. Recovering a deleted Photos photo (or Aperture photo RIP) from a file based backup is a pain. But with Time Machine, it just pops right back into place and Time Machine / Photos handles the database edits required.

Time Machine has zero deduplication outside of APFS native file clones though.

I.e., I have a 10TB external with a number of different versions of a 1TB photo library on it and a 1.5TB Final Cut Pro Library. There’s an archaic Aperture Library, a Photos Library, Lightroom Classic Library, and card clones from my individual SD cards before import.

Time Machine uses a full 10TB for that drive, but Duplicacy did it in 4TB. That’s because most of the libraries and folders contained the same originals. That’s a huge boon to Duplicacy.

I see no reason not to run both Duplicacy and Time Machine. Duplicacy also gives you the comfort of periodic hash checks to protect against bit rot that Time Machine does not have.

I’ve restored from my Time Machine backups probably 15-20 times in the last couple years. I’ve never restored from Duplicacy, but that’s because of the ease of access. I take comfort in knowing that Duplicacy safely uploaded a copy to Backblaze, as well as created a cold offsite backup on a 3.5" external, and a copy in my local OMV server for me.