On 2017-03-12, at 3:53 PM, Macs R We <macs...@macsrwe.com> wrote:

> 
>> On Mar 12, 2017, at 3:31 PM, Michael <keybou...@gmail.com> wrote:
>> 
>> What you are describing happens on local backups (makes them significantly 
>> less useful), but does not happen (or at least, I've never seen it, and I 
>> spend/have spent a good amount of time playing with TM) on real/disk backups.
> 
> I have no knowledge of more than one type of T M backup, or what you are 
> describing as the distinction between the two you describe.

If you have local backups enabled, then the backups in that tree have different 
timestamp behaviors than the backups in the physical disk.

>> For the real backups, TM actually keeps the directory trees separate, and 
>> finally deletes a file when there is no directory with an entry pointing to 
>> it anymore.
> 
> Doesn't make sense to me.  You delete an important file by mistake, figure it 
> out only two weeks later, and try to get it back, only to be told, "sorry, 
> you deleted it and it's gone now"?  That would defeat one of the major 
> features.

As long as it has a reference in the hard-linked directory trees somewhere, 
then it is still occupying space on the backup disk, and can be recovered from 
the backup that points to it.

>> So no, this is not a "benign" case and it just works. Sure enough, the files 
>> in the older backup wound up going poof, and then there were no copies of 
>> the files anywhere on the disk.
>> 
>>>> Of course, finding some such files over here makes me worry that there are 
>>>> others elsewhere that I don't know about, and as soon as another backup is 
>>>> culled for space, even those existing backups will go poof.
>>>> 
>>>> How do I force time machine to scan everything and make backups of 
>>>> everything that is there, rather than just saying "I've seen this 
>>>> directory and subdirectory tree already, so one link and don't bother 
>>>> looking inside"?
>>> 
>>> Well, you can "touch" the directory tree down to the file in question, but 
>>> you seem to be describing a failure mode of that mechanism to begin with, 
>>> so I'm not sure what to say.
>> 
>> What I wound up trying:
>> 
>> 1. Force a reboot of the computer with the drives mounted.
>> To minimize problems, I logged out of the window server (name: ">console"), 
>> logged in on the raw console, and mounted the source drives. Then,
>> sync
>> sync
>> power-button
>> 
>> On restart, it did do a deep scan, but it still did not copy everything.
>> 
>> 2. Force a reboot of the computer with the drives AND the backup drives 
>> mounted.
>> When you are logged in on the console, the backup drive is not mounted by 
>> default. So this time, I added this ("diskutil mountdisk disk%" or "hdiutil 
>> attach <sparse bundle image>", as needed).
>> 
>> This time,
>> sync
>> sync
>> power-button
>> 
>> resulted in everything missing being copied to the backup.
>> 
>> So that is the "how to fix it".
> 
> Sounds like you just threw the machine into a state where it realized it 
> couldn't depend on its date stamps on the backup drive, journal or no 
> journal, so it did a full backup again.  I assume tht backup was REAL slow.

Nope. It actually did a real comparison of the main drive and the latest 
backup. It only backed up about 30 GB of data (just about 1 TB for a full 
backup).

It took a LONG time to start backing up that 30 GB.

>> For what it's worth, as insurance against drive failure / undetected IO 
>> failures, I have two backup sets on this drive. A normal backup that is 
>> updated once an hour, that takes up most of the drive, and an sparse bundle 
>> image that is generally updated when I get a system update (which no longer 
>> happens) or when I do a macports update -- and which I keep trimmed to only 
>> 2 backups. So, one lets me go back daily for about 20-some days, and one 
>> lets me go back to about a month and a half.
> 
> I just run standard T M backups to a backup volume on a local server, which 
> is a RAID-1 set of three partners, one of which is kept in a fireproof safe 
> and taken out only once a quarter to re-sync it.

Nice approach. My offsite backup is backblaze ($50 a year).

---
Entertaining minecraft videos
http://YouTube.com/keybounce

_______________________________________________
MacOSX-talk mailing list
MacOSX-talk@omnigroup.com
http://www.omnigroup.com/mailman/listinfo/macosx-talk

Reply via email to