I have a Windows 7 VirtualBox virtual machine. The disk image file is 30GB and is one large .vdi file. If I change anything inside that (even a few KBs), Time Machine wants to backup the entire 30GB file each time. Actually even if I just boot up the virtual machine, Windows makes some registry changes etc and even with 0 user/application level changes it triggers the full 30GB copy.

Is there a way to make a virtual disk image such that it's Time Machine friendly? So if a few KBs/MBs are changed, only those sectors are copied over?

Thanks Sid

  • For OS X I put the VDI-files on a "file-mounted-as-a-disk" file system which was sparse (i.e. consisting of a lot of small files instead of a single large one). This delegated the problem from virtualbox to the operating system. – Thorbjørn Ravn Andersen Jun 29 '15 at 7:34

Create a sparse bundle disk image which is made up of 8 MB bands. When the VirtualBox image file located on the disk image changes only those bands in the disk image that have changed will be updated by Time Machine.

  • 1
    This answer sounds interesting, but it would be worth expanding a bit. I can find some pointers on the internet but they all seem to have some sort of issues. – Calimo Dec 5 '14 at 11:46

After some tinkering around, it seems VirtualBox allows you to create the virtual hard drive as VMDK files (native format of VMWare). VMDK files allow you to split the total image into 2GB chunks, so a 30GB hard drive is actually 16 files

  • 1x Meta file (text file listing all the actual files) ~few KB
  • 15x 2GB VMDK chunk files (the actual virtual disk)

I've yet to hook up Time Machine to see how friendly this makes it, but I think this might actually work.

[Update #1] This is certainly quite useful! I no longer face a full copy of a 30GB image, the backup is about 3-4 GBs (because multiple chunks are updated on each bootup). One change I'd do if I were starting over again, I'd might make each chunk/slice about 200MB each so that (worst case) when any file is updated, 200MB is to be updated instead of 2GB.

[Update #2] I brought this up on the VirtualBox developer forums and it seems that the VMDK spec defined by VMWare (and used by everyone else, including Oracle VirtualBox) is hardcoded at 2GB chunks. So there is absolutely no flexibility to drop chunk size down to 1GB/500MB or 200MB.

Also, unlike the simple bootup tests I had done before, I've since noticed that if I do anything useful inside the Windows 7 VM, Time Machine's backup size goes to 10-15GB! Somehow a LOT more chunks are being hit even if I write little data (I suspect fragmentation of files across many chunks + swap file)


According to this blog post:


creating a snapshot will do the trick:

simply create a snapshot of your machine. VirtualBox will then leave your hard disk image untouched and create a separate file with just the changes from the time of the snapshot.

  • Kindof, but not really. If I change 5GB in a 10GB pool, VirtualBox's snapshots will now store 15GB as 10GB (pre-snapshot) + 5GB (post snapshot difference). Ideally we'd like to cap it at 10GB and have time machine only pick the delta 5GB. The selected answer of slicing the virtual hard drive (Z bytes) into many (n) stripes (each stripe is N byte => Z = n * N) works in that direction. Downside? As each stripe grows, the solution becomes less optimal since each byte changed in a stripe can now result in N-1 bytes of the stripe requiring backup by TimeMachine. Thanks! – DeepSpace101 Jan 11 '12 at 1:15
  • Actually if you change so much data inside the VM, you can periodically make a new snapshot and remove the old one. This operation will merge the data, reducing total size of virtual disk image. Which will trigger a full TimeMachine backup for one time and then the whole process starts over. – vadipp May 16 '13 at 7:26
  • @Sid also you can store your huge amounts of changeable data outside of the virtual machine. This can be done using technologies like "Virtualbox shared folders", samba aka Windows shares, and even NFS (technet.microsoft.com/en-us/library/cc754350.aspx). – vadipp May 16 '13 at 7:31

I've been interested in this as well – here's an answer that turned up in a Google search.

Might this work? (I ask because I'm too timid about trying this out myself on my mission-critical WinXP VM...)

To summarize the process, we first must create the base VDI disk and mark it as immutable. This forces VirtualBox to create a second differencing image of changes beyond the immutable base disk image. The second step is to change the mode of the differencing disk, toggling autoreset from ON to OFF. By default the differencing disk only applies for one run of the VM. In otherwords, any changes across restarts will be lost. Turning autoreset off fixes this.

Here are the steps I’ve extracted from that discussion, including commands that need to be run:

  1. Create an immutable .VDI disk.

    1. Detach the base VDI from the virtual machine in the VM settings.
    2. Make the VDI immutable by running the following command:

      VBoxManage openmedium disk -type immutable DISK_FILE_NAME.vdi
    3. Reattach the now immutable VDI to the VM.

  2. Tell VirtualBox to use a differencing disk explicitly. Click the check-box that says ‘Differencing Disk’ in the VBox settings for the VDI that is immutable. Note the GUID of the differencing disk that gets created.

  3. Disable autoreset for the differencing disk:

    1. By default VBox will reset the state of the machine between restarts.
    2. Disable this behavior by toggling the autoreset setting:

      VBoxManage modifyhd --autoreset off DIFFERENCING_DISK_GUID

After running through these steps you should be able to start your VM, make some changes, and restart. The changes on disk that you made should be persistent. It would be nice if VBox would make this particular use case all GUI-based, but at least it’s possible. Regardless, now TimeMachine only copies the differencing disk which is significantly smaller than the base disk image.

  • 1
    It might work, however as he notes, it required periodic maintenance where you merge the differencing disk with the base disk => new base disk and continue with a fresh differencing disk. Personally, I prefer not fiddling with my disk after setting it up! – DeepSpace101 Feb 16 '12 at 21:41


I finally got around to converting my 10GB Windows XP Pro .vdi file to a bunch of +/- 2GB .vmdk files.

I was hoping that any changes I would make in Windows would be limited to a small number of .vmdk files, so that Time Machine would back up a small number of 2GB .vmdk chunks.

Didn't quite work out. Seems that when I load the Windows XP VM, any changes I make -- no matter how small -- end up changing the "modified" date/time of ALL the .vmdk files...

...which means that Time Machine backs up the whole 10GB -- just like before.

Am I missing something? It seemed like this would be the solution for making a Time Machine-friendly VM...maybe not so much?

  • 1
    I updated my own answer too. Even in the 'just boot' scenario, yours will be even more severe since I had 300% of the chunks that you had (5 vs 15). I think having chunks helps somewhat, but not all the way :( ... It's possible your swap file is fragmented across all/most of the chunks. – DeepSpace101 Mar 20 '12 at 6:31
  • So...kinda sucks, no? Came awfully close to being awesome. Oh well... – Mikey Mar 21 '12 at 5:15
  • Yeah, but try defragging the WinXP virtual hard drive (PageDefrag look good for XP. Not on my Win7 box) from within WinXP. That should pull the swap file together, into fewer physical chunks. As soon as you do it, it'll be a big TM backup since a lot changed. However, 2nd+ TM backup onwards should be smaller. Imperfect, I know :/ ... – DeepSpace101 Mar 21 '12 at 16:23
  • 1
    Well...no luck for me. I ran the built-in defrag several times on my WinXP VM, exited and backed up the whole thing with Time Machine, then re-loaded the VM, exited, and backed up a second time. Even with defragging, etc., all 7 of the .vmdk files that make up my 10GB VM showed a change to the modification date, which triggered them to all be backed up by Time Machine again. So, I guess I just can't win for losing -- but not for a lack of trying. Thanks for the help and great suggestions...they made a lot of sense, but just didn't work out for me in practice. – Mikey Mar 22 '12 at 5:52
  • 1
    @Sid...sorry, cut myself off there... I'm using WinXP on my Mac exclusively to run Quicken '11. Nothing else. I had been storing my Quicken data file inside the WinXP VM, which meant that to back it up, I had to back up the WHOLE .vdi file -- all 10+ gigs. And then it occurred to me to map a VirtualBox shared folder from the Mac side to the WinXP side, and store Quicken's data file on the Mac side. That way, it'll get regular TM backups, while I can now exclude the .vdi from TM backups, only manually backing it up when I make major changes to WinXP. Problem solved! – Mikey Mar 23 '12 at 21:45

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.