TimeMachine does not backup everything!

A

aicul

Registered
I have just noticed that Time Machine does not seem to want to backup certain big files I have (such as VMware virtual machines 5gb files).

I have checked the options setup in TimeMachine and there is no setting here that could imply that these files would not be backed-up.

I have made a test and noticed that TimeMachine will not backup the stated files.

Does anyone know what could cause this?

Al other TimeMachine options work.
 
It's v1.1 downloaded from their site.

You think the version affects TimeMachine? Aren't VMware files just files? OK - bundles of folders and files. But there are many similar files on the mac (ie. applications).

For sure I have peeked into the VMware files but I did not change the security settings!
 
I remember reading about this once before. A little Googling and I found it: http://64.233.169.104/search?q=cach...s-backed-up&hl=en&ct=clnk&cd=5&gl=us&ie=UTF-8

Apparently VMWare specifically prevents Time Machine from backing up its disk images, because for some reason it will lead to data corruption of Time Machine runs while VMWare is active. (Don't ask me why!) There are some work-arounds on that page I linked, but perhaps it's not a good idea to follow them if it could lead to data corruption...
 
Ok - Mikuro, thanks for the link. This proves to be the case with me. Here are the conclusions of my reading and testing:

Apparently Apple does provide a manner to block archiving by TimeMachine. This can be set using the "com.apple.metadata:com_apple_backup_excludeItem" file attribute and the xattr command in terminal.

VMware seems to think that Time Machine backups could compromise an "open" virtual machine, so they decided to block Time Machine using the above mentionned file attribute.

I have tried to manually remove the file attribute using the following 3 commands (use ls -l@ to check your results). This releases the TimeMachine backup.

Code: 
xattr -d com.apple.metadata:com_apple_backup_excludeItem Windows.vmwarevm
cd Windows.vmwarevm
xattr -d com.apple.metadata:com_apple_backup_excludeItem *.*

However, the file attributes are reset to "block TimeMachine" as soon as you restart the virtual machine. So this is a short lived solution.


I am quite saddened by VMware because:
  1. they block TimeMachine without warning me in anyway or form. Potentially exposing them to some court case I think.
  2. I can understand blocking TimeMachine on "open" virtual machines but applying the same logic on "closed" ones seems excessive.
  3. the ideal setup would be for VMware to set the file attribute at virtual machine start, and remove it at VMware quit. But this seems to be to complex for them!

The only other solution I can think of is either using ZIP or a DMG image, but both add some silly overhead.

I remain surprised that VMware decided to block TimeMachine without any form of warning. I discovered this sillyness when I wanted to recover a virtual machine I had accidently deleted... relying on TimeMachine... just to find out VMware bypassed my archiving system - how stupid!
 
I will check.

However, this does not preclude the absolute unconsideration of VMware to wantingly activate file attributes that block TimeMachine at statup and forgetting to reset them at virtual machine shutdown.

This is just incomplete, and outright low quality programming, furthermore as a registered user of VMware products, I would have welcome some warning from their behalf.
 
Ok here is a status. I have installed version 1.1.2 (which claims to solve this issue).

UNFORTUNATELY it does not solve the issue.

TimeMachine will not backup VM virtual machine files because the file attribute (com.apple.metadata:com_apple_backup_excludeItem) is still set after a clean virtual machine shutdown.

The test I did in v1.1.2:

1. check in terminal what file attributes are set. Observed that the com.apple.metadata:com_apple_backup_excludeItem is set on a specific virtual machine

2. start the virtual machine

3. clean shutdown of the virtual machine

4. check the file attributes again.

The file attributes remained set so as to block TimeMachine.
 
The argument goes something like this: Anytime you even *boot* the virtual machine, the 5 GB (or much larger!!!) file is changed. You don't really *want* to add 5 GB (or much more in some cases) every hour, every day. It just doesn't make good sense.
 
Point taken Fryke but wouldn't you say that when someone activates TimeMachine it is for an obvious reason : To get backups done - whatever the archive disk capacity maybe.

By de-activating TimeMachine backups, VMware is actually tampering with my system setup WITHOUT any form of warning.

So my point is : I can understand all the logic about size, stability, ..., but I cannot understand someone overriding fundamental setups of my system without telling me.

I think it is plain bad programming quality and also a disregard of users on VMwares part.
 
Hello VirgilTracy,

It helps and confirms other input by Mikuro. Seems the only way today is to setup a script that forcibly removes what VMware imposes.

Although the script is easy to write, it is quite impractical because a user should run it every time he closes a virtual machine and before TimeMachine kicks in.

Frankly I can understand Fryke's cmment. But I don't think VMware though it through because all the components are available to them:

1. use the file attributes to inhibit TimeMachine backup when a virutal machine is running. This implies setting them at machine start and removing them at machine stop.

2. for those that do not want, or think virtual machines will use too much archive disk, they can use the TimeMachine functionality of not saving specific folders (in preferences/timemamchine/options).

I really don't see where VMware thought their solution was sufficient. It purely ensures virtual machine stability and lets users discover for themselves that backups are not blocked.
 
I just had a funny idea: what if you put VMWare's disk image inside a 'sparsebundle' dmg? Apple made sparsebundles specifically to work with Time Machine, I think — they're just like regular sparse disk images (which grow as needed), except that the data is split into many smaller files inside a package. That way you don't have the problem of a single enormous file being altered for every single change.

I assume Apple's disk image manager has some way or preventing corruption in these cases as well. But I really can't say for sure. Don't test it without first making backups, of course.
 
You must log in or register to reply here.
Back
Top