Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.system > #105480 > unrolled thread

Sierra's Time Machine's backups slower?

Back to article view | Back to comp.sys.mac.system

Contents

  Sierra's Time Machine's backups slower? ANTant@zimage.com (Ant) - 2017-04-25 13:16 -0500
    Re: Sierra's Time Machine's backups slower? nospam <nospam@nospam.invalid> - 2017-04-25 14:17 -0400
      Re: Sierra's Time Machine's backups slower? Snit <usenet@gallopinginsanity.com> - 2017-04-25 13:19 -0700
    Re: Sierra's Time Machine's backups slower? "Andre G. Isaak" <agisaak@gm.invalid> - 2017-04-25 22:20 -0600
      Re: Sierra's Time Machine's backups slower? dempson@actrix.gen.nz (David Empson) - 2017-04-26 19:38 +1200
        Re: Sierra's Time Machine's backups slower? "Andre G. Isaak" <agisaak@gm.invalid> - 2017-04-26 07:56 -0600
          Re: Sierra's Time Machine's backups slower? nj_kruse@me.com (Niels Jørgen Kruse) - 2017-04-26 20:44 +0200
            Re: Sierra's Time Machine's backups slower? "Andre G. Isaak" <agisaak@gm.invalid> - 2017-04-26 13:03 -0600
              Re: Sierra's Time Machine's backups slower? nj_kruse@me.com (Niels Jørgen Kruse) - 2017-04-26 22:13 +0200
            Re: Sierra's Time Machine's backups slower? nospam <nospam@nospam.invalid> - 2017-04-26 16:45 -0400
              Re: Sierra's Time Machine's backups slower? android <here@there.was> - 2017-04-27 06:37 +0200
                Re: Sierra's Time Machine's backups slower? nospam <nospam@nospam.invalid> - 2017-04-27 00:39 -0400
                  Re: Sierra's Time Machine's backups slower? android <here@there.was> - 2017-04-27 06:44 +0200
                    Re: Sierra's Time Machine's backups slower? Alan Baker <alangbaker@telus.net> - 2017-04-26 21:57 -0700
                      Re: Sierra's Time Machine's backups slower? android <here@there.was> - 2017-04-27 07:08 +0200
                        Re: Sierra's Time Machine's backups slower? Alan Baker <alangbaker@telus.net> - 2017-04-26 22:10 -0700
                        Re: Sierra's Time Machine's backups slower? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-04-27 09:43 +0000
                      Re: Sierra's Time Machine's backups slower? nospam <nospam@nospam.invalid> - 2017-04-27 09:28 -0400
                        Re: Sierra's Time Machine's backups slower? Alan Baker <alangbaker@telus.net> - 2017-04-27 07:02 -0700
                        Re: Sierra's Time Machine's backups slower? Bruce Esquibel <bje@ripco.com> - 2017-04-28 11:13 +0000
                          Re: Sierra's Time Machine's backups slower? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-04-28 11:25 +0000
                          Re: Sierra's Time Machine's backups slower? nospam <nospam@nospam.invalid> - 2017-04-28 08:09 -0400
                          Re: Sierra's Time Machine's backups slower? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-04-28 14:42 -0400
                            Re: Sierra's Time Machine's backups slower? dempson@actrix.gen.nz (David Empson) - 2017-04-29 09:01 +1200
                              Re: Sierra's Time Machine's backups slower? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-04-28 22:59 -0400
                            Re: Sierra's Time Machine's backups slower? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-04-29 20:10 +0000
                    Re: Sierra's Time Machine's backups slower? Jolly Roger <jollyroger@pobox.com> - 2017-04-27 16:41 +0000
                      Re: Sierra's Time Machine's backups slower? android <here@there.was> - 2017-04-27 20:32 +0200
                        Re: Sierra's Time Machine's backups slower? Jolly Roger <jollyroger@pobox.com> - 2017-04-27 23:23 +0000
                          Re: Sierra's Time Machine's backups slower? android <here@there.was> - 2017-04-28 05:40 +0200
                            Re: Sierra's Time Machine's backups slower? Jolly Roger <jollyroger@pobox.com> - 2017-04-28 16:14 +0000
                              Re: Sierra's Time Machine's backups slower? android <here@there.was> - 2017-04-28 18:40 +0200
            Re: Sierra's Time Machine's backups slower? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-04-27 09:42 +0000
              Re: Sierra's Time Machine's backups slower? "Andre G. Isaak" <agisaak@gm.invalid> - 2017-04-27 05:49 -0600
                Re: Sierra's Time Machine's backups slower? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-04-27 14:20 -0400
                  Re: Sierra's Time Machine's backups slower? Jolly Roger <jollyroger@pobox.com> - 2017-04-27 18:31 +0000
                    Re: Sierra's Time Machine's backups slower? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-04-27 14:56 -0400
                      Re: Sierra's Time Machine's backups slower? Jolly Roger <jollyroger@pobox.com> - 2017-04-27 19:32 +0000
                        Re: Sierra's Time Machine's backups slower? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-04-27 15:55 -0400
                          Re: Sierra's Time Machine's backups slower? Jolly Roger <jollyroger@pobox.com> - 2017-04-27 20:41 +0000
                  Re: Sierra's Time Machine's backups slower? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-04-28 11:19 +0000
                    Re: Sierra's Time Machine's backups slower? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-04-28 15:01 -0400
                      Re: Sierra's Time Machine's backups slower? Jolly Roger <jollyroger@pobox.com> - 2017-04-28 19:06 +0000
                      Re: Sierra's Time Machine's backups slower? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-04-29 20:07 +0000
                Re: Sierra's Time Machine's backups slower? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-04-28 11:16 +0000
    Re: Sierra's Time Machine's backups slower? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-04-26 14:00 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#105729

In message <odv845$ehi$1@remote5bge0.ripco.com> Bruce Esquibel <bje@ripco.com> wrote:
> In comp.sys.mac.system nospam <nospam@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.

[toc] | [prev] | [next] | [standalone]

#105731

In article <odv845$ehi$1@remote5bge0.ripco.com>, Bruce Esquibel
<bje@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.

[toc] | [prev] | [next] | [standalone]

#105758

>> 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.

[toc] | [prev] | [next] | [standalone]

#105779

JF Mezei <jfmezei.spamnot@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
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#105804

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.

[toc] | [prev] | [next] | [standalone]

#105884

In message <59038d10$0$8212$c3e8da3$cc4fe22d@news.astraweb.com> JF Mezei <jfmezei.spamnot@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.

[toc] | [prev] | [next] | [standalone]

#105637

On 2017-04-27, android <here@there.was> wrote:
> In article <270420170039597801%nospam@nospam.invalid>,
>  nospam <nospam@nospam.invalid> wrote:
>> In article <here-540130.06370127042017@news.individual.net>, android
>> <here@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:

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

[toc] | [prev] | [next] | [standalone]

#105653

In article <emel98FbmobU1@mid.individual.net>,
 Jolly Roger <jollyroger@pobox.com> wrote:

> On 2017-04-27, android <here@there.was> wrote:
> > In article <270420170039597801%nospam@nospam.invalid>,
> >  nospam <nospam@nospam.invalid> wrote:
> >> In article <here-540130.06370127042017@news.individual.net>, android
> >> <here@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

[toc] | [prev] | [next] | [standalone]

#105695

On 2017-04-27, android <here@there.was> wrote:
> In article <emel98FbmobU1@mid.individual.net>,
>  Jolly Roger <jollyroger@pobox.com> wrote:
>
>> On 2017-04-27, android <here@there.was> wrote:
>> > In article <270420170039597801%nospam@nospam.invalid>,
>> >  nospam <nospam@nospam.invalid> wrote:
>> >> In article <here-540130.06370127042017@news.individual.net>, android
>> >> <here@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.

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!

-- 
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

[toc] | [prev] | [next] | [standalone]

#105712

In article <emfcriFgfs0U1@mid.individual.net>,
 Jolly Roger <jollyroger@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

[toc] | [prev] | [next] | [standalone]

#105740

On 2017-04-28, android <here@there.was> wrote:
> In article <emfcriFgfs0U1@mid.individual.net>,
>  Jolly Roger <jollyroger@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 <here@there.was> wrote:
> In article <270420170039597801%nospam@nospam.invalid>,
>  nospam <nospam@nospam.invalid> wrote:
>> In article <here-540130.06370127042017@news.individual.net>, android
>> <here@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

-- 
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

[toc] | [prev] | [next] | [standalone]

#105745

In article <emh82eFrarlU2@mid.individual.net>,
 Jolly Roger <jollyroger@pobox.com> wrote:

> On 2017-04-28, android <here@there.was> wrote:
> > In article <emfcriFgfs0U1@mid.individual.net>,
> >  Jolly Roger <jollyroger@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 <here@there.was> wrote:
> > In article <270420170039597801%nospam@nospam.invalid>,
> >  nospam <nospam@nospam.invalid> wrote:
> >> In article <here-540130.06370127042017@news.individual.net>, android
> >> <here@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

[toc] | [prev] | [next] | [standalone]

#105617

In message <1n53w4s.a8tohs1unrh8xN%nj_kruse@me.com> Niels Jørgen Kruse <nj_kruse@me.com> wrote:
> Andre G. Isaak <agisaak@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.

-- 
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

[toc] | [prev] | [next] | [standalone]

#105620

In article <slrnog3fea.jnv.g.kreme@snow.local>,
 Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:

> In message <1n53w4s.a8tohs1unrh8xN%nj_kruse@me.com> Niels Jørgen Kruse 
> <nj_kruse@me.com> wrote:
> > Andre G. Isaak <agisaak@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.

Andre

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

[toc] | [prev] | [next] | [standalone]

#105650

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.

[toc] | [prev] | [next] | [standalone]

#105652

On 2017-04-27, JF Mezei <jfmezei.spamnot@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.

-- 
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

[toc] | [prev] | [next] | [standalone]

#105657

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

> Nope. That's not how it works.

So pray tell, how does it work?

[toc] | [prev] | [next] | [standalone]

#105660

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 2017-04-27 14:31, Jolly Roger wrote:
> 
>> Nope. That's not how it works.
> 
> So pray tell, how does it work?

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.

-- 
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

[toc] | [prev] | [next] | [standalone]

#105662

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.

[toc] | [prev] | [next] | [standalone]

#105667

JF Mezei <jfmezei.spamnot@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. 

-- 
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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.sys.mac.system

csiph-web