I have a number of logs in c:\windows\log\windowsserverbackup that follow the pattern wbadmin.*.etl.

I have opened these files in the Event Log tool and can only see a large number of entries with GUIDs and nothing else in them. In fact, there seems to be no useful information anywhere in the logs directory.

Is there any way I can work out what the GUIDs mean or adjust the Backup settings to leave something meaningful in the logs with regard to what the backup process is up to? My main concern is to work out why the backup is running so slow (see below).

Some Background Info

This is for an SBS 2011 box running nightly backups to external media with Windows Backup.

Of late the backup process has mostly been running very slowly (~12hrs instead of the usual ~1 hr).

I've been working along a number of lines of inquiry and one of those lines is to see what the backup logs have to say. I want to see what's being backed up and how long it's taking.

In parallel with the logs investigation, I'm following leads around VSS, Exchange, Antivirus, full backup media etc - but I'll raise separate questions for those items as / when needed. Here I just want to get some meaningful logging.

Many thanks


per @joeqwerty's suggestion I had look at the event logs under Event Viewer > Applications and Services Logs > Microsoft > Windows > Backup > Operational but there was very little in there apart from start & stop messages. Does anyone know how to get more information regarding the content being backed up and what's holding things up (or even if it's possible) ?

  • 1
    AFAIK, that is not the log location nor are those the log files for Windows Server Backup. It may be the location for the Backup tab in the SBS console, but I really have no idea. The log location for Windows Server Backup is: C:\Windows\System32\winevt\Logs\Microsoft-Windows-Backup.evtx and this log can be viewed in the Event Viewer>Applications and Services Logs>Microsoft>Windows>Backup>Operational – joeqwerty Sep 28 '13 at 22:12
  • Thanks @joeqwerty, you have no idea how much googling I did, just to find the location I was looking in to begin with. Anyway I had a look at the evt log for Backups but it doesn't have much to say other than when it started and when it stopped. I'll update my question. – LRE Sep 28 '13 at 22:53

Look in the events in Event Viewer > Applications and Services Logs > Microsoft > Windows > Backup > Operational: event ID 4 or 14 (Backup completed) Details- (o) Friendly view -EventData: Volumesinfo. This is a long string with a fixed structure. It has important information on each volume being backed up: e.g. backup result, volumename, IsIncremental, Datatransferred. There is no file or directory level information however.

I used logparser.exe and some heavy VBS programming and Excel macros to extract the events from the event file (c:\windows\system32\winevt\logs\Microsoft-Windows-backup.evtx), parse the VolumesInfo string into something readable and periodically mail it as CSV to me as admin, so I can keep an eye on how the backups proceed at my clients sites.

I did this after discovering that backups sometimes took longer than exspected. Extracting the log info allowed me to discover that some volumes were not always backed up incrementally (flag IsIncremental in the VolumesInfo string was 0).

The reason was that I had inadvertently set a limit in the Shadow Copies settings for the backup disk. This is poorly documented: backups are stored as shadow copies on the backup disk, and the Shadow Copies space limit setting is ALWAYS in effect, regardless if normal shadow copy creation scheduling for the backup disk is active or not. The normal Windows scheduled creation of shadow copies of disks can be enabled or disabled per disk, but the space limit setting stays in effect even if this scheduling is disabled. Windows scheduled shadow copy creation and Windows backup are two totally independent processes, but they use the same infrastructure process (VSS) and do both honor the shadow copy space setting.

So, if you set a limit on the space that shadow copies are allowed to take on the disk where the backups are written to, and that limit is reached, Windows backup will delete older shadow copies from the backup disk to make room for the new backup. This is Windows Server Backup automatic disk usage management at work.

Now, if your backups consist of multiple volumes (as is the case in full server backups e.g. System Reserved + C: + D: etc.) and Windows backup decides an entire volume's shadow copy needs to be deleted, it will take a full backup of that volume again. That's why backups may suddenly and unplanned take much longer than exspected : there may be a volume full backup going on instead of an incremental one (and you are losing older backup copies at the same time).

On Windows server, you manage space for Shadow Copies by rightclicking on any drive, Properties, Shadow copies. Then identify the drive where your backups are stored (click on Settings-Details to see more volume/drive information). The crucial point is that the shadow copy maximum size setting is always in effect (Settings, Maximum size: (o) No limit or (o) Use limit), regardless if shadow copies scheduling to this drive is enabled or disabled ! (This is a typical example of a badly designed dialog box, where a setting is on a deeper level, suggesting it is dependent on a higher level setting, while it is actually independent)

Conclusion: in the Shadow Copies settings for a backup disk:

  • shadow copy scheduling should be set to Disabled (you don't want Windows to create shadow copies of the backup disk's contents)
  • Maximum Size should be set to (o) No limit (to allow Windows backup to use the entire backup disk capacity to store backups as shadow copies)

For a thorough explanation of shadow copy usage for backups see: A Closer Look at Windows Server Backup (and where did my backup files go?)

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.