Short answer: Time Machine is designed to delete old backups. Hourly ones survive a day, daily ones survive a month, and weekly ones survive until the disk fills up. Then the oldest go.
There is no setting for this. You cannot tell Time Machine to keep three years, and the only lever you have is the size of the disk.
This is documented behavior and it has not changed in years:
So the age of your oldest backup is decided by one thing: how much bigger the backup disk is than the data on your Mac, and how much that data churns. A 1 TB drive holding 900 GB of Mac gives you weeks. The same drive holding 200 GB gives you years. Nobody tells you which you have.
The one above. You will sometimes see "Time Machine deleted some older backups to make room" in Notification Center, and you will just as often see nothing, because the notification is easy to miss and easy to have turned off.
Check what actually survives:
tmutil listbackupsThat prints every backup on the mounted destination, oldest first. Read the dates down the left and the shape of the schedule is visible: a run of dailies at the end, weeklies before that, and a start date that is the real answer to how far back you can go.
Sometimes Time Machine abandons the existing history and starts fresh. A macOS upgrade, a repaired volume, a changed disk identifier, or a corrupted backup index can all do it. The old backups may still be on the disk taking up room while being unreachable from the restore interface.
tmutil listbackups against the destination shows what is still addressable. If the oldest
entry is a few days old on a drive you have used for two years, this is what happened.
On an APFS Mac, Time Machine also keeps snapshots on the internal disk, so you can restore something when the backup drive is not attached. They are kept for around 24 hours and they are deleted automatically when space is needed.
tmutil listlocalsnapshots /People find these, assume they are the backup, and then find them gone. They live on the same disk as the original, so a failed drive takes both. Useful for a mistake you notice this afternoon. Not a backup.
On a network destination all of your history lives inside one sparse bundle. Advice on the internet about backup problems very often ends in "delete the sparsebundle and start over", and doing that deletes every version you had in one action. The disk image errors have fixes that do not involve that, and they are worth trying first.
Honestly, very little.
What you cannot do is set a retention policy. No number of days, no minimum number of versions, no "keep the first backup of every month forever". The schedule at the top of this page is the whole interface.
It is for making a fixed disk last, and it is a reasonable answer to that. The problem is that the policy is invisible while it runs. The day you go looking for the version of a file from eight months ago is the day you learn how far back your disk actually reaches, and by then the answer is fixed.
Old versions stay until you decide otherwise. There is no counter that discards them at thirty days and no schedule that thins them behind your back.
When space does run short, the app asks, and it tells you what it would remove and how much that frees before anything happens. The plan is made first and carried out later, so a mistake in a rule stays recoverable for a week.
The main screen shows how far back the history reaches, which is the number this whole page is about. And restoring the newest backup is free on every tier, including after a license ends, so history is a convenience you pay for and getting your files back is not.
If you are staying with Time Machine, the useful thing to do today is run
tmutil listbackups, look at the first date, and decide whether that is far enough back for
you. The 3-2-1 rule covers the other half of the question, which is
what happens when the one disk holding all of it fails.
No. There is no setting, no defaults command that survives, and no supported way to pin a backup. The only levers are the size of the disk, how much you back up, and using more than one destination.
Run tmutil listbackups with the drive attached. The first line is the oldest backup you can still restore from. That date, and not the age of the drive, is your real history.
Yes, that is the designed behavior: the oldest backups go to make room for the newest one. It is also worth checking whether the disk is genuinely full, because the not enough space message is often about how it sizes the job, and not about free space.
No. They live on the same disk as the files they came from, they are kept for about a day, and they are deleted when the system wants space. They cover an accidental deletion this afternoon and nothing beyond that.
An update can invalidate the backup index and start a new chain. The old data is often still on the disk while being unreachable from the restore interface. tmutil listbackups tells you what is still addressable, and if the answer is only the last few days, the chain was restarted.
Related: Time Machine says there is not enough space, the 3-2-1 rule, and Copy Shelter and Time Machine compared.