MacOS security prevents applications from accessing backups. I don't think the user can even grant access to backups except to the last. It would require a serious breach of MacOS security that would likely be patched before the ransomware made enough money to justify the enormous effort that would be required to create it.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Eventually, I also fell victim to TimeMachine’s reliability issues
- Thread starter VitoBotta
- Start date
- Sort by reaction score
I don’t trust Time Machine ever since I got my first iMac in 2012. Gave it a test 2 years ago and yeah, still a big flop for me. Over this time I got used to manual backups by simply copying needed files on USB drives. Since the flash drives have gone dirt cheap I just buy them once in a while and keep copying files on ‘em. Even if one fails I know I have copy somewhere else, better than automatic backups and way better than HDDs or cloud storage
Yep, Time Machine works great until you need to actually restore something, then it’s just whine, whine, whine.
I do daily boot drive backups with CCC and use dropbox for current projects. I do weekly backups for the Files drive and monthly for Archive. So far it’s been mostly fine, but I do get into trouble if I notice a mistake from yesterday and CCC has already made a backup since. The safety net feature is a bit hit and miss and getting to it is not convenient in APFS.
After adding a Surface Pro to my workflow, I’ve been looking for a good backup solution for that but haven’t yet found something as affordable and simple as CCC.
Ever since I realise TM backup is not portable (that is, the ability to move backup to a new drive without destroying it), I’ve ditched it since and move to ccc. Unfortunately versioning in ccc is not working for me at the moment due to file system limitations and the aforementioned portability issue. I want a backup to be carried over across different drives, rather than starting anew.
I also use Acronis backup for my Windows PC, but sadly didn’t purchase another perpetual license for Mac otherwise I’d use that too on my Mac. Their backup is very portable, and I like it.
With Apple silicon locking down the system drive even further, I feel like TM becomes less ideal as time goes on. CCC seems to be good enough imo. Maybe some of my understanding is wrong, so I am open to be corrected. Right now I only use CCC for semi-regular Mac backup. If I had a Mac with more than just 2 USB-C ports I’d like to do it daily.
I also use Acronis backup for my Windows PC, but sadly didn’t purchase another perpetual license for Mac otherwise I’d use that too on my Mac. Their backup is very portable, and I like it.
With Apple silicon locking down the system drive even further, I feel like TM becomes less ideal as time goes on. CCC seems to be good enough imo. Maybe some of my understanding is wrong, so I am open to be corrected. Right now I only use CCC for semi-regular Mac backup. If I had a Mac with more than just 2 USB-C ports I’d like to do it daily.
Perhaps re-read my post?
One CCC backup is always held off-site.
It would have to be a hell of a ransomeware to affect a disk that is not even in the building.
I have been using TM for about as long as I've been on Mac - guess that's 19 years now. I am generally more careful than most, so I do not often have to go back, but I HAVE had to go back, and it has always worked, including relatively recently, on either Sequoia (probably) or Sonoma.
However, "trust but verify." I also back up to BackBlaze, stored on the opposite end of the continent. This of course is off-site too. I have never HAD to restore from BackBlaze, but I test it monthly.
You do test your backups regularly, don't you?
However, "trust but verify." I also back up to BackBlaze, stored on the opposite end of the continent. This of course is off-site too. I have never HAD to restore from BackBlaze, but I test it monthly.
You do test your backups regularly, don't you?
Time Machine only works with APFS. The one exception, from what I've read, is that if you have an old HFS+ Time Machine drive going that was created pre-APFS using Time Machine's weird old "multi-linked file" system (versus the much less hacky and more reliable APFS snapshots it uses now), you can still use that. Getting all this from Eclectic Light Company, which has a lot of insanely deep dives on the subject.
Last edited:
Well, I guess I've "gotten lucky" a dozen times or more over the years.
I've never had TM report that it was okay and then fail to restore files. But I have seen it get stuck on the Preparing step forever, and the fix was to start a new backup from scratch. I've also seen the disk fail and it not letting me know until I checked the status. So the burden is on me (and family members) to check the backup status regularly, which not everyone knows how to do.
Accessing older versions of a file saves my butt at least once a year, and one time I migrated a family member to a new computer using it, but I do not trust it fully, and it is incredibly slow to browse (especially compared to that great Apple demo Apple when they first unveiled it.)
I agree with others that Apple hasn't given it much love lately. It does basically still work for most people most of the time. But given the task it is supposed to solve, that's not good enough.
Accessing older versions of a file saves my butt at least once a year, and one time I migrated a family member to a new computer using it, but I do not trust it fully, and it is incredibly slow to browse (especially compared to that great Apple demo Apple when they first unveiled it.)
I agree with others that Apple hasn't given it much love lately. It does basically still work for most people most of the time. But given the task it is supposed to solve, that's not good enough.
I've been using TM for years and it's been "good enough". I really like the ease of use and the simplicity of the interface even if it is slow.
My main gripe is the inevitable corruption which causes the system to insist on deleting the old backup and creating a brand new one. This seems to occur about every 1.5 to 2 years but recently it's gotten to where it's less than a year. So, great, I'll still have a current backup but now I've lost the archive so I can't go back and get something I accidentally deleted years ago (not that this happens often).
I suspect that this problem is due to the network or the NAS itself. I get random "failed to eject <TM volume>" errors occasionally. And the backups themselves seem to take way longer than expected for a mere 100MB or so. I blame TM overhead for that.
I have no interest in becoming a full time archivist with the elaborate steps that go along with it.
I may start doing a 2nd TM backup to a locally attached storage which is fine for my iMac but might become a bother for my MBA. But I think I'm going to try this idea out anyway.
My main gripe is the inevitable corruption which causes the system to insist on deleting the old backup and creating a brand new one. This seems to occur about every 1.5 to 2 years but recently it's gotten to where it's less than a year. So, great, I'll still have a current backup but now I've lost the archive so I can't go back and get something I accidentally deleted years ago (not that this happens often).
I suspect that this problem is due to the network or the NAS itself. I get random "failed to eject <TM volume>" errors occasionally. And the backups themselves seem to take way longer than expected for a mere 100MB or so. I blame TM overhead for that.
I have no interest in becoming a full time archivist with the elaborate steps that go along with it.
I may start doing a 2nd TM backup to a locally attached storage which is fine for my iMac but might become a bother for my MBA. But I think I'm going to try this idea out anyway.
I do worry about a potential failure when trying to recover something. I don't worry too much because I have a lot of redundancy; I have 3 clones, 3 TM backups, and 3 offsite destinations. But, I should be testing some. Carbon Copy certainly verifies the backups after they are made, but I suppose there could be a bug.
Could you describe your test? I'm curious about what you're testing. It seems like you're suggesting you do a full restore from BackBlaze. Do you have a VM for that or a spare machine that you use? If you do a restore, how do you confirm the restored files are all correct?
In case of Time Machine, grab some random items and restore along side the original, then can use shell commands like cmp, diff, or 3rd party apps to compare contents.
If have spare disk space lying around, can restore items from other backup methods to said space and run compares.
Obviously, don't want to do this to something that changes often, like contents of the Library folder (too many changes happening all the time to have anything "static" there for the most part). Or understand the output of compares: for example, if comparing Pictures folder vs backup, and use Photos app [or similar], need to account for databases that might have changed/updated [photos.sqlite* files].
Last edited:
Maybe I'm naive, but I have my CCC running diffs every 4 hours. Yes, there's latency, but it's reliable.
This is a reasonable way to test that TM backups have not suffered significant failures. A random sampling of a reasonably large number of files will likely detect that. Carbon Copy's checks are far more thorough. Maybe there's nothing like that for Time Machine.
I do not trust Arq and BackBlaze. Its closed source and you know what happens in the background. To each his own.
how do you test and verify 100s of GB?
On another forum I was directed towards Duplicati. I'm obviously after data backup, not full OS backup.
Duplicati = OpenSource + supports all the major destinations.
I think the tradeoff between Duplicati and something like Cryptomator is Duplicati does folder/directory backups (in a traditional sense like at X time, here's what the file looks like) where Cryptomator is an encrypted file-on-demand situation.
Duplicati = OpenSource + supports all the major destinations.
I think the tradeoff between Duplicati and something like Cryptomator is Duplicati does folder/directory backups (in a traditional sense like at X time, here's what the file looks like) where Cryptomator is an encrypted file-on-demand situation.
I have MacOS and Windows 11 on the same SSD ("bootcamp" style, I have Intel), and the quickest way to backup OS is using plain copy Linux style "dd" to an external SSD. Time Machine is more time consuming to restore from these days. That's one reason Time Machine, or any backup really, over network is just to be considered extra protection, not the first choice when having to restore anything.
Anyway, just wanted to chime in on Icloud - I have used it for years to store documents, and, for me, Icloud silently fails to sync some files. Even if I give it days to catch up. I have no idea why. Some files were zipped, others were written in Pages and stored on Icloud. But Icloud folders, from 2 computers, didn't match - and they didn't match what was found on https://www.icloud.com/iclouddrive/ either. I had to spend ages to remove everything from icloud and start all over, and now I think it syncs ok. But I only have 3GB of data there now, much of it zipped, not 40GB like I used to.
(I didn't lose anything I think - Time Machine saved me that time; another time Time Machine backed up everything except my main user folder - what?? Maybe some program had changed some settings with my ok, fortunately discovered this after a few months)
Anyway, just wanted to chime in on Icloud - I have used it for years to store documents, and, for me, Icloud silently fails to sync some files. Even if I give it days to catch up. I have no idea why. Some files were zipped, others were written in Pages and stored on Icloud. But Icloud folders, from 2 computers, didn't match - and they didn't match what was found on https://www.icloud.com/iclouddrive/ either. I had to spend ages to remove everything from icloud and start all over, and now I think it syncs ok. But I only have 3GB of data there now, much of it zipped, not 40GB like I used to.
(I didn't lose anything I think - Time Machine saved me that time; another time Time Machine backed up everything except my main user folder - what?? Maybe some program had changed some settings with my ok, fortunately discovered this after a few months)
One of the best reasons to transition from legacy macOS to iPadOS is the built-in cloud backups. iCloud Sync/Backup works flawlessly on iOS/iPadOS devices but I've definitely heard macOS has a lot of cruft that causes unreliability due to its age.
What is the syntax of the dd command you use? I've used dd to copy full volumes and other similar kinds of things. How are you using it for backup?
All of my important data is on an external SSD attached to my Mac Mini and I use that drive with Sync.com, so it is automatically Synced. I also have an external HD attached for regular Time Machine backups, and it also backs up the other external drive (my sync.com drive). I also have a local NAS that I mount over NFS and then run a rsync script on my Mac Mini to backup all the files on that external drive to the NAS to create a mirror copy. My NAS also has an external drive connected for local backups that runs a backup job on that data weekly.
this one definitely looks nice. Does it run as an app locally, or you have to set it as a docker and server blah blah?
-does it create 1:1 copy?
-if its that simple, then backup apps are easily replaced?!
-is it any different than going to Macintosh HD and just selecting everything and drag+drop it over with the mouse to an external drive?
one important thing is that I do not think it does incremental backups, so every time you need to backup a 300GB drive it will copy the whole 300GB over.
dd creates a byte level "copy" so its great for cloning media (HD's,etc) since it preserves the disks state byte by byte. There are plenty of free command line tools that can replace backup/duplication apps (rsync, rdiff, ditto....)
dd is most often run from the command line, in Terminal. It can copy anything, but I believe the suggestion is that @poi ran is copying a full volume to a destination volume, since they mentioned "backup OS" in their post.
And as you said, if used that way, every backup writes the full volume to the destination every time it is run. I don't know much about how that would impact longevity of the target if one were to back up frequently. Of course if the backup is interrupted or fails in some way, you've completely lost your last backup to that destination and have nothing.
dd is a particularly poor choice if done incorrectly. Just copying from a volume where active processes might be writing will result in a backup that probably is internally inconsistent or even unreadable. Backup tools like Carbon Copy and Time Machine take a volume snapshot and back up that snapshot.
If one were to use dd to backup a volume that's in use, then a snapshot should be taken, the snapshot mounted, and that volume be selected as the source of the backup. Carbon Copy and Time Machine can make snapshots on demand.
rsync is a more efficient choice since only changes are written to the destination. Also, a failure or interruption does not corrupt the entire destination volume. rsync has the same issue with regard to needing a snapshot, but the severity of that depends on the scope of what you're trying to copy. For example, backing up ~/Library would be vulnerable to changes during the copy.
Using Finder to make backups maybe also has the problem that files could be written to during the copy. I found