2

We have a small, relatively idle Windows Server 2008 R2 installation that does basic file sharing and hosts Exchange for about 10 not very active users.

When running a windows server backup, the daily incremental data is about 20GB. This is not coming from users shared files, nor from changes in their mailbox sizes. The total size of the installation is 249GB, which is mostly old files.

Where is all this data coming from, and how can I reduce it? Using online backup of the vhd file from the backup is taking a while because of this daily change.

Is there some way I can at least see what files are changing and contributing to this data ?

Options I can think of but am not sure about:

  1. pagefile churning - although the backup does not include the pagefile, perhaps the changed blocks left behind are included ?
  2. logs or something ? But the installation size stays the same every day
  3. should I zero free space using sdelete before backing up perhaps ?
Mathias R. Jessen
  • 25,161
  • 4
  • 63
  • 95
bobjandal
  • 121
  • 1
  • 4
  • Do your users keep outlook mail (pst) files on that server? Those files seems to change just from opening them (in other words, every time they start outlook.) – Hennes Oct 23 '12 at 22:30
  • no, it's an exchange server and the clients have OSTs on their local machine. – bobjandal Oct 23 '12 at 23:04
  • 1
    I would take a look at how Exchange is being backed up. My suspicion is that the entire EDB file is being backed up during the incremental backup. – joeqwerty Oct 24 '12 at 01:15
  • yes the entire edb is backed up, but only the changed data is being written in the backups - it doesn't churn blocks very much - this was not the source of my data churning, even tho the EDB is about 45GB and supports about 20people who email a lot. – bobjandal Nov 03 '12 at 23:42

3 Answers3

2

Disable the LastAccessedTime NTFS file system setting and see if that fixes it. 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]  
"NtfsDisableLastAccessUpdate"=dword:00000001

You may want to review how you are doing backups.

In Windows 2008 R2, it is possible to perform a "full" backup every day to a dedicated local drive, and the block-level changes feature should only copy the new and changed data to the backup medium. Using this, I have literally hundreds of "full" backups on one 2 TB USB hard drive. (This strategy and feature does not work if the backup target is a network share).

enter image description here

This may seem counter-intuitive when compare to the traditional full-incremental strategy.

This feature is probably not documented as well as it could be. More information here:

https://blogs.technet.com/b/filecab/archive/2009/10/31/learn-more-about-system-image-backup.aspx

[...]
"Just as a brief recap, a system image is in essence a snapshot of an entire drive(s). The backup is done in block level (as opposed to file level) increments and includes all user and system files, configuration data and applications that are present on the drive, plus information regarding disk layout and boot entries. The image can be used to recover a working Windows if your hard disk ever fails, or if you simply want to reimage your OS to an earlier point in time.

"During the first backup, the backup engine scans the source drive and copies only blocks that contain data into a .vhd file stored on the target, creating a compact view of the source drive. The next time a system image is created, only new and changed data is written to the .vhd file, and old data on the same block is moved out of the VHD and into the shadow copy storage area. Volume Shadow Copy Service is used to compute the changed data between backups, as well as to handle the process of moving the old data out to the shadow copy area on the target. This approach makes the backup fast (since only changed blocks are backed up) and efficient (since data is stored in a compact manner). When restoring the image, blocks will be restored to their original locations on the source disk. If you want to restore from an older backup, the engine reads from the shadow copy area and restores the appropriate blocks."

Greg Askew
  • 35,880
  • 5
  • 54
  • 82
  • Thanks a lot for your response there - I found the problem and have written my findings as an answer. I am currently doing backups like you have mentioned, but my problem was I couldn't figure out what was churning data – bobjandal Nov 03 '12 at 23:35
0

Do you run wsus or SQL on the server? SQL logs while not large in size change so much that they can bloat backups like crazy. Typically if I backup a SQL server I run any maintenance plans to a separate drive not backed up.

Joe van Maldegiam
  • 71
  • 1
  • yes wsus and sql were running, quite heavily, but even that after investigation was only generating about 500MB of change data, which is definitely manageable. – bobjandal Nov 03 '12 at 23:41
0

So after quite a bit of pain I found where the churning was coming from. There were some application level backup jobs that were dumping to disk every night (like SQL). Whilst I thought our online backup software should have detected the similarity in the data, it couldn't do that if the backups had compression turned on, and it also has trouble finding duplication in such big files as a vhd.

I also learned thru mounting a vhd from two consecutive days and using BeyondCompare to see what changed that pagefile.sys is included in the vhd, so all pagefile activity is now part of your backups.

So in summary, if there are application level backups writing to disk, make sure they have compression turned off, and write to a seperate volume to be backed up independently, and if possible move pagefile.sys to another volume that doesn't get backed up. Even the exchange EDB did not churn sufficiently to impact on backup ability.

Thanks.

bobjandal
  • 121
  • 1
  • 4