Sierra's Time Machine's backups slower?

[Ant]

Hello.

Is it me or is Time Machine's back up slower in Mac OS Sierra v10.12.4?
Even if it is only about 100 MB to back up! It is a lot slower than Mac
OS X v10.8.5 (Mountain Lion) with the same exact hardwares (13.3" MBP
from 2012) and an external USB2 Seagate 512 GB HDD. I even tried
repartitioning and reformatting the drives in the external HDD (400 GB
encrypted journal + 100 GB exFAT), and making a brand new back up from
scratch.

Thank you in advance. :)
--
Quote of the Week: "You feel the faint grit of ants beneath your shoes,
but keep on walking because in this world you have to decide what you're
willing to kill." --Tony Hoagland from "Candlelight"
Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
/\___/\ Ant(Dude) @ http://antfarm.home.dhs.org (Personal Web Site)
/ /\ /\ \ Ant's Quality Foraged Links: http://aqfl.net
| |o o| |
\ _ / Please nuke ANT if replying by e-mail privately. If credit-
( ) ing, then please kindly use Ant nickname and AQFL URL/link.

[nospam]

In article <W8adnbDAZoPzD2LF...@earthlink.com>, Ant

<ANT...@zimage.com> wrote:

>
> Is it me or is Time Machine's back up slower in Mac OS Sierra v10.12.4?

you

[Snit]

On 4/25/17, 11:17 AM, in article 250420171417316947%nos...@nospam.invalid,

I have never found Time Machine to back me up at all... only my computer's
drive. :)

But, no, I have not found it to be slower with Sierra.

--
Personal attacks from those who troll show their own insecurity. They cannot
use reason to show the message to be wrong so they try to feel somehow
superior by attacking the messenger.

They cling to their attacks and ignore the message time and time again.

<https://youtu.be/H4NW-Cqh308>

[Andre G. Isaak]

In article <W8adnbDAZoPzD2LF...@earthlink.com>,

ANT...@zimage.com (Ant) wrote:

> Hello.
>
> Is it me or is Time Machine's back up slower in Mac OS Sierra v10.12.4?
> Even if it is only about 100 MB to back up! It is a lot slower than Mac
> OS X v10.8.5 (Mountain Lion) with the same exact hardwares (13.3" MBP
> from 2012) and an external USB2 Seagate 512 GB HDD. I even tried
> repartitioning and reformatting the drives in the external HDD (400 GB
> encrypted journal + 100 GB exFAT), and making a brand new back up from
> scratch.

I've found that in very rare instances, Sierra will take an abnormally
long time to complete even a relatively small backup. I've never been
successful in determining exactly what the cause of these slowdowns are,
though my suspicion is that it involves a closed file scheduled for
backup being opened while the backup is in progress. I've seen this
occur maybe once every few months.

That being said, I've not noticed any difference in the *normal* time it
takes for sierra to do backups.

Note that a particularly long backup, while perplexing, doesn't really
result in any sort of performance hit on the system, so I haven't really
worried about this.

Andre

--
To email remove 'invalid' & replace 'gm' with well known Google mail service.

[David Empson]

Andre G. Isaak <agi...@gm.invalid> wrote:

> In article <W8adnbDAZoPzD2LF...@earthlink.com>,
> ANT...@zimage.com (Ant) wrote:
>
> > Is it me or is Time Machine's back up slower in Mac OS Sierra v10.12.4?
> > Even if it is only about 100 MB to back up! It is a lot slower than Mac
> > OS X v10.8.5 (Mountain Lion) with the same exact hardwares (13.3" MBP
> > from 2012) and an external USB2 Seagate 512 GB HDD. I even tried
> > repartitioning and reformatting the drives in the external HDD (400 GB
> > encrypted journal + 100 GB exFAT), and making a brand new back up from
> > scratch.
>
> I've found that in very rare instances, Sierra will take an abnormally
> long time to complete even a relatively small backup. I've never been
> successful in determining exactly what the cause of these slowdowns are,
> though my suspicion is that it involves a closed file scheduled for
> backup being opened while the backup is in progress. I've seen this
> occur maybe once every few months.

Did you have long delays between backups to the same drive, in the order
of days?

If there is a long enough gap between consecutive backups, TM cannot use
the OS's cached list of folders with recent changes (because old entries
have expired), and instead has to do a full scan of the source drive and
compare the list of files to the last backup on that TM drive.

The time required to trigger this probably depends on the rate at which
folders are changing on your source drive, because the cache has a
limited number of entries. I see this sort of full scan when
reconnecting my occasionally updated second TM backup drive after more
than about two weeks.

There are also some events which force TM to do a full scan, e.g. if the
identity of the source drive or backup drive has changed.

> That being said, I've not noticed any difference in the *normal* time it
> takes for sierra to do backups.

Same here.

--
David Empson
dem...@actrix.gen.nz

[Andre G. Isaak]

In article <1n53swa.ty5yhv1uib5rwN%dem...@actrix.gen.nz>,

My Time Machine backups alternate between two drives, and both are
always connected so I doubt there's ever a day in which both drives
aren't backed up to multiple times (and I dare anyone to try and fix
that stranded preposition). Since I'm rarely away from the computer for
even a single day I doubt that's the issue.

I'm backing up both my internal drive (3TB - less than 1TB used) and an
external Thunderbolt Drive (4TB, about 3TB used) to 2 external 8TB USB
drives. Not sure if backing up multiple drives should make a difference.

As I said, this happens very infrequently, so I'm not terribly concerned
about it. More just curious...

[Lewis]

In message <W8adnbDAZoPzD2LF...@earthlink.com> Ant <ANT...@zimage.com> wrote:
> Hello.

> Is it me or is Time Machine's back up slower in Mac OS Sierra v10.12.4?
> Even if it is only about 100 MB to back up! It is a lot slower than Mac
> OS X v10.8.5 (Mountain Lion) with the same exact hardwares (13.3" MBP
> from 2012) and an external USB2 Seagate 512 GB HDD. I even tried
> repartitioning and reformatting the drives in the external HDD (400 GB
> encrypted journal + 100 GB exFAT), and making a brand new back up from
> scratch.

It's been several years since I noticed a time Machine backup at all. I
am certainly not sitting there watching them.


--
Personal isn't the same as important. What sort of person could think
like that? And it dawned on him that while Ankh in the past had had its
share of evil rulers, and simply bad rulers, it had never yet come under
the heel of a good ruler. That might be the most terrifying prospect of
all. --Men at Arms

[Niels Jørgen Kruse]

Time Machine gets very slow when it has to delete old backups. The
oldest backup is slow to delete, possibly because it is mostly actual
files and not fake hardlinks.

--
Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark

[Andre G. Isaak]

In article <1n53w4s.a8tohs1unrh8xN%nj_k...@me.com>,

That isn't the issue here -- neither backup drive has filled up yet.

[Niels Jørgen Kruse]

Andre G. Isaak <agi...@gm.invalid> wrote:

> In article <1n53w4s.a8tohs1unrh8xN%nj_k...@me.com>,
> nj_k...@me.com (Niels Jørgen Kruse) wrote:
>
> > Andre G. Isaak <agi...@gm.invalid> wrote:
> >
> > > My Time Machine backups alternate between two drives, and both are
> > > always connected so I doubt there's ever a day in which both drives
> > > aren't backed up to multiple times (and I dare anyone to try and fix
> > > that stranded preposition). Since I'm rarely away from the computer for
> > > even a single day I doubt that's the issue.
> > >
> > > I'm backing up both my internal drive (3TB - less than 1TB used) and an
> > > external Thunderbolt Drive (4TB, about 3TB used) to 2 external 8TB USB
> > > drives. Not sure if backing up multiple drives should make a difference.
> > >
> > > As I said, this happens very infrequently, so I'm not terribly concerned
> > > about it. More just curious...
> >
> > Time Machine gets very slow when it has to delete old backups. The
> > oldest backup is slow to delete, possibly because it is mostly actual
> > files and not fake hardlinks.
>
> That isn't the issue here -- neither backup drive has filled up yet.

Do you have backups very far back then? Much more than a year also cause
slowdown in my experience.

[nospam]

In article <1n53w4s.a8tohs1unrh8xN%nj_k...@me.com>, Niels Jørgen Kruse

<nj_k...@me.com> wrote:

>
> > My Time Machine backups alternate between two drives, and both are
> > always connected so I doubt there's ever a day in which both drives
> > aren't backed up to multiple times (and I dare anyone to try and fix
> > that stranded preposition). Since I'm rarely away from the computer for
> > even a single day I doubt that's the issue.
> >
> > I'm backing up both my internal drive (3TB - less than 1TB used) and an
> > external Thunderbolt Drive (4TB, about 3TB used) to 2 external 8TB USB
> > drives. Not sure if backing up multiple drives should make a difference.
> >
> > As I said, this happens very infrequently, so I'm not terribly concerned
> > about it. More just curious...
>
> Time Machine gets very slow when it has to delete old backups.

no it doesn't.

> The
> oldest backup is slow to delete, possibly because it is mostly actual
> files and not fake hardlinks.

also wrong.

[android]

In article <260420171645581830%nos...@nospam.invalid>,

Nothing beats a good cloning schedule for backups. You don't have to
watch the 'putter while it does its things...
--
teleportation kills

[nospam]

In article <here-540130.0...@news.individual.net>, android

<he...@there.was> wrote:

> > >
> > > > My Time Machine backups alternate between two drives, and both are
> > > > always connected so I doubt there's ever a day in which both drives
> > > > aren't backed up to multiple times (and I dare anyone to try and fix
> > > > that stranded preposition). Since I'm rarely away from the computer for
> > > > even a single day I doubt that's the issue.
> > > >
> > > > I'm backing up both my internal drive (3TB - less than 1TB used) and an
> > > > external Thunderbolt Drive (4TB, about 3TB used) to 2 external 8TB USB
> > > > drives. Not sure if backing up multiple drives should make a difference.
> > > >
> > > > As I said, this happens very infrequently, so I'm not terribly concerned
> > > > about it. More just curious...
> > >
> > > Time Machine gets very slow when it has to delete old backups.
> >
> > no it doesn't.
> >
> > > The
> > > oldest backup is slow to delete, possibly because it is mostly actual
> > > files and not fake hardlinks.
> >
> > also wrong.
>
> Nothing beats a good cloning schedule for backups. You don't have to
> watch the 'putter while it does its things...

nor do you with time machine.

[android]

In article <270420170039597801%nos...@nospam.invalid>,

So you can boot from a TM backup? And it never fails?
--
teleportation kills

[Alan Baker]

No...

...but you can restore from a TM backup and then boot.

[android]

In article <odrtn6$l3n$1...@gioia.aioe.org>,

That won't help you out if you have a HD failure.

Let me add that any backup should be rotated. Like storing daily, weekly
and monthly clones. Or something like that. Copies off site is good if
you can arrange for it.
--
teleportation kills

[Alan Baker]

Not in an instant, it won't, but if you have another HD (or can buy one
just up the street), you can quickly solve that problem.

>
> Let me add that any backup should be rotated. Like storing daily, weekly
> and monthly clones. Or something like that. Copies off site is good if
> you can arrange for it.

Preaching to the choir, here.

You can do that with TM you know...

[Lewis]

Hard links and "actual" files are the same exact thing.

--
What was it they said about gods? They wouldn't exist if there weren't
people to believe in them? And that applied to everything. Reality was
what went on inside people's heads. --Moving Pictures

[Lewis]

Yes it will.

> Let me add that any backup should be rotated. Like storing daily, weekly
> and monthly clones. Or something like that. Copies off site is good if
> you can arrange for it.

Time Machine already rotates backups,

--
'We'll never make it alive!' CORRECT. --Small Gods

[Andre G. Isaak]

In article <slrnog3fea....@snow.local>,

Lewis <g.k...@gmail.com.dontsendmecopies> wrote:

> In message <1n53w4s.a8tohs1unrh8xN%nj_k...@me.com> Niels Jørgen Kruse
> <nj_k...@me.com> wrote:
> > Andre G. Isaak <agi...@gm.invalid> wrote:
>
> >> My Time Machine backups alternate between two drives, and both are
> >> always connected so I doubt there's ever a day in which both drives
> >> aren't backed up to multiple times (and I dare anyone to try and fix
> >> that stranded preposition). Since I'm rarely away from the computer for
> >> even a single day I doubt that's the issue.
> >>
> >> I'm backing up both my internal drive (3TB - less than 1TB used) and an
> >> external Thunderbolt Drive (4TB, about 3TB used) to 2 external 8TB USB
> >> drives. Not sure if backing up multiple drives should make a difference.
> >>
> >> As I said, this happens very infrequently, so I'm not terribly concerned
> >> about it. More just curious...
>
> > Time Machine gets very slow when it has to delete old backups. The
> > oldest backup is slow to delete, possibly because it is mostly actual
> > files and not fake hardlinks.
>
> Hard links and "actual" files are the same exact thing.

Time Machine relies not only on hard linked files, but also on hard
links to directories. Most file systems don't allow this because it
creates all sorts of potential problems (recursive directories, orphaned
subtrees, etc.). Apple does its best to avoid this issues by making it
extremely difficult for anything other than time machine to create or
manipulate multiply-linked directories.

Deleting a time-machine backup is considerably slower than deleting a
comparably sized group of files, and I assume the reason for this is
that the OS performs consistency checks when deleting multiply-linked
folders.

[nospam]

In article <odrtn6$l3n$1...@gioia.aioe.org>, Alan Baker
<alang...@telus.net> wrote:

> >>>

> >>> Nothing beats a good cloning schedule for backups. You don't have to
> >>> watch the 'putter while it does its things...
> >>
> >> nor do you with time machine.
> >
> > So you can boot from a TM backup? And it never fails?
> >
>
> No...
>
> ...but you can restore from a TM backup and then boot.

directly attached time machine backups are bootable since lion.

[Alan Baker]

Forgot that... ...right.

[Jolly Roger]

My goodness... You poor ignorant thing! You just can't seem to get
anything right. Bless your little heart!

No, Time Machine *doesn't* get "very slow" when it deletes old backups.
To wit, here's a sample where 1.27GB of new/changed data was backed up,
and where 446.5 MB of stale backups were deleted in only 12 minutes -
over the network:

Apr 27 03:18:52 server com.apple.backupd[32191]: Backing up to
/dev/disk5s2: /Volumes/Time Machine Backups/Backups.backupdb
Apr 27 03:18:53 server com.apple.backupd[32191]: Disk image
/Volumes/server (Time)/server.sparsebundle mounted at: /Volumes/Time
Machine Backups
Apr 27 03:20:14 server com.apple.backupd[32191]: Will copy (1.27 GB)
from Server
Apr 27 03:20:14 server com.apple.backupd[32191]: Found 32797 files (1.27
GB) needing backup
Apr 27 03:20:14 server com.apple.backupd[32191]: 3.87 GB required
(including padding), 300.43 GB available
Apr 27 03:29:14 server com.apple.backupd[32191]: Copied 32756 items
(1.27 GB) from volume Server. Linked 22314.
Apr 27 03:29:20 server com.apple.backupd[32191]: Created new backup:
2017-04-27-032920
Apr 27 03:29:25 server com.apple.backupd[32191]: Starting post-backup
thinning
Apr 27 03:30:30 server com.apple.backupd[32191]: Deleted /Volumes/Time
Machine Backups/Backups.backupdb/server/2017-01-26-030132 (446.5 MB)
Apr 27 03:30:30 server com.apple.backupd[32191]: Post-backup thinning
complete: 1 expired backups removed
Apr 27 03:30:30 server com.apple.backupd[32191]: Backup completed
successfully.

So... The backup of new data took nine minutes, and the deletion of the
old backup took less than one minute. Imagine that.

And no, old backups aren't "mostly actual files and not fake hardlinks"
either.

And yes, you definitely can boot from Time Machine backups. I've done it
plenty of times.

So much wrong. So much fail. Pity. Contrary to your ignorant claims,
Time Machine is extremely elegant and reliable. You quite literally set
it and forget it. Then when you finally do need to restore, your data is
there. Maybe if you actually used it you might know that.

Aren't you the same dingbat who thinks it's a great idea to spam
multiple disparate news groups (rec.photo.digital, alt.photography,
comp.sys.mac.system, comp.sys.mac.apps, and comp.sys.mac.comm) multiple
times a month with your lame "Derrrrr, huh-huh-huh, let me edumacate you
all about basic Usenet etiquette you already know: This is The Usenet:
Basic Usenet and News Facts" posts? Yeah, people just love, love, love
you for all of the pure noise and misinformation you contribute here!
Believe it; and boy have I got a nice bridge to sell you! ; )

Keep trying, little guy! Once day maybe you'll finally get *something*
right... : D

--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[JF Mezei]

On 2017-04-27 07:49, Andre G. Isaak wrote:

> Deleting a time-machine backup is considerably slower than deleting a
> comparably sized group of files, and I assume the reason for this is
> that the OS performs consistency checks when deleting multiply-linked
> folders.

I view it differently:

Why does Time Machine need to delete ? to free space.


Say File1.txt has remained unchanged for 6 months or 180 days/backups.
So you have one copy of file1.txt with 180 directory entries pointing to it.

Deletting the January 1 backup won't free up space used by File1.txt, it
merely decrements the "number of entries" counter for the file to 179.
You then have to go and delete the Jan 2 backup etc etc.

So you have to loop through al backups (oldest to newest) deleting all
files in each until you have enough free space. Since vast majority of
file entries in a daily backup have a "count" higher than 1, deleting
them won't cause freeing of disk space, so you have to delete a whole
lot of file entries just to free up a certain amount of disk space.

So it may end up deleteing say 10,000 file entries without freeing any
disk space because those files are also used in the next day's backup.
But there is still a cost in CPU/disk to do that operation which yields
no new disk space.

I have to assume that Apple does tricks when it comes to hard links for
directories. If jan1/Recipes/ directory is a hard link that points to
same directory as jan2/Recipes, when you delete jan1/Recipes/File1.txt
it would normally also delete the entry from jan2/Recipes/file.txt which
isn't something you want. So Apple has to do some fancy legwork to
either create a new version of jan1/Recipes that it can then play with
(delete individual files until directory is empty) or don't remove files
from directory as you delete them and then just delete the non-empty
directory (in the above case, simply decrement its count since it is
also used in subsequent backups).

(the other option is that whenever you modify a directy whose count > 1,
you need to create its own local copy so you can change it without
affecting the copies that used to be linked together. This allows you do
perform normal delete operations that delete the file and the file entry
in the directory).


Looking at this, the new file system is likely going to provide a huge
iomprovement on this.

[Jolly Roger]

On 2017-04-27, JF Mezei <jfmezei...@vaxination.ca> wrote:
> On 2017-04-27 07:49, Andre G. Isaak wrote:
>
>> Deleting a time-machine backup is considerably slower than deleting a
>> comparably sized group of files, and I assume the reason for this is
>> that the OS performs consistency checks when deleting multiply-linked
>> folders.
>
> I view it differently:

Your view is based on ignorance and is therefore irrelevant.

> Say File1.txt has remained unchanged for 6 months or 180 days/backups.
> So you have one copy of file1.txt with 180 directory entries pointing to it.

Nope.

> Deletting the January 1 backup won't free up space used by File1.txt, it
> merely decrements the "number of entries" counter for the file to 179.

Nope. That's not how it works.

> You then have to go and delete the Jan 2 backup etc etc.

Nope. That's not how it works either.

> So you have to loop through al backups (oldest to newest) deleting all
> files in each until you have enough free space. Since vast majority of
> file entries in a daily backup have a "count" higher than 1, deleting
> them won't cause freeing of disk space, so you have to delete a whole
> lot of file entries just to free up a certain amount of disk space.
>
> So it may end up deleteing say 10,000 file entries without freeing any
> disk space because those files are also used in the next day's backup.

LOL! Wow... You're just pulling this straight out of your ass...

[remainder of clueless ramblings rightfully ignored]

You should really stick to talking about what you actually know.

[android]

In article <emel98...@mid.individual.net>,

Jolly Roger <jolly...@pobox.com> wrote:

> On 2017-04-27, android <he...@there.was> wrote:
> > In article <270420170039597801%nos...@nospam.invalid>,
> > nospam <nos...@nospam.invalid> wrote:
> >> In article <here-540130.0...@news.individual.net>, android
> >> <he...@there.was> wrote:
> >>
> >>>>> Time Machine gets very slow when it has to delete old backups.
> >>>>
> >>>> no it doesn't.
> >>>>
> >>>>> The oldest backup is slow to delete, possibly because it is mostly
> >>>>> actual files and not fake hardlinks.
> >>>>
> >>>> also wrong.
> >>>
> >>> Nothing beats a good cloning schedule for backups. You don't have to
> >>> watch the 'putter while it does its things...
> >>
> >> nor do you with time machine.
> >
> > So you can boot from a TM backup? And it never fails?
>
> My goodness... You poor ignorant thing! You just can't seem to get
> anything right. Bless your little heart!
>
> No, Time Machine *doesn't* get "very slow" when it deletes old backups.
> To wit, here's a sample where 1.27GB of new/changed data was backed up,
> and where 446.5 MB of stale backups were deleted in only 12 minutes -
> over the network:
>

[---]

>
> So... The backup of new data took nine minutes, and the deletion of the
> old backup took less than one minute. Imagine that.

Soo? I have not made any complaints on the speed of TM. You've
attributed the wrong person.

>
> And no, old backups aren't "mostly actual files and not fake hardlinks"
> either.

That is nothing that I've have written. You've attributed the wrong
person.

>
> And yes, you definitely can boot from Time Machine backups. I've done it
> plenty of times.

Good for you. I wouldn't trust it. There are way to many complaints of
failed TM backups on the net for that.
--
teleportation kills

[JF Mezei]

On 2017-04-27 14:31, Jolly Roger wrote:

> Nope. That's not how it works.

So pray tell, how does it work?

[Jolly Roger]

Ginormous hint: There's no need to recursively look at individual file and
folder sizes to figure out what to delete. There are these new-fangled
things called snapshots...

Want to know more? I'm not your secretary, One-Who-Never-Reads. If you
truly want to learn how Time Machine works, use the internet and your
brain, and learn like the rest of us.

[JF Mezei]

On 2017-04-27 15:32, Jolly Roger wrote:

> Ginormous hint: There's no need to recursively look at individual file and
> folder sizes to figure out what to delete. There are these new-fangled
> things called snapshots...

Folder sizes are irrelevant becaiuse deleting all files in folder does
not garantee you fee up the amount of disk space you calculated.

Also, you cannot selectively delete files. If Time Machine says you have
a backup dated 26-APR-2017 at 15:00, then that backup must contain all
files as of that time. You can't partially delete a backup to make space.

The issue isn't deleting a backup, the issue is removing actual files
which are used by many backups. Removing it from one backup doesn't free
the space.

> Want to know more? I'm not your secretary,

but you're the one who challenges my statement and unwilling to explain.

[Jolly Roger]

JF Mezei <jfmezei...@vaxination.ca> wrote:
> On 2017-04-27 15:32, Jolly Roger wrote:
>
>> Ginormous hint: There's no need to recursively look at individual file and
>> folder sizes to figure out what to delete. There are these new-fangled
>> things called snapshots...
>
> Folder sizes are irrelevant

Snapshot sizes are. Your claim that deleting a stale snapshot won't free
space is bullshit.

> Also, you cannot selectively delete files.

Irrelevant since we are talking about TIME MACHINE automatically deleting
stale backups.

> The issue isn't deleting a backup

Yes it is, since that's what we are talking about. You don't get to step in
and move the goal posts.

>> Want to know more? I'm not your secretary,
>

> but you're the one who challenges my statement and I will to explain

You made the claims. The onus to prove your own claims falls squarely on
your shoulders. If you can't back up your claims, we will rightly assume
you are blowing hot air.

[Jolly Roger]

Ah, okay. You're just replying to a sub-thread where someone claimed TM
is slow to talk about your own thing because you're such a stellar
proponent of Usenet etiquette, is that it? So much for leading by
example, I guess.

Conveniently you are mum when it comes to booting from TM volumes.
Nothing more to say on that one, eh? Thought we'd forget you said it
wasn't possible?

>> And no, old backups aren't "mostly actual files and not fake hardlinks"
>> either.
>
> That is nothing that I've have written. You've attributed the wrong
> person.

See above. You're not one to spam this news group repeatedly about
Usenet etiquette when you can't even bother to set a good example.
Replying to a sub-thread with an off-topic post is rude and frowned
upon.

>> And yes, you definitely can boot from Time Machine backups. I've done it
>> plenty of times.
>
> Good for you. I wouldn't trust it. There are way to many complaints of
> failed TM backups on the net for that.

Heh... As if that means anything. There are complaints about
*everything* on the net. I notice when I search Google for
"MTNewswatcher problem" there are over twenty thousand hits - yet here
you are using it. I guess you shouldn't trust it either, eh? Way too
many complaints!

[android]

In article <emfcri...@mid.individual.net>,

Jolly Roger <jolly...@pobox.com> wrote:

> Conveniently you are mum when it comes to booting from TM volumes.
> Nothing more to say on that one, eh? Thought we'd forget you said it
> wasn't possible?

That I did not say either...
--
teleportation kills

[Bruce Esquibel]

In comp.sys.mac.system nospam <nos...@nospam.invalid> wrote:

> directly attached time machine backups are bootable since lion.

Really?

Google "bootable time machine backup" and see the results.

They are bootable if you use CCC or SuperDuper to make a bootable volume,
then use it for a TM backup.

If someone just sticks a usb/fw/tb drive in and start using for TM, it's
not going to boot on it's own.

-bruce
b...@ripco.com

[Lewis]

In message <agisaak-389227...@88-209-239-213.giganet.hu> Andre G. Isaak <agi...@gm.invalid> wrote:
> In article <slrnog3fea....@snow.local>,
> Lewis <g.k...@gmail.com.dontsendmecopies> wrote:

>> In message <1n53w4s.a8tohs1unrh8xN%nj_k...@me.com> Niels Jørgen Kruse
>> <nj_k...@me.com> wrote:
>> > Andre G. Isaak <agi...@gm.invalid> wrote:
>>
>> >> My Time Machine backups alternate between two drives, and both are
>> >> always connected so I doubt there's ever a day in which both drives
>> >> aren't backed up to multiple times (and I dare anyone to try and fix
>> >> that stranded preposition). Since I'm rarely away from the computer for
>> >> even a single day I doubt that's the issue.
>> >>
>> >> I'm backing up both my internal drive (3TB - less than 1TB used) and an
>> >> external Thunderbolt Drive (4TB, about 3TB used) to 2 external 8TB USB
>> >> drives. Not sure if backing up multiple drives should make a difference.
>> >>
>> >> As I said, this happens very infrequently, so I'm not terribly concerned
>> >> about it. More just curious...
>>
>> > Time Machine gets very slow when it has to delete old backups. The
>> > oldest backup is slow to delete, possibly because it is mostly actual
>> > files and not fake hardlinks.
>>
>> Hard links and "actual" files are the same exact thing.

> Time Machine relies not only on hard linked files, but also on hard
> links to directories.

So?

> Deleting a time-machine backup is considerably slower than deleting a
> comparably sized group of files, and I assume the reason for this is
> that the OS performs consistency checks when deleting multiply-linked
> folders.

Perhaps. It could be for all sorts of reasons, but hard links is not one
of those reasons.

--
The hippo of recollection stirred in the muddy waters of the mind.

[Lewis]

In message <5902365e$0$8033$b1db1813$2411...@news.astraweb.com> JF Mezei <jfmezei...@vaxination.ca> wrote:
> On 2017-04-27 07:49, Andre G. Isaak wrote:

>> Deleting a time-machine backup is considerably slower than deleting a
>> comparably sized group of files, and I assume the reason for this is
>> that the OS performs consistency checks when deleting multiply-linked
>> folders.


> I view it differently:

Of course you do. I'm sure you'll share your complete lack of knowledge.

> Why does Time Machine need to delete ? to free space.

That's an astonishingly dumb question.

> Say File1.txt has remained unchanged for 6 months or 180 days/backups.
> So you have one copy of file1.txt with 180 directory entries pointing to it.

If only there were some way to tell how many links there were to a
file...

> So you have to loop through al backups (oldest to newest) deleting all
> files in each until you have enough free space.

I'm sure that's how YOU would do it. It's not how anyone else would do
it.

--
The Piper's calling you to join him

[Lewis]

In message <odv845$ehi$1...@remote5bge0.ripco.com> Bruce Esquibel <b...@ripco.com> wrote:
> In comp.sys.mac.system nospam <nos...@nospam.invalid> wrote:

>> directly attached time machine backups are bootable since lion.


> Really?

> Google "bootable time machine backup" and see the results.

Don't need to. I have computers with bootable time machine backups.

> They are bootable if you use CCC or SuperDuper to make a bootable volume,
> then use it for a TM backup.

Nope. You are wrong.

> If someone just sticks a usb/fw/tb drive in and start using for TM, it's
> not going to boot on it's own.

Yes it is.

--
I have NOT lost my mind! I've got a backup around here somewhere.

[nospam]

In article <odv845$ehi$1...@remote5bge0.ripco.com>, Bruce Esquibel

<b...@ripco.com> wrote:

>
> > directly attached time machine backups are bootable since lion.
>
> Really?

really.

> Google "bootable time machine backup" and see the results.

completely meaningless.

google 'flat earth' and see the results.

> They are bootable if you use CCC or SuperDuper to make a bootable volume,
> then use it for a TM backup.

there is no need for either of those.

> If someone just sticks a usb/fw/tb drive in and start using for TM, it's
> not going to boot on it's own.

yes it absolutely will, assuming lion or later, as i said.

[Jolly Roger]

You insinuated it, which is on record:

On 2017-04-27, android <he...@there.was> wrote:
> In article <270420170039597801%nos...@nospam.invalid>,
> nospam <nos...@nospam.invalid> wrote:
>> In article <here-540130.0...@news.individual.net>, android
>> <he...@there.was> wrote:
>>
>>> Nothing beats a good cloning schedule for backups. You don't have to
>>> watch the 'putter while it does its things...
>>
>> nor do you with time machine.
>
> So you can boot from a TM backup? And it never fails?

Run, Forest, run from your own words! ; )

Gosh... You must be tired of all this "winning" by now, you poor thing!
: D

[android]

In article <emh82e...@mid.individual.net>,

Jolly Roger <jolly...@pobox.com> wrote:

> On 2017-04-28, android <he...@there.was> wrote:
> > In article <emfcri...@mid.individual.net>,
> > Jolly Roger <jolly...@pobox.com> wrote:
> >
> >> Conveniently you are mum when it comes to booting from TM volumes.
> >> Nothing more to say on that one, eh? Thought we'd forget you said it
> >> wasn't possible?
> >
> > That I did not say either...
>
> You insinuated it, which is on record:
>
> On 2017-04-27, android <he...@there.was> wrote:
> > In article <270420170039597801%nos...@nospam.invalid>,
> > nospam <nos...@nospam.invalid> wrote:
> >> In article <here-540130.0...@news.individual.net>, android
> >> <he...@there.was> wrote:
> >>
> >>> Nothing beats a good cloning schedule for backups. You don't have to
> >>> watch the 'putter while it does its things...
> >>
> >> nor do you with time machine.
> >
> > So you can boot from a TM backup? And it never fails?
>
> Run, Forest, run from your own words! ; )
>

That makes big sense...
--
teleportation kills

[JF Mezei]

>> directly attached time machine backups are bootable since lion.

Yosemite:

Diskutil list for the Time Machine backup disk

> /dev/disk1
> #: TYPE NAME SIZE IDENTIFIER
> 0: GUID_partition_scheme *2.0 TB disk1
> 1: EFI EFI 209.7 MB disk1s1
> 2: Apple_HFS DMA6 2.0 TB disk1s2

There is no recovery partition.

HOWEVER:

Two relevant files at the root of the TM backup drive:

drwxr-xr-x+ 6 root wheel 204 Jun 17 2016 Backups.backupdb
-rwxr-xr-x@ 1 root wheel 115716 May 10 2015 tmbootpicker.efi


The backupdb is the directory containing all the directories of backups
by date.

What is likely is that the disk has the tmbootpicker.efi file as the
blessed "boot loader" and that file likely has code that chooses a
directory in the .backupdb that contains the system.

What is not clear to me is how it chooses it. (the latest backup might
be corrupt and you don't want to boot from it, and the oldest backup may
not have more recent version of OS.).

However, judging from the name "tmbootpicker", it is likely that it
presents a menu to allow one to choose what to boot from.

[JF Mezei]

On 2017-04-28 07:19, Lewis wrote:

> If only there were some way to tell how many links there were to a
> file...

Knowing there are 180 directory entries pointing to File1.txt is easy.
And depending on the file system, if the actual file entry has
backpointers, you may also easily find out in which directories and
under which name these 180 entries are.

So if you wish to delete all references to file1.txt, you can do it by
finding all references to it and deleting it. That will free up the
disk space occupied by file1.txt. But also make 180 backups corrupt
since they will be incomplete.

When Time Machine needs free space, it does not and cannot decide to
make a whole buchh of backsups corrupt by arbritrarily deleteing one or
two files of its choice. It needs to eliminate full backups from oldest
to newest backups until enough space has been freed.

And this is where it can get very IO intensive if deleting the oldest
backup merely results in a whole buch of directory updates to remove
fiule entries without freeing any space because these files are all used
by subsequent backups.

The IO happens on the backup drive, so depending on the disk system you
have, it may or may not impact IOs to the others disks on your machine.

If your TM backup is on USB, I doubt it would impact SATA drives or PICe
SSDs since they use different interconnects.

[Jolly Roger]

On 2017-04-28, JF Mezei <jfmezei...@vaxination.ca> wrote:
>
> When Time Machine needs free space, it does not and cannot decide to
> make a whole buchh of backsups corrupt by arbritrarily deleteing one or
> two files of its choice. It needs to eliminate full backups from oldest
> to newest backups until enough space has been freed.

You are pulling this straight out of your ass. To prove it: Show us one
citation showing that this is how Time Machine works.

[David Empson]

JF Mezei <jfmezei...@vaxination.ca> wrote:

> >> directly attached time machine backups are bootable since lion.
>
>
> Yosemite:
>
> Diskutil list for the Time Machine backup disk
>
> > /dev/disk1
> > #: TYPE NAME SIZE IDENTIFIER
> > 0: GUID_partition_scheme *2.0 TB disk1
> > 1: EFI EFI 209.7 MB disk1s1
> > 2: Apple_HFS DMA6 2.0 TB disk1s2
>
> There is no recovery partition.
>
> HOWEVER:
>
> Two relevant files at the root of the TM backup drive:
>
> drwxr-xr-x+ 6 root wheel 204 Jun 17 2016 Backups.backupdb
> -rwxr-xr-x@ 1 root wheel 115716 May 10 2015 tmbootpicker.efi
>
>
> The backupdb is the directory containing all the directories of backups
> by date.
>
> What is likely is that the disk has the tmbootpicker.efi file as the
> blessed "boot loader" and that file likely has code that chooses a
> directory in the .backupdb that contains the system.

Partly correct. I vaguely remember posting something about this a while
ago. I don't have time to look up the deatils now, but here is a quick
summary from memory:

There is a hidden folder in the Backups.backupdb folder with a name
something like ".RecoverySets", which contains numbered subfolders (0,
1, ...), typically only "0" is required. Each of those has a backup of a
recovery partition (as a folder/file hierarchy), which contains details
about Mac models which are supported by that instance of the recovery
partition. tmbootpicker looks up the identification details from the
computer and picks the appropriate recovery partition backup, then boots
from that.

TM backs up the recovery partition automatically, including backing up
changes to it (e.g. after an Apple update). If you start backing up a
different computer to the same drive, TM might need to create another
numbered recovery partition backup - I ended up with two of them when I
replaced my previous Mac with my current one and kept using the same TM
backup drive, because the originally backed up recovery partition did
not support the new model.

> What is not clear to me is how it chooses it. (the latest backup might
> be corrupt and you don't want to boot from it, and the oldest backup may
> not have more recent version of OS.).

A TM drive boots into a backup of the recovery partition. It does NOT
boot into a working copy of your main system.

This means that if you have been backing up to a directly connected TM
drive (not a networked one) and your main drive completely dies and is
replaced with a blank new drive, you can boot from the TM drive and use
the recovery software to restore the TM backup to the new main drive,
without needing any other copy of the recovery partition.

It also avoids the need for Internet Recovery, which is still useful in
the case of a networked TM backup, since you can't boot from one of
them.

--
David Empson
dem...@actrix.gen.nz

[JF Mezei]

On 2017-04-28 17:01, David Empson wrote:

> There is a hidden folder in the Backups.backupdb folder with a name
> something like ".RecoverySets", which contains numbered subfolders (0,
> 1, ...), typically only "0" is required.

Thanks. makes a lot of sense to have a TM backup boot from the recovery
partition to give minimal system where you can then choose what to do.
(and from that instance, you have a disk util to format replacement
drive and a more complete Time Machine software to restore.

[Lewis]

In message <5903916f$0$10144$c3e8da3$e408...@news.astraweb.com> JF Mezei <jfmezei...@vaxination.ca> wrote:
> On 2017-04-28 07:19, Lewis wrote:

>> If only there were some way to tell how many links there were to a
>> file...

> Knowing there are 180 directory entries pointing to File1.txt is easy.
> And depending on the file system, if the actual file entry has
> backpointers, you may also easily find out in which directories and
> under which name these 180 entries are.

No, dummy. That's absurd.

> So if you wish to delete all references to file1.txt, you can do it by
> finding all references to it and deleting it. That will free up the
> disk space occupied by file1.txt. But also make 180 backups corrupt
> since they will be incomplete.

Taht seems like something you would think of; it's not something any
competent person would ever think of doing.

> When Time Machine needs free space, it does not and cannot decide to
> make a whole buchh of backsups corrupt by arbritrarily deleteing one or
> two files of its choice. It needs to eliminate full backups from oldest
> to newest backups until enough space has been freed.

No one said anything about corrupting backups. You are being
astonishingly dumb.

> And this is where it can get very IO intensive

No. Not at all.

> if deleting the oldest backup merely results in a whole buch of
> directory updates to remove fiule entries without freeing any space
> because these files are all used by subsequent backups.

Time Machine knows how may files have a single link, so knows how much
space deleting a backup snapshot will free. Duh.

> If your TM backup is on USB, I doubt it would impact SATA drives or PICe
> SSDs since they use different interconnects.

Your complete lack of understanding on how modern computer systems work
and modern hardware specifications is a constant source of amusement.
Deleting files from drives is very fast because the OS has to do very
little; the drive does nearly all the work.

--
SOME SHADOWS ARE SO LONG, THEY ARRIVE BEFORE THE LIGHT. --Soul Music

[Lewis]

In message <59038d10$0$8212$c3e8da3$cc4f...@news.astraweb.com> JF Mezei <jfmezei...@vaxination.ca> wrote:
>>> directly attached time machine backups are bootable since lion.


> Yosemite:

> Diskutil list for the Time Machine backup disk

>> /dev/disk1
>> #: TYPE NAME SIZE IDENTIFIER
>> 0: GUID_partition_scheme *2.0 TB disk1
>> 1: EFI EFI 209.7 MB disk1s1
>> 2: Apple_HFS DMA6 2.0 TB disk1s2

> There is no recovery partition.

So what?

Plenty of bootable disks have no recovery partition.

> What is not clear to me

Is anything. At all. So you simply make shit up with zero
understanding, zero information, zero research. In short, zero brain
activity.

--
Fairy Tales are more than true; not because they tell us that dragons
exist, but because they tell us that dragons can be beaten.