Unable to finish Time Machine back up on macOS Sequoia

Update:

Yesterday I freed some space on my systen, which now 25 GB for free SSD space and 5 GB of free RAM.

I had to retry the backup after my external target disk had to be disconnected (I'm meanwhile travelling).

Still the backup process takes WAY TOO LONG.

Its initial estimation for remaining hours was 2 hours, which would have been perfectly okay.

Yet it quickly started increasing - after about an hour it said 6 hours.

Now, some 6 hours later, where it claims to have reached 50%, it tells me 8 hours.

The claim that the reason for the bad backup performance being litte free system SSD space is empirically wrong.

As I wrote, my system now has some 25 GB free space, which is 3 times the original amout,

but this did not change the exteremely bad performance at all!

The reason is clearly something different.

Taking little SSD space as a cheap excuse for unacceptably loooooog duration of a full TM backup does not work out.

It is misleading and just proves little technical clue about the acutal issue.

Apparently you did not get what I meant with the analogy I wrote above:

With this, I wannted to point out a different issue (apart from is painfully bad performance),

namely that its estimations on how long the full backup is going to take goes entirely wrong!

Which is another indication of poor software quality of the Time Machine backup.

Trying out an alternative backup solution for comparison is good.

I had already done so, in order to get at least some full backup in reasonable time.

I've simply used `rsync -ax`. It works about 4-5 times faster than Time Machine.

Update: the estimated remaining time for the full backup went up to one week!

Meanwhile it is back to 'just' 3 days.

Which is still way too much.

Time Machine backup so far took about 2 days to write so far nearly 100 GB.

Utterly bad performance.

And still no real explanation for the reason.

BTW, supposedly unlike most others I selected encryption of the backup target,

but this should not have any noticeable impact on performance.

Instead, target disk write speed should be the predominant factor.

I meanwhile noticed very bad behavior when copying files, at least from HFS+ to APFS, which can explain part of the wrong estimations of remaining backup time by TM:

If the source file is very large, while reading or writing the file, it appears to grow indefinitely!

I experienced this with a 3.5 GB file and a 105 GB file.

This happens also when using sync, cp, or mv.

This must be due to a bug in at least one of the mentioned Apple file systems.

This makes no sense.

The (initial) backup is just painfully - and needlessly - slow.

There is no good reason for it to take more than a couple of hours at most.

BTW, when a backup is interrupted, it can not get resumed later.

Which also indicates bad design and major waste of disk space.

What a waste of resources.

And the backup process does not warn about its space greediness and its terrible performance when not granted that much space.

How would your boss react if, for a clearly defined task you started to do, each time he asks you how much time you still need to complete it, you keep increasing the estimate?