Do You Use It? What’s Your Backup Strategy

That’s the option I was looking for in Adam’s survey: manually created clones.

Overall, our current set-up looks like this for both of our personal Macs:

  • Internet versioned: Continous via Backblaze
  • Local data-only clones: Manually to SSD via ChronoSync once a month (drive is disconnected between back-ups)
  • Off-site data-only clones: Manually to GOPD¹⁾ via ChronoSync once a month, rotating three drives (so the back-ups are no older than 3, 2, and 1 month(s), respectively)
  • Cloud: Photos and Music libraries on iCloud (yup, not fool-proof for the former, but that’s well-covered by the other three options)

Planned future changes:

  • Local data-only clones: Move to scheduled ChronoSync, with having the app un-/mount the always-connect drive as needed
  • Off-site data-only clones: Switch from GOPD to SSD to speed things up “a bit”

¹⁾ Good Old Platter Drive :smirk:

Except for routine testing, I haven’t needed to use a backup in years. In 2016 the GPU in my 2012 MBP died. We had just bought my wife a new iMac so I used my bootable CCC clone to get up and running on her old iMac. One other time I had an OS upgrade fail and used the backup to get going.

If my M1 iMac died I have an old MacBook Air that’s synced via iCloud so I can be going in a short time.

Back to the subject of testing - my philosophy is that an untested backup does not exist. If you haven’t tested it recently, you cannot depend on it. I test both my local and BackBlaze backups. A lot of this comes from my involvement in corporate disaster recovery. We had time windows when critical systems had to be up and running. In some scenarios certain people were designated as unavailable for the recovery.

While having an automatic backup run from CCC is a good idea, I just ran into a problem that redundant backups can cause. On my Archive disk, I keep files I do not need immediate access to, and store a clone of the disk in my safe deposit box. I was running Neofinder on my disk and it kept giving me a memory overflow with requests to close other programs. I thought the problem was with NF, but looking at logs showed a lot of files that were corrupted or otherwise could not be opened. This never showed up on my copying and I do not think there is a fix. It may be that the disk is old or the directory is corrupted. Who knows. It is beyond my skill set to figure out what it happening.

One lesson is to check these kinds of backups regularly (though this disk contains so many files, I don’t know how I would catch this earlier). Also don’t assume just because you are backing up that the files can be recovered when you need them.

If I run a recover program on this, will I be able to recover the files?

(Also, would formatting the disk in APFS give my directory any more resilience that if I format the drive in HFS? This will be a 14 TB hard drive.)

CCC has an option in its ‘Advanced Settings’>Performance & Analysis tab to check for corrupted files periodically. I’ve set that to once a month. Note: if large HDDs are involved, the time to run that backup is enormous compared to a typical run (say 10 hours vs 30 minutes).

Excellent point about testing backups — and kudos to Adam for evangelizing Friday 13ths as backup testing days!

We have a recurring task to test all of our backup destinations — off-site HDs, local SSDs, and BackBlaze — every three months. IMHO, that’s often enough, especially since, ChronoSync, our current backup software of choice, has great logging and very clearly points out any issues it encounters during a run.

We do the testing manually by restoring a dozen, or so, randomly selected files. That doesn’t sound comprehensive, but it does ensure that the medium is generally accessible and its data not corrupted beyond rescue.

I would assume that this would take as long as a full (that is, not incremental) backup, since it needs to read every file on both the source and destination in order to compute and compare the checksums.

See also CCC: How to verify a backup.

I almost forgot that I have a rather, umh, dramatic story to tell about backups. That experience inspired a five-minute Ignite talk I gave some ten years ago.

Talking to audience members afterwards, I was stumped by how many of them did not have any backups at all.

Compared to that, I see that most of us TidBITS Talkers are well into paranoid-about-my-data territory. And that’s a very good thing!

I once had a mission-critical server (Linux) backed up daily to Amazon Simple Storage Service using duplicity. I would periodically restore a few files just to make sure everything was working.

One day the server’s disk became corrupted (thanks, systemd!) and it wouldn’t boot. Because I had a full backup that was less than a day old, I decided the most expedient course was to just restore the entire server.

I started the restore. I knew it would be slow: the files were stored online at AWS. When I did test restores, it took a while (maybe 1-2 minutes per file restored) but I figured that was overhead searching for the files through hundreds of incremental backups – overhead that wouldn’t apply to every. single. file. on a full restore.

I was wrong.

After 24 hours, the restore was less than 1% complete. Thinking that internet delays were the culprit, I downloaded the entire backup set which required only a few hours. I then ran the restore locally. It didn’t speed up. It turns out that duplicity really doesn’t like having hundreds of incremental backups accumulated, and I was rotating the backups (starting a new full backup) only once a year.

One minute per file doesn’t seem that bad, but for a server with right around a million files on it, I think that makes the restore time in the neighborhood of two years.

Two morals:

  1. Limited testing is a good thing, but there needs to be at least some full testing. Which I did, but only a month or so after starting using duplicity and I didn’t repeat it after the number of incrementals had built up. It is difficult, time-consuming, and expensive to do full disaster recovery drills regularly, but without doing so you risk being bitten by bugs that won’t show up with limited testing.

  2. Those of you who have backup strategies that use completely different tools to make multiple backup sets (Time Machine + CCC, for example) are doing a Very Good Thing™.

I had a bootable clone of the server that was only a few weeks out of date. I used that, and updated the likely places where data loss might occur using the duplicity backups. All was well except that it aged me a bit.

4 Likes

Thanks for sharing that story, Ron! It made me wonder if there isn’t a way to automate that backup check.

Turns out, that ChronoSync has a “Validate” function (emphasis mine):

The validator function compares the selected file or folder pair and verifies that the file data, resource forks and metadata match between the two. This includes verifying the data via bit-for-bit compare or checksum, depending upon the target connections.

Sounds like that approach is much more thorough, more trustworthy, and less tedious than any randomized manual testing could ever be.

So there’s my weekend project… :sunglasses:

P.S.: TidBITS Talk still rocks. Of course. :grin:

1 Like

Could you please elaborate a little, especially about Mail?

I agree with Ron; my SuperDuper! bootable back ups are a huge comfort for just such situations as he describes. As is being able to find things using the Finder, instead of delving into Apple library voodoo or a bucket full of unidentifiable files. I am furious about this development.

Depending on the amount of work I am doing I will go for a bootable clone of everything (3TB) every few days. Plus, drawings for projects I am working on get uploaded as a version copy to iCloud, so I can keep the gaps between drawing copies smaller. My strategy also includes a “save as” each day or each significant change or variation. It is a system which has been tested several times over the years, it works well and now it is broken. Midst all the over-engineering of 21st century Apple these adjustments seem petty and unnecessary. Some you can work round. Some you can’t. Which is why I have five Apple computers of different ages in my office, all running different OSs, dedicated to different functions.

1 Like

Drew and Roger,

Please elaborate which version of Sequoia you are running. As I previously mentioned, 1) one of the reasons Adam began all this was due to OS 15.2 “issues” with bootable backups, 2) SuperDuper! “supposedly” not providing bootable backups under 15.2, and 3) my most recent post about my (final!) success with SD and the port dependency.

Is the working port on each machine the DFU port? Not the DFU port? Or DFU port on one but not the other machine?

See Apple’s article on How to identify the DFU port on Mac.

I’m not much help in this as I am still running Sonoma on an Intel 2020 iMac 5k, trying to stay out of trouble. I was quite keen to get a newer machine before Christmas but not yet.

I don’t like using email as a filing system. It’s rare that someone needs the actual email in the future. I save them as a PDF and then file the PDFs in my filing system. Much better backup granularity. Before retirement my wife worked as an Exchange administrator and has horror stories of her users having massive email stores (PST & OST) and having them get corrupted.

1 Like

Neither of them are the DFU ports. On the Mini, it would be the port closest to the Ethernet Port. On the Air, it is the port closest to the hinge. I have the SSD drives plugged into the other ports on each Mac, ie, the non-DFU ports.

I keep incremental backups of my major data storage volumes, including my internal startup volume. However, I just went through a great deal of difficulty ensuring that I could still boot from an external volume that incorporated a copy of my internal data volume. Like others, I discovered with the upgrade to Sequoia 15.2 that the legacy system cloning option was no longer viable, but I finally got pretty much the same result by installing Sequoia 15.2 to the external volume, then booting into that volume, setting up a temporary admin user, then performing the migration to the data volume using Migration Assistant. The difficulty appears to be that my internal drive had some corrupted data, because after several failures, the problems went away when I reinstalled 15.2 to my internal volume as an in-place installation with the goal of repairing whatever was broken. It surprised me that only this function appeared to be affected by whatever was corrected by the in-place installation.

Laine,

If you read my posts above, you’ll see where I run Onyx and Disk Utility’s First Aid on each of my Mac’s internal SSDs before doing the SuperDuper! backups. I also keep my Macs “lean, mean, and clean”. Then of course there is the issue of “port dependency” with the backup process, which I finally resolved the other day (see my latest post above about that). Basically not use the DFU port. This link has information on the location of the DFU port on each Mac model:

First, BackBlaze does not back up your entire Mac. You are not going to reconstitute a failed machine with a BackBlaze backup with ease. Here’s what they say:

What We Don’t Backup

Backblaze does not want to waste your bandwidth or Backblaze data center disk space. Thus, we do not backup your operating system, application folder, or temporary internet files that are transient and would not be useful in the future. Backblaze also excludes podcasts in iTunes.

Certain Filetypes

You can see these exclusions by clicking on “Settings…” in the Backblaze Control Panel and selecting the Exclusions tab. These exclusions can be removed! Some of these excluded files are:

  • ISO (Disk Images)
  • DMG (Mac Disk Image)
  • VMC VHD VMSN (Virtual Drives)
  • SYS (System Configuration & Drivers)
  • EXE (Application Files)

Other Backup Programs

Backblaze also doesn’t backup backups like Time Machine and Retrospect RDB.

So, let’s say you have an unfortunate event involving a hamster, a large glass of just-mixed epoxy, and your laptop. After a week or two, the laptop comes back from Apple with the default system for that model & year (:sunglasses:). You received your USB drive from BackBlaze and now what? You can’t use migration assistant [update: I’ve never tried this, it might work but it seems unlikely to work and a query to Backblaze support showed they’ve never tried this]: the BackBlaze backup is simple. You have to create your new user account and then copy over your user files. Documents folder, Movies, Music, etc.

But, and this is the crux of your Mail question, what do you do with your User Library where all your preferences and mail data and application support files are kept? Unless you are absolutely certain that the OS is exactly the same one you were using when the hamster careened into that glass, copying the entire User Library and replacing the vanilla one on your new system is a very, very big question mark. I’ve never had the courage to try this and unless you’re truly expert, don’t.

If you want to restore your Mail settings and archive hold down the Option key and click on the Go menu in the Finder, your User Library will appear in the list. Open it. Then, making sure Mail isn’t running first, copy the Mail folder from the backup to your new Mail folder replacing it. You should do the same for the Application Support folder and the Preferences folder. Then, immediately restart while crossing your fingers (and your eyes, too, while you’re at it). As for the rest of the zillion folders in the Library, you’re on your own. . . . :slightly_smiling_face: :roll_eyes:

If other people have had experience with restoring from BackBlaze I’d encourage them to post here. My own feeling was when I had to use it that “You’re lucky you have anything at all so just get the basics and don’t try to be fancy.”

Dave

1 Like

In addition to Jochen comments (thank you), CCC does a similar process if one selects “Find and replace corrupted files” in the advanced settings for a task. To quote from CCC’s web site:

“CCC normally uses file size and modification date to determine whether a file should be copied. With this option, CCC will calculate an MD5 checksum of every file on the source and every corresponding file on the destination. If the checksums differ, CCC will recopy the file.”

On a HFS disk it takes hours but on a SSD it’s much quicker.