does Time Machine notify _before_ deleting the "oldest" backup

My question is

-- does it notify _before_ deleting the oldest weekly back-up

...

Will Time Machine notify me _before_ it deletes the oldest weekly back-up,

so I can archive the disk and start a new one?

The answer to those questions is no.

Key aspects of Time Machine:

1. Time Machine guarantees an absolute minimum of one and only one complete, restorable backup. More than that is "nice to have" but not guaranteed.
2. It is completely normal and to be expected that Time Machine will require an entire backup disk's capacity. It does so to the extent it is possible to keep those older backups. Therefore it does not matter how full the backup disk becomes. It will eventually become full and will remain full as it continues to create new backups.
3. If you delete an item from the source volume, it becomes a candidate for deletion when Time Machine needs the space required for its absolute minimum of one and only one complete, restorable backup.
4. Time Machine does not delete older backups until after successfully creating a newer one. For this reason it can only approach becoming 100% full, but any attempt to determine just close it can get to that value or any other would be an exercise in futility.

I see where this is potentially going.

Then have a few suggestions ;

1 - Get Support Choose a product and we’ll find you the best solution.Start now and open an Apple Support Ticket as they are Apple Employees to deal will these types of issues . 

2 - Product Feedback - Apple and make it known to Apple regarding this issue 

Have taken enough of the users time

Good luck with this issue

This is the first of two longwinded replies so be sure to read the one that follows next.

bob24 wrote:

-- my (clearly incomplete) understanding is that Apple has made some System files completely inaccessible for modification by the user and applications

That is correct.

After years of slowly moving in that direction, macOS "Catalina" finally adopted the iOS approach of completely separating the operating system from the user space. It now exists on its own dedicated and secure "read only" signed system volume — isolated, cryptographically protected, and totally inaccessible to the user. If, through some (effectively impossible) means, an alteration to that volume is attempted such an attempt will fail. Not only is any nonconforming code rejected, any single solitary nonconforming byte is rejected.

That's more information than you asked for, but is one aspect of macOS that makes Macs the most secure consumer grade computing products on the planet, by far.

- are those files in Time Machine or is the "complete restorable backup" require a fresh install of macOS -- and then it will restore everything under the user / applications control

-- and if that is the primary / reliable goal of Time Machine

A traditional TM "restore" will restore everything in the user space as it always has, but since macOS itself exists on that separate SSV restoring macOS itself can only be accomplished by reinstalling it as a separate step. Recover all your files from a Time Machine backup - Apple Support was amended in recent macOS versions to draw attention to that fact. Fortunately it is only necessary to reinstall macOS when replacing the storage volume (hardware), or to fix some other problem in which that volume is suspected to have become corrupted — also a hardware problem.

is there any clear benefit to having both TimeMachine and Carbon Copy Cloner

I really don't think so. I used CCC in the distant past, but those recent macOS changes have made it unnecessary or no longer advantageous. TM is all that is required, as long as you have multiple redundant backups.

There is nothing wrong with using CCC, but no matter which backup method works best for you, you need more than just one. Any device can fail at any time, including the TM backup disk. Besides, if the disk is physically connected to the Mac, a damaging electrical anomaly can simultaneously affect both of them. Even if it's on a wireless network, a major catastrophe such as a flood or fire can affect a Mac and its backup. That means you need at least two backup disks, with one of them geographically distant from the other at all times.

But since they have to be near each other when backing up, guess what that means: a really robust backup strategy needs at least three backup disks.

"delete an item for the source volume, it becomes a candidate for deletion"

-- the Trash does not show in time Machine

- are items visible in the Trash also in Time Machine but only visible on the last date before deletion

-- or does Time Machine consider even things still visible in the Trash as "candidates for deletion"

The Trash is not viewable in the "Enter TM" interface, but a complete TM "restore" will restore the Trash.

"candidate for deletion"

-- how does Time Machine handle files that are simply moved

I have always assumed that they consume only one spot in Time Machine

that the pointer to the file is simply reset

-- is there a defined order in which the candidates are actually deleted?

Yes. The TM launch screen you quoted in your original post describes what it does in Apple's typically very brief but very accurate style. As backups age, you will only be able to restore the first backup of every hour, day, or week... in that order.

Yes, files are only backed up once and consume only one "spot". Changes to them are recorded as changes occur.

Applications

-- the risk of accidentally deleting an Application is small

and I would never restore a corrupt Application from Time Machine

I would delete and reinstall

-- Is there any benefit in letting Time Machine back-up Applications?

Yes. Bear in mind there is only one copy of an item backed up, so additional incremental backups don't take any more space. Apps themselves change only when they are updated, which isn't very often compared to work products like movies or documents.

When you look at the aggregate size of your Applications folder (for example) you will realize it doesn't occupy that much space compared to the backup drive capacity — which ought to be at least 2 TB for casual users.

Of course you can exclude it if you want though. Doesn't seem worth the effort to me.

Continued in the next reply.

In practice on any of my machines ( 3 ) Time Machine Backup Automatically deletes older Snap Shots as Space is required.

The Required Empty Space is calculated by the Time Machine Backup Utility.

If the user what to remove the worry of Older Snap Shot being automatically removed, suggest getting another External Drive with at least 2 1/2 Greater Drive Capacity than the Internal Drive.

The start that new drive as the dedicated drive for TM Backups.

Set aside the existing drive in a fafe place like Safety Deposit Box of Bank for future needs or repurposing at a later time.

In case this aspect may have been over looked, here it is again

" Automatically deletes older Snap Shots as Space is required."

In which case - get another drive and start a New Regime on the New Drive

You don't get the warning until after. Time Machine is a backup, not an archive. If you have a 1 TB drive with Time Machine backups that you want to keep, better disconnect it.

1 TB is pretty small anyway. Time to get a new one.

Reply part 2 of 2:

And finally some purely operational questions

-- do you recommend a particular ratio of GB being backed up to GB on the Time Machine volume

-- assuming your Time Machine volume is working

given the complexity of the TimeMachine read write move actions

is there a time duration that inclines you to just reinitialize the Time Machine volume and start fresh

Calculating that ratio with any degree of accuracy is not feasible, which is why most people default to the standard answer of "at least two or three times the size of the source". Like most "rules of thumb" it exists primarily to get people off the help desk phone so that they can move on to other callers waiting on hold.

The calculation is as follows: a TM backup volume capacity must be large enough to hold one complete backup of its source volume's contents, plus sufficient capacity to back up everything that changed since the last backup, plus a sufficient amount of "overhead" that is not easily calculated, and is a function of the total number of files that have changed in addition to their sizes. TM performs that calculation prior to even starting a backup, then it adds a generous amount of extra to be reasonably sure it can finish.

In very rare cases the above calculation is wrong, TM cannot finish, and it will throw the very unwelcome "Time Machine could not complete the backup" error alleging the backup drive is too small. This of course leads to understandable confusion and anger especially if the user the TM backup drive performs due diligence and concludes the backup drive should only be about half full. It happens. The bottom line is that if TM tells you it needs more space, it needs more space. The aforementioned "rule of thumb" is — usually — adequate, even if it lacks mathematical justification.

Finally: When a drive accumulates a backup history of a year or more, I typically erase them and start a new set on that drive. The reason is twofold: even a modest TM backup will soon contain several hundred million tiny files, and managing them just gets unwieldy. It will start to take forever to "verify" that backup on a network or with Disk Utility. Besides, if I have not needed to restore a backed up file for many months, the likelihood of ever having to restore it approaches nil. And, it further reinforces the fact TM is not an archival system. 99% of my TM "restore" needs have been to restore the most recent backup — the only one it guarantees.

Obviously if there were critical changes at multiple points in the interval _between_ a given date time and the next available date and time (be it one hour, day, or week later) then those variations are not available. But what one does see is valid -- correct?

All correct. The idea of course is that you might want to restore a particular file that you erased, say, yesterday afternoon. As months and years pass, you might want to restore a file that you recall having last July, but the exact time or day becomes less important.

Naturally if you created a file on a Tuesday last July and erased it the next day, the logical inference is that you never intended to keep that file for long. But if you kept it for a week or more, it will be restorable. TM achieves its goal of keeping a potentially long history at the expense of some "granularity" so to speak.

I started using CCC in the days when it could provide an immediately bootable back-up. Those days are gone, but I have stayed with it. I have great respect and appreciation for the programmer (Mike Bombich) -- he is remarkably clear and transparent. I see your point that it is now redundant -- but I will probably leave going until I either need the drive or the next upgrade gets too expensive.

CCC is a good product and I give Mike Bombich a lot of credit for sticking with it after all these years. Many others have not. Apple's propensity to constantly refine or completely overhaul macOS has frustrated many a developer into throwing up their hands and concluding it's just not worth the effort — especially for something that they got paid $40 for eight years ago, for which users expect a lifetime of support.

In response to the operational recommendations

-- (What I consider) my archival program is CrashPlan -- which is set to make complete daily backups both to their servers (off-site) and to an external drive (on-site). On the rare occasion I have used it for specific files, it has been fully reliable. It is relatively pricey, but I appreciate the granularity of control it provides. (

The more options you have, the better. Too many people get caught by surprise with no recovery plan whatsoever. I'm just not enamored with a disaster recovery plan in dire circumstances that rely upon potentially tenuous Internet connections. I suppose if the Internet as a whole goes down we'll have more important things on our minds though.

Those are good questions, but to answer them in the detail you deserve will take some time I don't have at the moment. I'll follow up but it might not be until tomorrow.