My tiny do-nothing web server has large daily backups

[cparker4486]

Hi everyone,

Hoping someone has some insight in to this. Specifically, I'm looking for clues as to what is causing the large daily backups for a VM that does next to nothing. This is a 2012 R2 Core server running IIS that serves a small site that just a few staff use internally. I'm talking 10s of hits per day (if that!). Minuscule traffic. Yet, daily backups are about 1.3GB in size consistently and the VBK itself is just 7.7GB.

Curious about this, I used PowerShell to show me the list of files that were all modified yesterday. This was my best effort at determining what is likely to be changing every day but, unfortunately, these files are all very small. They don't come anywhere close to explaining the high churn on this machine which is what brings me here.

Anyone have any idea how I can determine what's actually changing? I'd expect this server to have megabytes of change per day.

[Gostev]

Try capturing writes using the Process Monitor from Windows Sysinternals, then filter the output by above-mentioned files and see which ones get most writes.

[cparker4486]

Thanks for the idea. I'll see what I can find out.

Does that mean B&R backs up all changed blocks even if they're not in use?

[foggy]

Yes, unless BitLooker is enabled.

[cparker4486]

Yes, I have BitLooker enabled. It looks like all the changes were coming from my antivirus software. My software doesn't support Windows Server Core but somehow I managed to push the agent there some time in the past. I've uninstalled it and now the newest VIBs are averaging 300MB. This is much more in line with what I would expect from this machine.

This brings up another question. My search for modified files is looking like it's not thorough enough. Does this mean files can be written to without the OS changing the modified timestamp?

[jmmarton]

AV software can potentially update the last accessed date.

Joe

[Gostev]

Joe, "Last accessed" timestamping can even be quite easily disabled in Windows, however he is asking about "Last modified" timestamp instead.

[jmmarton]

I thought he was asking about files that could be causing changed blocks without changing the "last modified" timestamp. My thought was perhaps the AV software was updating last accessed (assuming that's not disabled) which might explain changed blocks when the last modified date isn't changed.

Joe

[tsightler]

Any change the filesystem is highly fragmented, especially the MFT?

[cparker4486]

I thought he was asking about files that could be causing changed blocks without changing the "last modified" timestamp. My thought was perhaps the AV software was updating last accessed (assuming that's not disabled) which might explain changed blocks when the last modified date isn't changed.

You are correct. If only modified files were backed up then I wouldn't have seen such large dailies so I was asking if there were other ways files could be identified as changed.

If a file's last accessed time changes, but it's not modified, does that qualify the entire file to be backed up or would it just be the part that stores the last accessed timestamp?

[cparker4486]

Any change the filesystem is highly fragmented, especially the MFT?

I don't know. I haven't thought about manually defragmenting drives in years (because it is automated). Is that something we (Veeam customers) should be doing?

I did a little looking around and according to "defrag C: /A /U", the drive is 34% fragmented. I don't know how to check the MFT.

[cparker4486]

Here's the result of "defrag /C /H /V"

Code: Select all

PS C:\Users\Administrator.ATI> defrag /C /H /V
Microsoft Drive Optimizer
Copyright (c) 2013 Microsoft Corp.

Invoking defragmentation on System Reserved...

        Free Space Consolidation:  100% complete.

The operation completed successfully.

Post Defragmentation Report:

        Volume Information:
                Volume size                 = 349.99 MB
                Cluster size                = 4 KB
                Used space                  = 257.44 MB
                Free space                  = 92.55 MB

        Fragmentation:
                Total fragmented space      = 0%
                Average fragments per file  = 1.01

                Movable files and folders   = 87
                Unmovable files and folders = 4

        Files:
                Fragmented files            = 0
                Total file fragments        = 0

        Folders:
                Total folders               = 3
                Fragmented folders          = 0
                Total folder fragments      = 0

        Free space:
                Free space count            = 6
                Average free space size     = 16.32 MB
                Largest free space size     = 45.41 MB

        Master File Table (MFT):
                MFT size                    = 256.00 KB
                MFT record count            = 255
                MFT usage                   = 100%
                Total MFT fragments         = 1

        Note: File fragments larger than 64MB are not included in the fragmentat
ion statistics.

Invoking defragmentation on (C:)...


Pre-Optimization Report:

        Volume Information:
                Volume size                 = 21.65 GB
                Cluster size                = 4 KB
                Used space                  = 7.91 GB
                Free space                  = 13.74 GB

        Fragmentation:
                Total fragmented space      = 34%
                Average fragments per file  = 1.35

                Movable files and folders   = 70718
                Unmovable files and folders = 5

        Files:
                Fragmented files            = 6968
                Total file fragments        = 24172

        Folders:
                Total folders               = 3231
                Fragmented folders          = 263
                Total folder fragments      = 1001

        Free space:
                Free space count            = 10823
                Average free space size     = 1.29 MB
                Largest free space size     = 1.09 GB

        Master File Table (MFT):
                MFT size                    = 132.50 MB
                MFT record count            = 135679
                MFT usage                   = 100%
                Total MFT fragments         = 1

        Note: File fragments larger than 64MB are not included in the fragmentat
ion statistics.

The operation completed successfully.

Post Defragmentation Report:

        Volume Information:
                Volume size                 = 21.65 GB
                Cluster size                = 4 KB
                Used space                  = 7.91 GB
                Free space                  = 13.74 GB

        Fragmentation:
                Total fragmented space      = 0%
                Average fragments per file  = 1.00

                Movable files and folders   = 70709
                Unmovable files and folders = 5

        Files:
                Fragmented files            = 0
                Total file fragments        = 0

        Folders:
                Total folders               = 3231
                Fragmented folders          = 0
                Total folder fragments      = 0

        Free space:
                Free space count            = 541
                Average free space size     = 51.76 MB
                Largest free space size     = 2.47 GB

        Master File Table (MFT):
                MFT size                    = 132.50 MB
                MFT record count            = 135679
                MFT usage                   = 100%
                Total MFT fragments         = 1

        Note: File fragments larger than 64MB are not included in the fragmentat
ion statistics.

[foggy]

If a file's last accessed time changes, but it's not modified, does that qualify the entire file to be backed up or would it just be the part that stores the last accessed timestamp?

Only blocks containing the actual change.

[tomhkr]

Does this mean files can be written to without the OS changing the modified timestamp?

If I'm not mistaken, when you create a file and then delete it, it still counts as changed blocks.
You can easily test this, place a large (4 GB) file on the server and then delete it immediately. You should see the change appear on your backup.

If you have a lot of temporary files on a fragmented drive it would create a lot of changed blocks.

[cparker4486]

If you have a lot of temporary files on a fragmented drive it would create a lot of changed blocks.

This makes sense but I thought this is what BitLooker is supposed to negate now. Is that not correct?