Marsymars
2 days ago
Well, heck.
I posted ~7 months ago about my decision to use HFS+ for backups, and had a couple skeptical replies. (https://news.ycombinator.com/item?id=47317123)
I guess I misjudged Apple's commitment to support HFS+ long-term.
It now seems like there's no real native way of doing encrypted backups to HDDs on macOS (APFS not really recommended for HDDs)... the options are either encrypted Time Machine to a network location, or a third-party tool.
Guess I'll figure out SuperDuper or Carbon Copy.
lakeviewterrace
2 days ago
> encrypted Time Machine to a network location
this has a bonus feature where it will slowly corrupt itself over time and offer to start a completely new backup instead.
yangm97
2 days ago
That would happen around once a year when I used the 2013 AirPort Time Capsule.
It seemed to stop killing itself when I moved to a ZFS backed samba share.
Funnily enough I also kept snapshots enabled because I was expecting TM to bork itself eventually, so I could always rollback to a working state but I don’t remember needing to use that.
nijave
2 days ago
Eh, mine was always on zfs first on FreeNAS then Ubuntu and it didn't seem to help.
The only thing that definitely made it worse was smb over openvpn. It'd corrupt itself every couple months instead of once or twice a year.
mahboi
18 hours ago
What is the issue exactly, your network drops entirely and the sparse bundle disk image gets into some inconsistent state? Cause SMB is definitely not aware of the stripes you're writing for that, and partial file writes are possible too. But I'm a bit surprised if these disk images Apple intentionally chose for networked TM backups don't have some kind of failsafe for this, either at the block layer or the APFS layer.
And personally I've never had networked backups get corrupted, dunno why.
themanualstates
2 days ago
I also had a recurring corruption issue using a Windows Server file share.
Before MacOS 27, I was always able to remove the Time Machine destination, replace the corrupted sparse bundle with a fresh empty one, and reconfigure that as the new TM destination. I even made a script for this, so I didn’t have to figure out the terminal commands every time.
Unfortunately the script doesn’t work anymore; it throws ‘error 25’ on my MacOS 27.
What’s weirdest is that, before the corruption, TM backup and restore used to work fine on my MacOS 27. Seemingly the backup functionality works as normal, but setting the TM destination was broken.
js2
2 days ago
I backup to TrueNAS which configures Samba/ZFS to take a snapshot before each backup. If TM decides to corrupt a backup, I can revert to a snapshot. I've only ever had to do this once in years of operation with several Macs backing up (each to their own share).
thfuran
2 days ago
Sometimes it's pretty quick.
mistrial9
2 days ago
to go forward, you must backup
AceJohnny2
2 days ago
> I guess I misjudged Apple's commitment to support HFS+ long-term.
One thing I have learned with (current) Apple is to never trust their commitment to support something they're not using. And even be wary for stuff they are using. (in my mind, a core technical difference between Microsoft & Apple is that MS will bend over backwards for backwards compatibility, whereas Apple will drop it as soon as they can, and sometimes sooner still)
They replaced their use of HFS+ with APFS in 2017, so it's had a good run.
AceJohnny2
2 days ago
I have heard from ex-CoreOS (the Apple org) colleagues is that the organization is run intentionally lean, because the leadership believes that people do their best work under pressure. This leads, among other things, to aggressive YAGNI pruning.
jiveturkey
a day ago
sorry for the non-substantive nit. because we all know what you meant.
YAGNI is about not doing work in advance. it's very confusing to say YAGNI and pruning in the same breath. it's also confusing to call this aggressive since it's been 10 years.
i wouldn't call it dead code pruning either, since the code in question here was actually reachable and used. maybe, unmaintained code pruning?
natch
a day ago
Pruning of proposed features maybe?
unsloppable
2 days ago
Rosetta..
tonyedgecombe
a day ago
Is dead in next year's release (apart from a handful of exceptions).
mrpippy
2 days ago
I don't think APFS was designed or tuned with HDDs in mind, but it will work just fine. Especially for backups where random read/write performance is not important.
MilaM
2 days ago
I would not recommend using an APFS formatted HDD for Time Machine. It's painfully slow. With my Samsung T7 the hourly Time Machine backups are usually finished after a couple of minutes. Using my older HDD they can easily take 20 minutes to half an hour.
outofpaper
2 days ago
While time machine used to be snappy on HDD it was build out of one of the weirdest little hacks hard links in folders. The new Time Machine might front a similar front end but under the hood its a different beast. You're having to mount snapshots as you move through time.
fl0id
2 days ago
are you sure that is because of apfs? hdds are usually much slower, no?
zimpenfish
2 days ago
It's definitely APFS. I've had the pleasure* of HFS+ and APFS on the same external HDD and APFS is horrible. Given it is optimised for solid-state drives[0], it's understandable there'd be some slack but it is absolute horse paste.
(If I could create an encrypted external HFS+ volume, I would but macOS hasn't allowed that for a while as far as my experience goes - it's non-encrypted HFS+ or encrypted APFS.)
[0] https://support.apple.com/en-gb/guide/security/seca6147599e/...
MilaM
a day ago
My point is that while the old HFS+ based Time Machine was performing ok on spinning disks, the new APFS based TM backups are excruciatingly slow and take ages to finish. I did actually compare both types on the same hard drive and even then the difference was very obvious.
1over137
a day ago
>It now seems like there's no real native way of doing encrypted backups to HDDs on macOS
Be happy they let you backup to HDDs at all. :) They don't sell HDDs, so I'm half amazed they still work whatsoever.
hoherd
2 days ago
This might be a blessing in disguise for you. The silent data rot of HFS+ is what pushed me to ZFS. I would never go back to HFS+.
stingraycharles
2 days ago
Ok I may be an idiot, but I just have a permanently attached external disk that does Time Machine, what am I missing out on? Why network location? Or are you backing up massive amounts of data? (for me it’s just 2TB)
Marsymars
2 days ago
Oh right — I could do a local HFS+ non-encrypted disk with encrypted Time Machine (I assume) — that just slipped my mind.
tonyedgecombe
a day ago
This is what I do. It's the happy path and works well.
It seems most of the problems with Time Machine happen when you try and run it over SMB. It's not that surprising when you realise what it is doing under that scenario. It creates a virtual disk on the remote and then formats it with APFS. You don't need much to go wrong to corrupt the backup in this scenario.
mahboi
2 days ago
It's mainly for multiple people in a household to back up to one location, especially if some have laptops that are often not on desks. Those Airport APs used to also let you attach disks for this. You could even do it over a VPN.
stingraycharles
2 days ago
I so miss these Airport APs, I really don’t understand why the product line was cancelled, it was perfect.
mahboi
2 days ago
Same, I still have one for random purposes. Still the easiest and most polished router/AP, has lots of features.
root9876
2 days ago
I switched to Borg on Linux server from local attached Time Machine disk after once I went to a long trip and forgot the disk at home.
pinyen_cheng
a day ago
Yep, never trust Apple for something they don't rely on to live. For example, don't expect the ecosystem with the Homepod with screen can last for too long. The support will drop and only leave security response if nobody is purchasing.
mahboi
2 days ago
Wait, you can do encrypted backup to a network location but not to HFS+? What if the network location is just your own Mac?
isityettime
2 days ago
Can you use OpenZFS?
mahboi
a day ago
I had to cmd+f "FUSE" all over the place first, thank goodness 0 matches
isityettime
a day ago
They are working on a userspace port, since newer versions of macOS don't/won't allow third-party kernel code ("kexts"). But it's based on Apple's newer FSKit API directly, not macFUSE or FUSE-T.
mahboi
21 hours ago
I just remember Google macfuse, osxfuse, then the new non-Google macfuse never working right for one reason or another. Don't think it was even a kernel vs userspace issue, it's just that the project kept changing ownership and getting broken by OS updates for other reasons, and it was confusing to find help because of the naming.
Marsymars
a day ago
I could, but I don't want to make my wife figure that out if I get hit by a bus.
Joel_Mckay
2 days ago
MacOS is only Posix like, and does a lot of weird nonstandard things in the background regarding mounting drives/images.
There are restrictions on where things can run, what can run, and what is accessible to the process.
SSHFS is slow, but at least can mount windows/linux/android systems over VPN without issues. Look at what is needed to bring up SSHFS or NTFS support, and you should have a better idea of Apples walled garden policies.
Apple makes information appliances, and not general-purpose computers. Some may disagree, but they usually choose an exception use-case rather than the normal experience of users. =3
mahboi
a day ago
Well I'm in your boat. Encrypted sparse bundle disk image on an HFS+ volume seems like it should work, if I'm not missing something. You only need CoreStorage for encrypted HFS+.
qmr
2 days ago
ZFS