Time Machine backing up entire virtual hard disk, with or without snapshot

T

TimothyM

Junior Member
I've done a lot of reading about this to see if I could fix the problem I'm having. I've looked at forum posts, and I've looked at Parallels KB articles. As far as I can tell, I have everything configured correctly.

My understanding is that if I have Parallels configured to "Optimize for Time Machine" and disable "Automatically compress virtual disks," then only Smartguard snapshots will be backed up. Furthermore, those snapshots are supposed to be incremental. And lastly, Parallels integrates with TM, so that I shouldn't have to manually configure TM to exclude the Parallels directory.

So if a snapshot is not taken, nothing from Parallels should be backed up with TM, and the backup should be normal. And if a snapshot has been taken, then only enough to account for the modified files should be backed up.

This doesn't appear to be working correctly for me.

If I have launched Parallels at any point, then the entire 48GB of virtual disk gets backed up, snapshot or not. One forum post suggested that Parallels incorrectly reports the amount being backed up and actually only backs up the changes, but in my case, this isn't true, because the backups always take an incredibly long time. It appears to be backing up the entire virtual disk every time.

Can anyone suggest anything else I may have configured incorrectly? Or is this a bug, where Parallels didn't bother to inform Time Machine of what to exclude?
 
Ok, it seems quite normal. Time Machine shouldn't take all of the vm every time.

You said:

One forum post suggested that Parallels incorrectly reports the amount being backed up and actually only backs up the changes
Click to expand...

It' the Time Machine who incorrectly reports the amount being backed up, not Parallels. As I noticed to my backups, it is true. Time Machine reports whole vm size to be backed up every time but does not, it only takes what it supposed to.

First, we must be sure about the sizes have been backed up by Time Machine. I would suggest you to download BackupLoupe and index your backups and look at the real sizes which backed up.

http://soma-zone.com/BackupLoupe/
 
Huge backups

I used TimeTracker to analyze my backups. And I think you're right. It's not Parallels' fault. What I think is going on is that Time Machine is WAAAAY slower under Lion than it was with Snow Leopard. The backups really are taking an eternity, but it's not because they're so huge but because Time Machine has really regressed in efficiency.

I'll note that Time Machine seems to be a lot more demanding of memory than it used to be, along with Safari, and kernel_task hits a gigabyte. I'm probably hitting swap, which is ironic since I have 8GB of RAM.
 
If kernel taks is hitting 1 GB that means there are A LOT of kexts loaded, you should review the software you have installed.
 
Kernel extensions

The only non-apple extensions loaded are for Parallels (despite the fact that it's not running) and fuse4x. By far, be biggest kext is Radeon driver. I don't think your theory about kernel extensions explains the memory usage. Plus, I'm not doing anything any different from what I did with Snow Leopard, but kernel_task is much bigger than it used to be.

Index Refs Address Size Wired Name (Version) <Linked Against>
122 0 0xffffff7f82071000 0xc000 0xc000 com.parallels.kext.prl_netbridge (7.0 14922.693916) <5 4 3 1>
123 0 0xffffff7f82006000 0x4000 0x4000 com.parallels.kext.prl_vnic (7.0 14922.693916) <36 5 4 3 1>
128 0 0xffffff7f82014000 0x7000 0x7000 com.parallels.kext.prl_usb_connect (7.0 14922.693916) <30 7 5 4 3 1>
129 0 0xffffff7f82080000 0x58000 0x58000 com.parallels.kext.prl_hypervisor (7.0 14922.693916) <9 8 7 5 4 3 1>
130 0 0xffffff7f8201d000 0x4000 0x4000 com.parallels.kext.prl_hid_hook (7.0 14922.693916) <7 5 4 3 1>
139 0 0xffffff7f82042000 0x16000 0x16000 com.parallels.filesystems.prlufs (2010.12.28) <7 5 4 3 1>
140 0 0xffffff7f81184000 0x13000 0x13000 org.fuse4x.kext.fuse4x (0.8.12) <7 5 4 3 1>
 
You must log in or register to reply here.
Back
Top