Rolling back from a system upgrade

I have a doubt about what I wrote above.
Yes I also understand that a snapshot is made before a system upgrade, presumably with the specific purpose of rolling back if the upgrade goes bad.
When I tried rolling back by restoring a snapshot I was presented with a whole page of snapshots to chose from. These were the regular ones that TM creates every hour. I used one of these from before the upgrade and it rolled back all my data, apps and settings to the the time before the upgrade but the system volume was still the latest upgraded version.
I did notice or look for a special snapshot created before the upgrade, which I suggested above was to enable a roll back.
Maybe this roll back ability has changed, and now the protection is only to recover data, apps and settings from before the upgrade, not to rollback the OS version. Or maybe there is a special snapshot, but somehow I doubt it.

So… I was able to install a new OS (High Sierra) onto a thumb drive and boot the machine from that. And I can navigate to the applications folder on the internal drive and attempt to open an app.

BUT… the app (QuarkXpress) thinks this is a new install and wants to run through the registration process before opening. This will exceed my license limit – and even if it succeeds, I’m concerned it will invalidate the license I have already installed.

This seems to be the case with all my software – the apps think they are being opened for the first time.

Is there a way to modify this so the apps know to look on the internal drive for their configuration files?

You should be able to, but please note:

  • I mentioned a USB flash drive for creating a bootable installer, not as a destination for the installation.
  • While suppose you could, in theory, install macOS to a flash drive (if you have one that’s big enough), I wouldn’t recommend it. Flash drives are very slow and tend to not have the kind of wear-leveling technology that SSDs use. I don’t think you’ll be happy with the result, and your experience will be much worse than an installation to a Mac’s internal storage.
  • I would recommend installing to an external SSD (Thunderbolt, if you can afford it. USB 3 if you’re on a budget). You can also install to an external hard drive, but performance will be significantly worse.

If your goal is an emergency recovery system, performance won’t matter much, since you will (probably) only boot it rarely, in order to perform system maintenance or recovery. But if your goal is to have a temporary production system, for evaluation purposes, then you need something that will perform comparably to your internal storage, which means an external SSD of some kind.

1 Like

This is because the app is looking for registration data and preferences on the current system volume (probably somewhere under /Library or ~/Library).

If you know what files it’s looking for (some web searching may help you figure that out), you can try copying them from the old system to the new system. Alternatively, you can try running Migration Assistant to move your preferences (and maybe also your home directories, if not the apps themselves) to the new system.

1 Like

Ah… good point. I didn’t understand the difference. Thank you.

Just to pile on to what @Shamino wrote, I think you could do all of what you want without hassle if you went with a slightly larger SSD instead of the flash drive. As he writes, performance will be much better, but more importantly, with the larger capacity you can not just check out the system, but also all your apps and how it performs on your actual workflow.

So take a large enough external SSD (you can get a decent 1TB SSD for as low as $78, USB 3.1 Gen 2 cases cost as little as $12) and first clone your entire internal drive to it and then install Big Sur on that. When you boot from it, you will have your entire environment running on Big Sur. That would allow you to test Big Sur and use all your apps as you’re accustomed to. If you like it, install Big Sur on the internal (don’t forget to clone that first as a fail safe) and use Migration Assistant to bring over your docs or any other changes from the external SSD (this would be easier if bootable cloning worked on Big Sur [you’d just clone the external back onto the internal], but AFAIK we’re not quite there yet). OTOH if you don’t like it, just go back to booting from the internal Catalina drive and use the external SSD for something else.

That SSD costs a bit more than the thumb drive, but it will allow you to test everything you want/need and it will be a much better performing environment. And regardless if you like it or not, going back to regular use requires little effort.

BTW, a simple clone is free with SuperDuper!.


Thank you, thank you, thank you. This is incredibly helpful. I think I will go that route. And actually I’m only going up to Mojave, because as far as I can tell, the primary software I depend on only goes that far. And I do use Super Duper. So I’ll be ordering that SSD and proceeding on that path.

Using a USB thumb drive was not what I recommended. As I believe I outlined later in the conversation I use a bootable external SSD which contains all my applications and a symlink to my home folder so that the registration data for those apps is accessible to those apps. There are a very few which somehow sense that they have been relocated to a different drive and require me to re-register them (Microsoft being one of them) but that didn’t present a problem for me beyond digging out the licensing information.

Sorry, sloppy on my part and I misunderstood. Thanks for clarifying.

Hi Simon – Are you familiar with the SSD you referenced here? It will work on a Mac as a bootable drive?

It absolutely will. Just use Disk Utility to format as APFS. There are other SSDs that perform better, but they’re also more expensive. Regardless, they’ll all work just fine on a Mac.





Does TidBITS have a page for SSD recommendations?

For a device that is not expected to be used long-term (e.g. for a few months to evaluate a system), it probably doesn’t matter too much, but if it is something you expect to be using for a long time, I would recommend a brand with a good reputation.

IMO, these brands are Samsung, Crucial and San Disk.

I’m not familiar with WD’s SSD reputation, so I don’t have an opinion about them.

I would avoid PNY products at all cost. Although I haven’t used one of their SSDs, I have used several flash storage and DRAM products from them over the years, and all have failed catastrophically soon after installation (sometimes DOA, and sometimes dead after a few weeks). I don’t think any of their products can be trusted.

FYI, on the command line, tmutil can create a snapshot.

Thanks for your suggestions on backing up to an external SSD, or installing Big Sur on an SSD as a test. My question is: can CCC create a bootable 500GB backup of Catalina from my iMac to a 1TB SSD formatted as APFS which already has some files on it? Or would CCC try to use the entire 1TB as a single volume?

Sounds like you need to change the partitioning on the SSD to add one partition in addition to the one already holding files. Disk Utility should let you do that. That new second partition can then be used by CCC as a clone target volume.

@Simon’s approach is best - partition the destination so your backup is separate.

That having been said, one of CCC’s advanced options for a backup task is “Protect root-level items on the destintation”. When checked (it is on by default for new tasks), files and folders in the root of the destination device/folder will not be deleted if they don’t exist on the source.

But it’s still risky to rely on this because root-level items will be overwritten if the source has a matching file or folder. And when you want to clone that volume elsewhere (e.g. when restoring a backup to a computer’s internal storage), you will need to remember to not restore those files/folders.

If there is a reason you must leave those files on the destination volume, may I suggest you do one of the following:

  • Move them to a folder you know doesn’t exist on the source (e.g. “NotPartOfTheBackup”). This way there’s only one name to potentially conflict and it will be obvious (to you, in the future, when trying to restore the backup) that those files shouldn’t be restored.
  • Back up to a folder on the destination volume It won’t be bootable, but depending on what you require, that might be OK.

But since your destination volume is APFS already making a new volume in the same container will give you the best of both worlds. The backup volume will be separate from your data, and the pool of free space will be shared between the two volumes.

One final note: If you are backing up Catalina or Big Sur, then the destination device will have at least two volumes - the system volume and the data volume. It will probably also contain a clone of your (hidden) EFI, Recovery and VM volumes.

1 Like

Thanks Simon.

Alas, no, I’ve always struggled with such things because it’s hard to do enough testing to be comfortable with specific recommendations and then keep that up as the field evolves.

@ace Good point but at the same time there is a wealth of knowledgeable people here that can help balance that concern. Also, perhaps with a caution (like we don’t know? lol) that the opinions expressed are strictly those of the people posting. I have found so many threads here of great value and when I follow through exploring recommendations I figure it is up to me to do due diligence in assessing whatever is recommended. Besides, I have so many wonderful reminders as I go out online that are offered by Amazon, Walmart, fountain pen sites I’ve visited, and I know those are so reliable :wink:

I do really appreciate your editorial caution though.


A post was split to a new topic: Installing a different version of macOS in Recovery