AFP Support Disappearing: Another Nail in the Time Capsule Coffin

How does that work if there are two or more targets for Time Machine? (In other words, if I have two or more drives that I have set up for Time Machine backups, do the local backups get copied to the first one that Time Machine sees? Or does Time Machine, realizing there are multiple drives, save the snapshots to copy to each target?)

I am still using a Time Capsule, for three things. I use it as a Time Machine target for multiple Macs, I have a printer connected to its ethernet so two Macs can print, and I use it as shared storage for some files that I want each Mac to be able to access. (The files are on an external disk attached to the Time Capsule’s USB port.)

Each Mac already has an SSD as a Time Machine target (and one Mac has a spinning disk as a target, also). The printer access could be through an ethernet switch that I have had for many years. But the shared files are a minor concern.

I’ve never set up or used file sharing on a Mac. If that is the simplest solution, then this might be the impetus that changes that situation.

I’m using my old Time Capsule for daily CCC backups and it works well for that. It stopped working well for Time Machine backups quite a while ago - the computer would retain all those local backups. It also is acting as an ethernet hub with a printer connection.

No idea, but I would guess that they’d be copied to the first backup drive it sees.

That could work—set one Mac as the default storage location. Or just put the shared files in iCloud Drive or Dropbox or the like, if there aren’t too many.

The problem with Time Capsules despite their age (and the impending AFP deprecation) is that they’re so damn useful and they work even now 7 years(?) since the last one one was sold.

If you have one it’s definitely time to find a new solution but the simple solutions aren’t there. What’s with this technical progress thingie? Yes, repurpose an old Mac and use file sharing; yes, use an NAS but, er, there might be problems; yes, use the cloud but when you have 2TB of files and live in the middle of Montana on a slow DSL—um, really?

The problem for us all is that Time Capsules were a really elegant solution, easily managed, that handled a surprising number of use cases. There simply is no available alternative that matches their simplicity and sturdiness.

So much for progress.

Dave

Linksys Velop wi-fi routers have a usb port for sharing a connected drive via SMB. Very similar, but not as elegant, to Time Capsule functionally.

I keep my TimeCapsule plugged into my Bell modem/router as during larger file transfers over the LAN, the Bell will shut down and restart (and oh so slowly), whereas if I connect my Macs to the TC it handles large files with aplomb. I have, somewhere, three of the older flat TimeCapsules (pre-802.11n) and if this one ever fails, the first thing I’ll do will be to use one of those. The rate-limiting factor in internet speed is my (supposed) 50Mbps Bell cellular connection, not the wi-fi networking protocol. I gave up using them for TimeMachine as the backups quickly become corrupted and fail.

I agree. I have a second generation TC that had been powered on almost continuously since I bought it in 2009, but its power supply finally died about a month ago. I had disabled its wireless functions and used it via Ethernet as a print server for a USB-only printer and for very temporary storage of non-critical files.

For people who won’t be upgrading to macOS 16, I think a TC remains a reasonable backup solution, especially if the backup target is an external drive, but I’d be hesitant about using its internal drive or its wireless features, even if it is one of the final models.

Aside from general ease of use, I think the only real use case where AirPorts and Time Capsules are superior to most alternatives in 2025 is a rapidly diminishing one: as wired network print servers for USB-only printers.

It used to be pretty common for consumer routers to include print server functionality, but I’m not even sure if any current consumer routers still do, at least out of the box. AIs say that Netgear and TP-Link do, but I know that Netgear dropped support a couple of years ago, going so far as to remove it via a firmware upgrade from routers that previously supported it, and I can’t be bothered to look up the answer for TP-Link. AirPorts and TCs “just work” as USB print servers. Factoring in power consumption, a late model AirPort Express makes an excellent wired print server.

1. Many printers have built-in network connectivity. I can connect my Canon printer to my network either via Wi-Fi or Ethernet cable (the way I do it). In fact, the printer’s default setup is via a network connection.

2. My ASUS WiFi router has a USB port that can be used for a printer or an external disk drive. If a disk drive is attached, one option is to use the connected drive as a TM drive.

When I migrated from my Time Capsule a few years back, I found that my new Linksys router had an external USB port so I could connect an external drive. It uses the SMB protocol, but does not support APFS formatted disks, only HPFS. So if I try to use it as a Time Machine drive it fails, Sequoia does format any external hard drive for Time Machine as APFS only, not HPFS. That is why I ended up having an external hard drive connected directly to my MBP for Time Machine backups.

When printers have built-in networking, that almost always is the best choice for connectivity. The use case I raised was for printers that do not have built-in networking (or that may be otherwise unsuitable for direct networking, e.g. printers that have known networking vulnerabilities).

Thanks for sharing that. That’s very useful information! I see that the Asus models that support print services do so through LPR/LPD, so Macs can use those services without installing third party client software. Back when Netgear still supported shared printers, it required installation of the Netgear “ReadyShare” print app. My next router may be an Asus model.

Drat. I just checked my router, and it’s similar.

If you use a USB hard drive, make sure its file system is FAT32, exFat, NTFS or HFS+.

Thanks for the heads-up.

I’m surprised that matters. I thought TM, when saving to network volumes, creates APFS-formatted sparse-bundle disk image files, which should work equivalently no matter how the remote volume is formatted.

If you can’t use that device as a TM destination, I would assume that’s because it is a generic SMB network volume (without whatever magic Apple specifies should be used for networked TM), not because of how the volume is formatted.

If you require network-based TM, then you’re going to need something that supports Apple’s proprietary extensions. Either a NAS that explicitly supports TM or an always-on Mac, where you can share a volume (like a USB-connected storage device) to your LAN as a TM destination.

@Shamino is correct.

For networked Time Machine backups, recent versions of macOS create a virtual APFS filesystem within a “sparse bundle” file, though HFS+ may be used in a sparse bundle from an older source volume. The drive itself does not have to be formatted to either APFS or HFS+ for networked backups.

This is why you can run networked Time Machine backups to network attached storage (NAS) devices that use non-Apple drive formats, like exFAT, ZFS, or others.

The key thing is that the server/router supports whatever other Apple magic is required for Time Machine.

I have various Macs using local, Time Capsule and Synology NAS for Time Machine. I guess they have a range of file systems depending on how long ago they were set up.

My only issue with the NAS is that I have to manually mount it for Time Machine to work (but that may be my lack of technical skills).

From the previous two comments above it seems that the discontinuation of AFP will not affect those backups. The only requirement is that the server is compatible with Time Machine. Is this the concensus?

It’s a little more complicated than that. It will be useful to keep in mind several items:

• APFS is Apple’s native format for modern filesystems.
• AFP is the Apple Filing Protocol, which is a networking protocol. Apple will drop support for AFP in an undisclosed future version of macOS.
• SMB is an independent networking protocol that Apple has been encouraging people to use instead of AFP.

Next:

• Time Machine can be run over a network using AFP.
• Time Machine can be run over a network using a specific version of SMB (version 3) if the network backup device supports certain additional requirements and SMB extensions.

When Apple drops support for AFP in a future version of macOS (let’s call it macOSfuture), any Mac running macOSfuture will be unable to use Time Machine over AFP. Macs running older versions of macOS will continue to be able to use Time Machine over AFP.

In your case:

• Local backups should continue working, since neither AFP nor SMB are involved.
• Any Mac you upgrade to macOSfuture will not be able to use your Time Capsule, since your Time Capsule uses AFP for Time Machine and is limited to SMB version 1. Macs running older versions of macOS will continue to work with your Time Capsule.
• If your Synology device is still supported by Synology, it probably supports (or will support) SMB version 3 with the Time Machine extensions. It most likely will work with macOSfuture machines as well as current machines, but you’ll want to check with Synology and make sure you are running the latest version of Synology software/firmware to be sure.

I’m a long-time TidBITS reader, from the late 90s or so. I started reading just before switching to use Debian Linux(!) but have kept reading since Adam’s commentary is always interesting, and most of my family use Macs. It’s my first time posting here, hence the prologue.

I tried to use a 2014 Mac Mini upgraded with an nvme drive to run as a family Time Machine server but suffered issues with either AFP or APFS (Apple File System) volumes causing corruption.

Wary of corruption and the fact that the 2014 Mac was mothballed at macOS 12 I installed Debian on it and reformatted the generous nvme drive as a btrfs volume. It was very easy to get this running samba (the open source SMB/CIFS file server) with Time Machine support.

The Time Machine backups have been running for over 4 months without a hitch. In addition to that, btrfs (apart from bitrot protection) gives snapshot support. Although it might seem incongrouus to take snapshots of an APFS volume which itself has Time Machine snapshots within it, it allows roll-back to an earlier version of a Time Machine volume if needed. (I’m wary of corruption re-occurring). And while the btrfs snapshots may not be sharing data between them as efficiently as APFS volumes themselves, these still perform pretty well. For example, these weekly snapshots, on a system with a lot of churn, show the following:

btrfs fi du -s *
     Total   Exclusive  Set shared  Filename
 ...
 351.41GiB   394.34MiB   350.97GiB  20250510-timemachine
 362.40GiB   241.36MiB   362.10GiB  20250517-timemachine
 372.74GiB   299.67MiB   372.37GiB  20250524-timemachine

The exclusive data shown for each snapshot is typically well under 400MB.

Enthused by this low-cost solution, I’m trying an even lower-cost approach for a “travelling server”. This is a Mele Quieter 4C box with a 2TB nvme disk, about the size of a large, boxy phone. This gadget has an Intel 4 core N100 CPU, 8GB RAM and 128GB eMMC onboard storage, is pretty robust and well-made, and are apparently often used in industrial settings. In the UK the total cost of the box and drive was about £250.

I make sure that there are always three copies of our data, so I don’t mind having just a single nvme drive in a backup device. The benefit is you can grab that nvme stick and put it into just about any reasonably modern Linux machine or USB stick reader and simply mount it.

Sorry for the long explanation, but since Adam asked for alternatives, I thought I’d mention this approach.

p.s. I don’t do this but it should be a snap to serve printer sharing from any Debian box using CUPS.

However enabling Time Machine support in the Asus software (or the Merlin one) supports Time Machine only over AFP so when Apple stops supporting AFP entirely this solution will also stop working.

It is possible to use Time Machine over SMB with a disk attached to an Asus router, but currently this is not simple (and not entirely reliable in my experience). I asked about it and found some ways to do it at Time machine support when AFP is removed from macOS? | SNBForums

It works fine, however while reconnecting the SMB share is reliable, re-opening the sparse bundle is not. Not yet sure how to get that reliable so the whole thing can just work.

To clarify when I say not entirely reliable I mean specifically the automation with the re-opening of the sparse bundle. Otherwise everything else is reliable.

My ASUS WiFi router has a USB port that can be used for a printer or an external disk drive. If a disk drive is attached, one option is to use the connected drive as a TM drive.

I tried to get that working oh-so-many times. I finally gave up. Reliability is an issue, and without knowing the backup is being made successfully or that it can be retrieved successfully (this a long-standing problem I’ve had with Time Machine), then Time Machine is of little value.

Now I have a Chronosync job that copies necessary files to a plain ol’ drive hooked up to that port my ASUS router. It works quickly and successfully. I’m still tweaking the Chronosync settings to make it run at intervals when my Mac is running but that’s not a high-priority project for me.

Interesting to see that you are using Merlin on your Asus router.

As the SMB deprecation conversation has been developing, I have been wondering about the state of support for Time Machine over SMB on consumer routers using alternative firmware, e.g., OpenWRT.

Personally, my backup needs are already covered, but some technically inclined TidBITters might find the approach worth investigating.

In the thread I created on SNB linked previously, some responses mention other threads there in which others are looking at running SMB v4 and other changes that could be make it easier for an end user to run Time Machine in such a configuration. I hope that if these experimentations are successful, then Merlin will include them. I’m less familiar with other alternative firmware, but indeed if one manages to get it to a state where Time Machine can add the share in its GUI, hopefully they’ll share the work.

I thought i was being clever and did a ssh 'btrfs send <btrfs_snapshot>' | btrfs receive <btrfs_snapshot> between my two family network TimeMachine servers running LInux as described above, so that I could seed backups on the portable server.

There were no problems with the new portable server serving the btrfs snapshot (re-snapshotted to be rw) and Time Machine on the client recognised the snapshot and offered to inherit it. But for some reason, for the new server, the client won’t pass verification or allow backups to start.

The worrying thing for me isn’t that there is a problem per se, but that I can’t easily work out where the issue is. The TimeMachine “option click” choice of Verify doesn’t report any logs on failure. And after googling about this for some time, I’m not confident that fsck_apfs can reliably fix an APFS sparseimage over the network. Since TM is running fine to the source of the clone, I know there is almost certainly something wrong in the image or local metadata; I just can’t find it.

There are 6 serious issues with networked APFS volumes listed at the Electric Light Company’s " How should you check an APFS backup store?", not to mention the article from the same source " Time Machine to APFS: When a network backup goes wrong.

I was delighted with my btrfs snapshots of APFS TM network backups being so lean and thought this would be a brilliant way of hedging against another APFS sparseimage corruption. However, if I can’t recover from these snapshots there is no point. And looking around, tools for recovering APFS network volumes don’t seem very good.

I’m wondering now if a home-grown rsync solution is the way to go. I believe that is what Carbon Copy Cloner uses. With rsync checksumming and btrfs snapshots I know i can retrieve the data, and easily sync the backups themselves between servers. Retrieval would certainly be more painful for family members though.

I’d be grateful for any comments on the reliability of APFS TM volumes and/or thoughts on the suitability of rsync, at least for file backups rather than system restores.

I used rsync to back up the Linux servers I maintained, and could re-create complete systems with just those backups, though it required a certain amount of esoteric knowledge. I never had a problem and I had a high degree of confidence that I could recover from any filesystem-related horrors.

I was happy enough with it that I used a similar script to back up my macOS system that I used along side Time Machine, CCC, and SuperDuper backups (yeah, I’m that guy). In all my many years using post-OS9 Macs, I never once had to do a full system restore, but I did feel that I had a system secure against file data loss. I had few incidents where TM would, out of the blue, present an error like “unable to use this backup: erase this disk and start over” which really decreased my confidence in TM. I also, several times, went looking for a lost file on TM only to discover that it was one of the many types/locations of files that TM apparently does not back up. OTOH, I never needed a file that wasn’t available in my rsync or CCC or SuperDuper backups.

Thanks for your response @ron. Yeah, I’ve been responsible for backing up 10s of Linux servers and 100s of TBs of data with rsync. We used to use hardlink copies for snapshots. Using snapshotting filesystems on the rsync target, like btrfs or zfs, makes things much easier these days.

I’ve compared backing up my linux machine with rsync to a family member’s experience with time machine. Both machines have the same ~400GB of data and roughly the same amount of weekly data churn. rsync + btrfs snapshot is about 3 times faster backing up to the same nvme external drives. My snapshots are to btrfs on luks encrypted drives too, so it’s not the encryption making it slow. I’m surprised Time Machine is considered fit for purpose.

It would be good to know if you still using rsync to backup your Mac. If you are instead using CCC, is that because of its capability of restoring a whole machine?

I’m editing this to add that I’ve just discovered that rsync has been replaced in Sequoia 15.4 with openrsync, a BSD licenced variant with only a subset of rsync’s features.

A year or so ago, disturbed by a number of the goings on at Apple, I decided to try putting my money where my open-source mouth is and switched to Linux as my daily driver. Up until then, I was still backing up with rsync and Carbon Copy Cloner.

The problem for us all is that Time Capsules were a really elegant solution, easily managed, that handled a surprising number of use cases. There simply is no available alternative that matches their simplicity and sturdiness.

I guess something ike TrueNAS with ZFS snapshots and TimeMachine support might be a good solution. Perhaps TidBITS could recommend a setup?! But my worry, based on my discoveries noted here, is how robust APFS sparse image files are for network backup. That wouldn’t be such an issue if block or extent based snapshotting solved an APFS corruption issue but my experience suggests otherwise (see below).

After reading this article, I ordered a USB3 case and connected it to my Asus ZenWiFi XT8 router along with a 3Tb HDD I had lying around from a long-dormant 2010 Mac Pro. I formatted the drive as HFS within the Asus web interface. Then, also within the Asus web interface, I turned on Time Machine. I went back to my Mac, opened up the Time Machine preference pane, and when I added a new drive it was able to see the newly formatted HDD connected to my router. It looks like it will take around 4 hours for the initial backup. I don’t know for sure if it’s using SMB instead of AFS, but I imagine it’s likely to be SMB. I suppose I’ll find out for sure once they completely remove AFS support from Mac OS X. I’ve still got a Time Capsule (with a somewhat recently updated HDD inside), and I’m still backing up to that as well. But it’s nice to now have a second alternative up and running for when the time comes that OS X can’t use the Time Capsule anymore.

I don’t know if your router can be configured to use AFP instead of SMB, but since Apple has been discouraging AFP for awhile, my guess is that it is using SMB only. If you’re interested, you should be able to figure out if your router is running AFP by using a Bonjour-capable network analysis tool.

A good one to try is Discovery - DNS-SD Browser, available for MacOS and iOS. If you launch it, it will scan your local network for Bonjour services. Time Machine requires that AFP and/or SMB “advertise” themselves via Bonjour.

You’ll almost certainly see an entry for “_smb._tcp.” or similar for your router, indicating that SMB services are active. If your router is also running AFP, you should see something like “_afpovertcp._tcp.” associated with your router’s address. My guess is that only the SMB entry will be there.

The Time Machine support of Asus routers (currently) uses AFP. You can know for sure by looking at the System Log, you will see mentions of AFP there.

I realise this discussion thread is really about Time Capsule and the imminent loss of AFP network protocol support. As noted previously I’m a Linux user trying to support Macs for the most demanding of users: family members. My note here is about the use of APFS (previously HFS) sparseimages by TimeMachine, and whether that is a suitable format for backup. Excuse the further somewhat off-topic post.

My approach has been to develop a secure network backup for Mac users in my family using reliable and well-know software such as Samba (which has SMB 3 support) and rsync file synchronisation, using the smb shares as a TimeMachine target. A key point of the design has been to mitigate APFS sparseimages created by TimeMachine becoming corrupted and trying to work around that by snapshotting APFS sparseimages.

My tests (which are perhaps flawed) show that I can’t restore a snapshotted APFS sparseimage after cloning it using btrfs snapshots or rsync (with the extended attributes flag). TimeMachine is unable to complete the verification of the snapshots used in my tests. The Mac hdiutil tool fails to attach or verify the networked image, making it impossible to repair with fsck_apfs. This may be because of some basic problem in how I’ve setup things, of course.

However the Eclectic Light Company’s post on sparse bundles suggests some fundamental flaws with APFS sparseimages that are likely to make them unsuitable for backup, with the author concluding:

Despite their widespread use and advantages, macOS features supporting the use of APFS-format sparse bundles are at present riddled with bugs (I count 6 above) and have serious shortcomings. Their inability to self-compact is a major failing which makes their use clumsy at best, and Disk Utility’s lack of support for basic maintenance functions through the last 2.5 years reflects badly on Apple’s engineering priorities. Disk Utility remains of early beta-test quality and far from complete.

Unless things have changed since that post in 2020, perhaps Mac users should shy away from TimeMachine (for at least data if not system backup) and consider other tools such as rclone or Carbon Copy Cloner instead.

Ivan here, author of the original 2020 article trying to come up with a good Time Machine replacement. I’ve been meaning to pitch Adam on an updated version of that article, since, unsuprisingly, some bits are out of date. But, I’m not exactly sure what it would say, since my conclusion on modern macOS is to avoid Time Machine over Wi-Fi, always.

The following conclusion is what I’ve landed on regarding Time Machine backups over Wi-Fi, with or without Time Capsule: their existence inside an APFS bundle makes them not as reliable as a backup needs to be; and adds a layer of abstraction I don’t want.

So, don’t use Time Machine over Wi-Fi on any device. Instead, use a network copying app, and a backup host with a snapshotting file system. An example (not saying best choice, just an example) would be using a Synology NAS formatted with Btrfs, and Carbon Copy Cloner or ChronoSync on a schedule to just copy files to that NAS. If you need to go back in time, in theory Btrfs should have your back, according to the thinning policy you specify in the NAS.

But that’s really all pretty cumbersome. While pricier, the answer that makes me the happiest is: Mac mini, headless. (Or any other Mac you have lying around.) Forget that it can serve Time Machine; I don’t care. I get to copy to an actual APFS volume with CCC, and CCC on the receiving side will automatically make an APFS snapshot when complete. And you can specify a thinning policy for those snapshots in CCC, too. And you can use external SSD’s for easy flexibility. And it’s just all APFS! No tricks! No abstraction!

Right now, CCC network copies are just calling rsync under the hood, so they don’t have the bells and whistles of local copies, but Mike Bombich has suggested to me that a future version may have a copying engine for network drives with similar capabilities as local drive copies (and better speeds).

If you need to administer the headless mini, screen sharing awaits. And, if you need to restore a bunch of stuff pronto without network bottlenecks and complications, you can just detach the backup drive from the mini, and plug it directly into your own Mac. It’s APFS! No foreign file system nonsense!

(Speaking of which…It’s a digression, but I wouldn’t necessarily trust HFS+ formatted drives supported by non-Apple routers and NAS products, as I saw mentioned. Those are depending on a Linux implementation of HFS+…which is maybe fine, but I’m certainly not trusting my backups to it. And, worse, there’s no support for journaling when writing, which is key to preventing file system corruption in case of something like an unclean restart.)

One concern about this setup is security: if you have FileVault enabled on the mini, then, if it restarts for any reason, you have to physically log in to it. If you’ve got a keyboard attached and are in proximity, fine, but those are two things I don’t want to count on.

What I propose: the external backup drive(s) can be encrypted via the usual macOS method for doing so (control-click > Encrypt). Don’t ever save the password in the keychain. Don’t use FileVault for the startup drive, and don’t keep anything sensitive on it. If the Mac restarts for whatever reason – some sort of email notification would probably be a good idea, thought I don’t have a ready method for it – you can remote into it, and remount the backup drive(s) by entering their encryption password(s).

Alternatively, Apple silicon Macs appear to be reasonably secure even with FileVault disabled, as long as Find My is enabled. When Find My is enabled, macOS requires that an admin password be known to get to Recovery mode. And, unlike Intel Macs, they don’t offer Target Disk Mode without access to Recovery mode. So I think that, without an admin password, there’s no way of getting the data off an Apple silicon Mac when Find My is enabled, even if FileVault is disabled. That means that if you want to save the drive passwords in the keychain, they’ll auto-mount when the computer restarts, but if someone were to walk off with your system, they’d still be unable to get into it, or get the data off the drive, without knowing your admin password (or the drive password, if you choose to use a different one).

My old Linux-powered 2012 Mac Mini NAS ran Netatalk 1.x to serve AFP, purely because it could store all that silly Mac-specific metadata in files and databases, and that was good enough for me, especially since the speed advantages of SMB weren’t that much greater with carefully tweaked buffers, and Samba was (and is!) a tangled mess of obsolete nonsense that needs a specific extension to support Apple’s SMB client at acceptable speeds, which imposed the same requirements on the host filesystem for extended metadata.

Then the netatalk people released the 2.x series, dropping support for filesystem-based metadata, increasing the dependencies required massively (to include, for instance, Tracker for search), and dropping a load of legacy support for AppleTalk and authentication methods long-dead. I was very surprised by this, since it was already pretty clear, by then, that AFP was going away. And so it has. I wonder if they felt it was worth it? The 1.x series wasn’t beautiful, but it worked.

None of which much matters, of course, because as you rightly point out, Time Machine over the network is just a novel form of Russian Roulette with your data. Until CCC figures out snapshotted remote copies, I suggest a network backup tool like Arq or Duplicati (or whatever), that has no requirements on the target filesystem beyond that it stores and retrieves objects, which will preserve metadata and be efficient during backup runs. This obviously isn’t quite as transparent or flexible as whole-Data-volume backup performed by CCC, so here’s to hoping that in future it is possible to do such a backup over the network.

And, yes, just get a Mac Mini for a storage server that keeps your data on APFS volumes, if your budget and demands allow. You know it makes sense.

A little off topic, maybe, but since a few people mentioned that they are using ASUS routers:

I realize that this exploit is not directly related to AirPort/Time Capsule security, but I would be extremely nervous about exposing an AirPort router or Time Capsule to the Internet or even enabling wireless functionality if others can get within range. There is very little information on the net regarding AirPort vulnerabilities, but I note that the AirPort devices run a BSD networking stack and other BSD components that have not been updated in several years. Maybe AirPorts aren’t considered big enough targets to go after, but maybe not.

And this post from Bruce Schneier’s website a few years ago shows home router security is, unfortunately, not a recent problem:

“Most routers are designed offshore, by third parties, and then private labeled and sold by the vendors you’ve heard of. Engineering teams come together, design and build the router, and then disperse. There’s often no one around to write patches, and most of the time router firmware isn’t even patchable. The way to update your home router is to throw it away and buy a new one.”

Home router security discussion continues at Home router security.

I was interested to see the conclusion by @IvanExpert about coming up with a good Time Machine replacement. Apropros of that, I’m writing to report that I’ve successfully concluded my experiments described above to setup backup of Macs in my family to two small Linux servers using TimeMachine over SMB. These are both now working well. One is a 2014 Mac Mini retrofitted with a 2TB nvme drive, the other a Mele device similarly equipped. Each server cost <£250 all in. It’s nice and easy to work with nvme drives.

I had significant difficulties using the TimeMachine interface for adding network targets but I was able to do it without trouble using the tmutil command. The backups are now performing well over Wifi with sync over 1:1 ethernet cable nice and fast for bulkier transfers.

I’ve set the servers to snapshot the APFS sparsebundles weekly. Interestingly, presumably due to the way APFS bands work, these snapshots are very space efficient.

The CCC approach is very interesting. I personally use rsync to backup my Linux machine to a luks-encrypted btrfs volume on the same backup devices – it runs at least twice at fast as TimeMachine for the same volume of data. However I believe CCC network backups will not allow full machine restores. Also, despite @IvanExpert’s thoughtful advice of using a Mac filesystem for backups I’d prefer the bitrot protection, compression and snapshotting capabilities of btrfs since APFS sparsebundles seem prone to corruption.

Anyhow, If anyone would like me to write up a step-by-step guide of how to setup a Linux server for TimeMachine backups, I’m happy to do that.

Thanks for the heads up with this article. Many interesting post here, but often pretty technical. What I really want is just to be able to continue using Time Machine wirelessly by connecting an SSD to a router. I’m able to do that reliably now with an (older?) TP-link Archer C9 (that I got for free from a neighbor and migrated to after my Time Capsule failed a few years ago), but after updating to OS 15.6.1 today I got the message in Time Machine that AFP will no longer be supported in the future, so I guess the Archer uses AFP (not sure how to check that).

I did some checking now on the internet - like with the Linksys Velop mentioned by Gordon early on - but it’s really hard to determine if Time Machine backups with samba are supported. I searched the entire Linksys website, failed to find any mention at all of Time Machine.

Is there any available router right now going forward for this simple low tech solution?

I’m posting an update on this strategy of snapshotting TimeMachine backups on a Samba network share in case anyone hits this in future.

For context:

1. The APFS file structure is documented here on the Eclectic Light company article " How robust are APFS clone and sparse files?"
2. Mike Bombich’s advice is “If you want a reliable, fast, feature-rich, simple to use backup for a Mac, then I recommend taking networking 100% out of the picture.” and he points to several important caveats to backing up to a NAS.

Mac network backups don’t allow you to restore a whole Mac AND the poorly documented APFS file system format seems prone to corruption due perhaps to network interruptions or someone sleeping/stopping their Mac during a backup.

The best approach seems to be, for normal users:

1. use CCC for network backups
2. always ensure you have a local storage backup solution

The notes below are if you wish to play dangerously with your data (I strongly recommend local Mac backups if you are going to try this).

So how does my Debian miniserver with a Samba network sharepoint on a snapshotting btrfs filesystem stack up as a TimeMachine target?

1. backup performance over fast WiFi is fine.
2. backup completions can be monitored via the com.apple.TimeMachine.SnapshotHistory.plist made as part of the TimeMachine backup process and automated emails can be sent accordingly.
3. regular snapshots can be taken using btrfs subvolume snapshot which are, interestingly, file extent aware and seem space efficient.

The reason for this post is to report that this setup just suffered its first APFS corruption issue. I was able to rollback to the previous btrfs snapshot and continue the backing up process. That worked as inteded (whew!).

I’m interested to see in future if I can move a btrfs snapshotted timemachine backup to a local Mac disk and restore from that. Since I’ve standardised on nvme drives for all my family’s storage, I can in theory sync an image from a btrfs volume to a local apfs-formatted drive using AFPS for Linux. I expect this won’t work, but it might be fun to try.

I assume you’re thinking about mounting the image and a physical APFS drive and using Linux to copy the contents of one to the other (maybe with a cp -R or rsync command or some equivalent)?

Yeah, that sounds really iffy to me, given the fact that the Linux APFS driver is reverse-engineered (since Apple hasn’t published sufficient documentation) and fairly new (so there are likely bugs that haven’t yet been discovered). And I don’t know if the standard Linux file utilities will be able to copy all of the metadata for an APFS volume (especially for things like version history, snapshots and copy-on-write clones).

But if you have an APFS disk image file (or sparse-bundle collection of files), you should be able to use Disk Utility on a Mac. Select the destination volume, then click “Restore” from the toolbar. Tell it to restore from the disk image. The destination volume will be wiped and replaced with the contents of the image. I’d give that a try (maybe with a thumb drive of sufficient size) to see if it works as expected.

For the sake of completeness, based on alert notifications in macOS 26, “macOSFuture” is confirmed to be macOS 27.