Hi Ruud,

Did you put the Windows swap file on a seperate disk and exclude it from
the VE backup?
If not this is part of the VE backup and might be (a part) of the size
increase you are seeing if Windows swap space is in use.
A file backup using the backup archive client might also exclude other data
(from the local include exclude list or a server client option set) that
you might need to take into account.

Regards,
   Stefan



On Fri, May 29, 2015 at 4:51 PM, Meuleman, Ruud <ruud.meuleman AT tatasteel DOT 
com
> wrote:

> Hi all,
>
> We administer a vSphere 5.5 environment using TDP for VE as our backup
> solution. TDP for VE uses CBT to make incremental-forever backups of our
> VMs, meaning that it only backs up the entire VM once; all subsequent
> backups are incrementals. We backup our VMs once a day. We are currently
> investigating why certain Windows VMs in our vSphere environment generate
> huge incremental backups. During our investigation we hit on something we
> don't understand. As a quick-and-dirty test, we did a file scan on a VM, to
> list all files that had been modified on the VM during the last 24 hours.
> We then added up the total file size of all those modified files. Then, we
> compared this combined file size with the size of the incremental TSM-VE
> backup for that day. we repeated this test on a number of VMs, smaller as
> well as larger ones. We had expected the combined file size to be much
> larger than the size of the incremental backup. After all, the fact that a
> file is modified does not mean that the entire file has changed (meaning
> that all CBT blocks need to be backed up). We expected a CBT backup to be
> more efficient, size-wise, than an incremental file-based backup. Instead,
> we found out that on all VMs, the incremental TSM-VE backup was
> consistently 1.5 to twice the size of the combined modified file size,
> exactly the opposite of the result we expected.
>
> We've tried to think of a few things that could cause this discrepancy.
> 1) In-guest disk defrag. This would change the blocks without changing the
> files, messing up the way CBT works. However, there are no scheduled or
> unscheduled defrags on our VMs.
> 2) The files on the VM are smaller than the CBT blocks. That could cause a
> small file to mark a larger CBT block as changed. However, as we understand
> it, CBT blocks are usually quite small (and not the same as VMFS blocks)
>
> What are we missing here? Is there some other process that changes the
> VMDK storage blocks of my Windows VMs without changing the actual files? Is
> my quick-and-dirty file scan too simplistic? I really hope that someone can
> explain this to me, thanks!
>
> Kind Regards,
> Ruud Meuleman
>
> **********************************************************************
>
> This transmission is confidential and must not be used or disclosed by
> anyone other than the intended recipient. Neither Tata Steel Europe Limited
> nor any of its subsidiaries can accept any responsibility for any use or
> misuse of the transmission by anyone.
>
> For address and company registration details of certain entities within
> the Tata Steel Europe group of companies, please visit
> http://www.tatasteeleurope.com/entities
>
> **********************************************************************
>