Currently Being ModeratedJun 12, 2012 7:23 AM (in response to stewarts2)
Check through this Pondini tip and then follow the link to the full Pondini site for all there is to know about Time Machine.
Currently Being ModeratedJun 12, 2012 3:59 PM (in response to stewarts2)
Time machine failed in progress as my hard drive failed. I have an "in progress" file on my external harddrive that is about 160 GB. I would like to try and load this back onto a new harddrive. Is this possible? Migration assistant is not responsive nor does Time Machine recognize the external drive when connected.
No, neither the "Star Wars" display nor Migration Assistant can deal with a partial backup.
And it sounds like the file system was damaged when your internal HD failed. Try to repair the backups per #A5 in Time Machine - Troubleshooting.
You'll have to try to drag & drop whatever you can from the ".inProgress" package to the corresponding places on your system. It looks like a file, but is really a special kind of folder. Right-click it in the Finder and select Show Package Contents. You'll find a duplicate of the most or all of the folder structure of your Mac. You'll have some of the actual data, but not all of it.
Skip all the top-level folders except Users. Inside it will be your home folder, containing all the default sub-folders (Desktop, Documents, Pictures, etc.). You can't copy the whole home folder, or entire default sub-folders, since the ones on your new HD are protected. But you should be able to copy the contents.
You can copy some "simple" apps (things you just dropped into Applications) from Applications, but "complex" ones (typically the ones that came with their own installers) will have to be reinstalled from their original discs. You'll also have to re-enter any serial numbers or purchase keys.
Currently Being ModeratedJun 12, 2012 4:41 PM (in response to Ralph Landry1)
thanks for your help!
Currently Being ModeratedJun 12, 2012 4:42 PM (in response to Pondini)
Thanks - helped but unfortunately lost most of my info. Appreciate you trying!
Currently Being ModeratedJun 29, 2012 4:11 PM (in response to stewarts2)
Pondini's site is a amazing wealth of information on TM, unfortunately more than I want to know! It's not good testimony to TM that some much information need even exist. I applaud the many people who go to the trouble of compiling these things to help others.
I'm analyzing a blown-directory archive myself. Disk Utility repair failed. I would appreciate any commentary on the low-level fsck fix ... this goes back :
Currently Being ModeratedJun 29, 2012 4:29 PM (in response to doug123apple)
That link was written in 2008. It has to do with repairing the backups in a sparse bundle disk image on a network backup (probably on a Time Capsule).
If DIsk Utility can't fix your backups, see the pink box at the end of the appropriate option in #A5 of Time Machine - Troubleshooting. Note the same link is in the section for backups on a Time Capsule.
Currently Being ModeratedJul 5, 2012 9:22 AM (in response to Pondini)
Hi there. Yes, the article is from 2008 but file systems haven't changed that much!
My archive problem was in a Time Capsule, and the inProgress file was inaccessible. IIRC Disk Utility and Disk Warrior could not fix it. I'm not sure I have it exactly right, but fsk did return:
** Checking volume information.
Invalid volume file count
(It should be 1346360 instead of 1182923)
Invalid volume directory count
(It should be 328352 instead of 290911)
Invalid volume free block count
(It should be 184833258 instead of 214336600)
Volume header needs minor repair
** Repairing volume.
Disk Warrior did work after that. I still couldn't read the (incomplete) archive through Time Machine but did inspect the contents and copy files out of inProgress. Very slowly. I don't what exactly I did that helped but I am extremely unhappy that Time Machine uses such an obfuscated system. Carbon Copy Cloner has regained a lot of appeal -- it's wasy to understand a clone. (TM is a good complement.)
SO my Q is simply whether Terminal / fsck provide a useful tool.
Currently Being ModeratedSep 18, 2012 1:45 AM (in response to stewarts2)
I get the impression that the way that Time Machine works has changed - am I right? This is not documented anywhere I can find so everything is hearsay which is not ideal...
Anyway, the structure used to be:
Where BackupFolder is the folder containing a separate folder for each timed backup, each named with the date on which the backup was performed. If a backup failed you could find a folder in here which had "inProgress" appended to its name, and if you delete that folder you can carry on with using the backup.
However now I have seen, in at least two instances, the BackupFolder itself has become a package renamed with the date on which the backup was performed and "inProgress" appended to it when a backup fails. Inside that package are the separate folders for each timed backup. It is not clear how one clears the failed state of the backup in these cases, if indeed it is possible.
Currently Being ModeratedSep 18, 2012 6:40 AM (in response to ncollingridge)
. . .
However now I have seen, in at least two instances, the BackupFolder itself has become a package renamed with the date on which the backup was performed and "inProgress" appended to it when a backup fails. Inside that package are the separate folders for each timed backup.
The .inProgress package may contain more than one failed backup. Each will have a UUID (long string of numbers and letters) instead of a date stamp (at least on recent versions of OSX). None of them are complete -- you need to delete the entire package.
Currently Being ModeratedSep 18, 2012 7:03 AM (in response to Pondini)
I wonder why they changed (if indeed they have) the previous approach? Being able to delete the last failed backup was a great way of getting it going again, but this way you are simply screwed. What is more:
1. There is no indication to the user that a fault like this has occurred.
2. Time Machine needs to be much more robust in situations like this. If it can fall over so easily and the backup becomes unuseable (often at the time when you depend upon it most) then it is simply close to useless. It should be designed so that whatever happens you can always get back to a previous valid backup.
In one case where I know the history leading up to the failure the Mac's hard drive had become faulty in a way (not uncommon) where it still just about worked, but extremely slowly (presumably every access required countless retrys before the data came through cleanly). Eventually a disk access would fail and the system would hang. Having replaced the hard drive it leapt back into life, only needing to have the data restored.
However while the system was running poorly it was still trying to backup via TM, but I guess that on one occasion at least it will have hung while attempting a backup. Faults like are not a rare occurrence, for this or other reasons, but must happen quite often, and TM should be robust enough to cope with it by being designed from the ground up to ensure that one faulty backup session cannot destroy the result of all the previous backup sessions.
I know that to achieve this in all circumstances is impossible, but at the moment it feels like TM is way more lightweight than it really needs to be.