Duplicacy vs Apple Time Machine

Support
#1

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?

#2

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
#3

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.

3 Likes
#4

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
#5

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.

#6

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).

2 Likes
#7

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).

2 Likes
#8

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:

2 Likes
#9

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.

3 Likes
#10

Just a quick follow up on this. I have been using TimeMachine for a couple of weeks now and by “using” I mean: turned it on and forgot about it. It was just doing its job. But now, it suddenly started complaining about not having enough space even though it was also saying that it will start deleting the oldest backup once it runs out of space.

Anyway, I went ahead and gave it another 300 GB because I thought that was the easiest way to solve the situation for the time being. So I logged into my NAS (OpenMediaVault) and increased the size of the samba share that I had created for the Time Machine alone. Well, actually, I didn’t increase the share, cause I’m not working with quotas but I increased the zfs file system where this share was living. And it worked. At least I could see the extra space when accessing the share via Finder.

But TimeMachine kept complaining about lack of space. I tried reselecting the volume to which time machine should backup but it complained that it was already in use. I tried rebooting the Mac but to no avail. I then tried disabling and re-enabling the SMB share. Now I was able to select the volume, but it ignored the existing sparsebundle and created a new one. I wanted to copy the old sparsebundle over to my desktop to try and repair it but it says I don’t have permission to access it. So I guess I’m just going to throw it away and start from scratch, hoping that it will make better use of the space it has this time.

I’m posting this here just to show that there is a point in using duplicacy on the Mac and that TimeMachine does seem to have quite some flaws. (When I started to google for the problems I was seeing, I was overwhelmed with hits so that I didn’t even know where to start. These access and corruption problems seem to be very common when backing up to SMB shares.

#11

3 posts were split to a new topic: Handling Apple Time Machine Sparsebundles

#12

If you search anything one the internet you will find tons of horror stories; happy users rarely post “today nothing happened either”. To counterweigh your findings I can say that I have been using time machine for over decade and never had issues caused by time machine. All the issues people complain about are self-inflicted. There are total of two:

  • using unsupported SMB share, or on a flaky server that advertises support of certain features (like SMB durable handle) but does not actually support them. Time machine checks for the features and would refuse to use the share if those are missing, but some people go as far as mounting unsupported share manually anyway and fooling time machine to use the mounted bundle as if it was local drive. Then they lose data inevitably but it is of course time machine fault. They rarely mention that first bit in their verbose complaint on the forums.
  • using unreliable storage that can rot (e.g. usb hard drives bought on sale in Walmart from the bin. But hey, it’s a hard drive and its cheap)

Othewise its solid. My bunde started over 9 years ago and survived migration from time capsule, to Thecus NAS, to Synology NAS, to another Synology NAS, and back to USB SSD. and supported over 8 migrations to new hardware almost every year. Not once it failed or complained about corruption. Yes, I have seen failure to restore from time machine when Synology broke SMB (it works over AFP), and I saw AFP server dropping connection mid restore (when Synology broke AFP) but never did it get corrupted, or failed in any other way.

It’s awesome. IN fact, I wish duplicacy had the same UI, behavior, and performance as Time Machine does (both in terms of CLI and the graphical). TM is my favourite backup tool by far and an absolute benchmark of how backup tool shall behave. Out of sight, not eating up resources (we still need built in CPU throttling in dupicacy!!) and rock solid.

The rest of your gripes we’re addressing here :slight_smile:

2 Likes