The “backup iPad” function in iTunes backs up only one or two files per second. This is no problem for large files (which may take longer), but particularly applies to very small files. Some applications have hundreds or even thousands of such small files. One application consisted of 80 MBytes made up of 6000 small files. It thus took 1-2 hours to backup those 6000 files – despite the fact that only 80 MByte were being backed up.
Furthermore, the backup progress bar may seem to freeze during specific parts of the backup process (when large series of small files are being processed). Apparently the progress bar show what percentage of the data that needs to be backed up has been processed. This is normally acceptable, but in this extreme case the user is likely to conclude that the process has crashed. In my case, backing up only 80 MBytes (out of a total backup of 1.5 Gbytes) took the majority of the time.
Before updating the iPad’s firmware using iTunes, Apple backups any user data on the device.
The main symptom is that this backup process takes very long: hours. And that it takes much longer than it originally took when the iPad was brand new. And much longer than one would expect for the amount of data being moved across the USB cable to the PC or Mac and to a local or network drive. Suggestions in forums to use better USB cables are incidentally unlikely to help.
On a PC you can watch this backup data accumulate in a directory (used by iTunes) named, for example,
There are utilities available by m4ko.de that automate the analysis of what files are being backed up (but you need to find the iTunes backup directory manually anyway).
The above has been observed back in April 2010 (and the issue is still not resolved in iOS 3.2). They also concluded that many applications generated hundreds or thousands of files, and that this essentially makes it look like the iPad backup process hangs. In my case one application (Granimator) consisted of least 6000 files with graphical elements. I can tell because the .mdinfo files contain the orignal file names like “Documents/packs/GP_moving_brands/shapes/white/4/shape_0445.png” which happens to belong to one of the Granimator shape packs. And the m4ko utilities can tell because they look at a domain name inside the .mdinfo files. Granimator is incidentally creating its own workaround for this problem – but this doesn’t help other applications.
The cause seems to be:
- every file that needs backing on the iPad up results in two files on the PC: the backup file named [hashnumber].mddata and a file with metadata named [hashnumber].mdinfo
- there are a few log and manifest files that list the hash values of all backuped files – but these are not relevant here
- somehow, only a few files per second can be backuped in this way – even if the files are only 1 kByte each
- particularly the application AppleMobileDeviceService.exe and AppleMobileService.exe respectively read 1 MB/s and write 0.5 MByte per second to the local device (127.0.0.1) according to the Resource Monitor. Note that 127.0.0.1 may have a strange web address depending on the content of your hosts file, but this is just a distraction. This detour of the writing of the data via the TCP/IP network stack within the PC may explain some of the performance overhead.
Various Apps have been discovered that exhibit this problem – so the issue is clearly a design problem that makes the iPad (and iPhone and iPod Touch?) pretty much incompatible with applications that install hundreds or thousands of tiny files. Apple can solve this by either changing their backup method, or by adding an extra rule that developers need to adhere to get their App accepted for distribution via the App Store.