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.
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.
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?
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.
jmmarton wrote: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?
tsightler wrote: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.
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.
cparker4486 wrote: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 wrote: 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.
