Whereas ordinary backups take no more than a couple of minutes, this one has been running for over 2 hours. I actually killed some earlier attempts thinking that the process had hung, so I am grateful to Chris Mercer for his comment in the Apple forums:
Hi all,Armed with the path information (
FYI I have an iPhone 3G running on the latest version of iTunes on the latest newly-updated version of Mac OS X.
It's been backing up for over an hour.
After a bit of digging I've found that loads of people are having this issue. It actually IS doing something, but either the status bar isn't updating properly or for some reason it is actually going very very slow.
I've found something reassuring, but before you follow any instructions please read them all before doing anything.
To make sure that it is doing something, you can go to finder, and go to this path:
your username
Library
Application Support
MobileSync
Backup
Go into List View and order by Date Modified. You'll see a folder with a very recent time there. If you click the disclosure arrow (the arrow to the left of the folder name) you will see a list of files and you will see that stuff is happening.
~/Library/Application Support/MobileSync/Backup/), I was able to dip down to the command prompt and use du -shm to keep an eye on progress.It's still painfully slow (average of 4MB / minute !), but at least I can see it moving ...
Oh, wait: it appears to have crashed. From 1323 MB, back to square one ...
I'll post updates as I learn more, but I suspect some of the slowness for me might be related to the large number of small files: 99.7% of the 13266 files it backed up before crashing were under 1 MB in size; 84% were under 100 KB.
It's been running again now for 20 minutes, and it's got through 450 MB; lets hope it doesn't slow down and die again!
UPDATE: It seems that half of the files are
.mdinfo, and the other half .mddata. The .mddata, as you might expect, are the data files; mine average 197 KB [1]. The .mdinfo files are tiny "binary property list" files, less than 280 bytes each.The latest attempt at a backup has been running for an hour. So far it's backed up 4164
.mddata files totalling 827 MB. I have 2.2 GB of data on my iPhone, so I could be in for a long wait, even if it doesn't crash again.[1]
ls -l | grep '.mddata' | awk '{ SUM += $5; COUNT++} END { print (SUM/1024)/COUNT }')UPDATE 2: It came time to head home, and the backup still hadn't finished. Predictably, the backup did not survive my Macbook's hibernation.
On the next run, it crashed again at 1323 MB:
Interestingly, the
Mon 28 Jun 2010 20:40:31 BST
1261 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:41:32 BST
1269 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:42:36 BST
1274 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:43:36 BST
1282 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:44:36 BST
1288 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:45:39 BST
1295 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:46:42 BST
1300 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:47:45 BST
1307 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:48:48 BST
1311 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:49:51 BST
1311 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:50:55 BST
1313 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:51:55 BST
1316 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:53:12 BST
1315 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:54:12 BST
1316 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:55:12 BST
1316 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:56:12 BST
1317 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:57:12 BST
1317 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:58:16 BST
1318 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 20:59:20 BST
1319 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 21:00:23 BST
1322 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 21:01:27 BST
1323 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 21:02:36 BST
1323 10be30bb86703bf73477870fef74387e5ceacae8
Mon 28 Jun 2010 21:03:36 BST
1323 10be30bb86703bf73477870fef74387e5ceacae8
Status.plist file in the backup directory indicates that the backup was successful<plist version="1.0">
<dict>
<key>Backup Success</key>
<true> </true>
</dict>
</plist>
UPDATE 3: Success at last! I put the phone in flight mode, and left it running overnight without an impatient human making queries at the command line. I can't say which made the difference. Reading from the directory that the backup is being written to shouldn't upset the process, but who knows.
After the cleanly-completed backup, the directory ended up containing 1297 MB. It looks like music files aren't backed up, which is reasonable enough considering the tight pairing with iTunes. With a bit more command line hackery [2], I got a listing of what's there:
1 ASCII text
33 ASCII text, with no line terminators
1 ASCII text, with very long lines
7 Adaptive Multi-Rate Codec (GSM telephony)
37 Apple binary property list
1 GIF image data, version 89a, 320 x 480
3050 JPEG image data
18 PNG image
15 SQLite 3.x database
11 XML document text
30 XML document text
1931 data
2 empty
The 1931 data files that are opaque to the
file command range in size from 168 bytes to 12.2 KB.The
.mddata and .mdinfo files are gone. Filenames are hex without an extension (e.g. 0663015d51be603f533b678e7b635eaacee052ff, 00dec425d314cb97d963bfe0796f6ea4c74e9778). There are also three interesting looking files: Manifest.plist, Manifest.mdbx, and Manifest.mbdb.When I subsequently reconnected my iPhone, a normal incremental backup completed within a couple of minutes, and brought the total up to 1347 MB. Judging by the timestamps, it touched/created 1470 files out of a total of 10808.
I've only had a couple of minutes to play with it, but initial impressions of iOS 4 are good. The UI feels more responsive, and the message threads in the mail app work well.
GoodReader still works, so I can still gradually work my way through De Soto on the go :-)
[2]
(for f in `ls`; file $f; done) > ../index.txt followed by some data cleansing with column, cut, and sed, then some aggregation with sort | uniq -c
What are you backing it up to? And using what connectivity?
ReplyDeleteBest regards
Hi Nigel.
ReplyDeleteUsing the standard USB connector cable connected to a Macbook Pro running Mac OS 10.6.4 and iTunes 9.2.
I left it running overnight, unwatched, and it seems to have worked, so perhaps it's a Heisenbug :-)
I'll post another update. Hope your upgrade went smoothly, if you're in a similar boat.
I know next to nothing about the iPhone. However, from the described symptoms and the USB 2.0 connection, I think it would be worth investigating whether the problem is one of setting up a USB link separately for each file being archived; this would slow things dowm markedly.
ReplyDeleteI have a suspicion that the iPhone operating system is based on Unix/Linux. If this is so, and you can connect to a command-line interface on that machine, try creating a single-file archive, for example using the UNIX TAR utility; it sounds as if you have sufficient non-volatile memory (16GB - 2.2GB). That would make all the individual file accesses happen just within the iPhone. Then backup just that one file of around 2.2GB, and subsequently delete the copy on the iPhone.
In addition, I suggest not using compression (eg with gzip) as, for sound files, little compression would be obtained and the compression processing itself might well be rather long.
If the iPhone does not provide access to a command-line interface (or any GUI control of a local 'backup' utility), I suspect your only recourse is to follow up with Apple, or bulletin boards that are specific to the product. It is also worth checking what all those little files contain; it might just be non-critical log information; that might have little backup value to you.
Best regards
Hi Nigel,
ReplyDeleteThanks for your comments.
iOS (previously known as iPhone OS) is a cut down version of Mac OS X, which is based on BSD, so it does have a Unix (though not Linux) core.
http://en.wikipedia.org/wiki/Darwin_(operating_system)
In typical Jobsian style, the iPhone (unless jailbroken) is heavily locked down. It would be nice if it mounted as a standard drive, and exposed its files for the usual backup mechanisms like rsync, but on Mac OS at least, you're forced to perform backups using iTunes. This one was a special backup, triggered by the iOS 4 upgrade. Quite how it managed to go so slow, I don't know.
The iOS upgrade succeeded in the end, though (per UPDATE 3), and the incremental iTunes backups are quick enough, so for now it seems like I'm back to having a device that Just Works TM :-)