Windows Server Backup - listing of files that were backed up

I have used BackupAssist for about 14 years now on multiple servers.  It scripts the native backup and adds all of the features not so easily added such as email notification, logging, etc.
https://www.backupassist.com/

Can I ask why you want this?  As previously stated in your other questions, the entire technology of backup has changed.  You seem to be trying to hold onto "old school" methodologies when they are unnecessary.

Windows Server Backup is a VOLUME IMAGE backup, not a file backup.  So there are no skipped files.

I have read this in the meantime - https://www.techwalla.com/articles/the-location-of-the-windows-backup-log.  

Also this - https://social.technet.microsoft.com/Forums/windows/en-US/bbd398bd-aab4-4719-bc2a-9aa05c0057f3/how-do-i-read-the-windows-7-backup-log-file-etl?forum=w7itprogeneral

https://social.technet.microsoft.com/Forums/office/en-US/1cdb9617-7ea5-4f5a-a89a-e492a118920c/backup-log-location?forum=winserverfiles

So it seems there are several ways of seeing what I want.  They look pretty simplistic however. Has anybody found a utility/script/third party that might make these a little more user-friendly?

Please note that I am well aware of other backup programs out there - so I am not asking this information out of ignorance - nor my other questions.  I can google like anybody else - nobody who is in IT would not know there are backup programs out there outside of Windows Server backup that have all kinds of features/benefits that WSB doesn't have. I just want to deep dive into Windows Server backup as far as I can and my hope was that somebody on Experts would have some of the answers so I can benefit from their deep dive.  If you are not interested in WSB understood. Not trying to sell it to anybody else. Just looking for Experts about it.

The only thing that will be listed on a "Skipped" file log would be locations that aren't able to be backed up (such as a redirected folder that is not actually located on the machine you are backing up)"

Older backup applications that ran file-level backups would skip a file if it was in use -- this does not happen with Windows Server Backup since it uses VSS and is able to capture an entire volume image.  If there is a problem running the backup, it will abort on the ENTIRE VOLUME (ie, "D: Drive"), not just a single file.

If you check the Status Report at the conclusion of a backup it will just let you know if each component (ie, Drive/Volume, System State, etc) succeeded or failed.

So -- your question: "Has anybody found a utility/script/third party that might make these a little more user-friendly?"  is probably not going to get an answer because it is a pointless endeavor.

Backup Assist scripts the backup jobs and then uses the native backup for the actual work which gives you additional options in the event of a catastrophic failure.  Just the feature of an  email with its results, every time it runs, is well worth the price and not having to learn the arcane specifics of each version of the native backup adds to its value.

I will take a look at the powershell. Thanks.

Lionel MM:

I went through the Powershell - could not find anything that would spew out a report with file sizes.  Perhaps I am missing something.  do you have knowledge if there is something in Powershell that would do this.

Lionel,
Your initial question did not ask for the file sizes and I would caution you about wanting that granularity in the report.  If you don't purge the log files on a regular basis, they will become huge!
I find it more useful to get a report of the failures and why they failed.
Did you look at BackupAssist?

Sorry for not mentioning file size. Yes, we would want it. We can purge the files.  If it just lists the files that were copied it should not be that much as the backups are differential.  Skipped files would be several  times bigger.  Not interested in any third party software. The report would be a nice to have - not a deal killer for using WSB if not available.

Maybe the easiest thing to do would be to make it simple and just add a dir command to the end of your script and have it go to a text file that will show you the contents of the backup folder, arranged by date, maybe something like this
dir I:\WindowsImageBackup\Computername\*.vhdx /s /od >BackupFiles.Txt

Won't that just show VHDX's?  I want to see the actual files that were backed up.  Windows Server Backup log shows folders but not specific files and their sizes.

VHD's won't ever show their content, only the huge file that is backed up on the host.

I am not sure what is then you are asking for--the existing log files that can be found in C:\Windows\Logs\WindowsServerBackup show what files were backup up and in a another log file which ones failed. For the host of the VMs the vhdx are files and so will backup that file when it has been changed or the backup flag has been set. On the VM itself, if you run a wbadmin backup in it then it will list files within itself, on its virtual disks but for the host (Hyper-V, VM Ware) the virtual disk are simply another file that it will backup if included in the backup list. Here is an example of what mine shows--I am backing up the entire C drive and this shows up in the log file, and when I look in the error log file it is empty so everything was successfully backed up

Backup of volume C: succeeded.

However on my D Drive I am only backup up VM's on that drive so this is the list that shows successful backups, of the virtual disks, not what is within the virtual disks

Backed up D:\
Backed up D:\VirtualMachines\
Backed up D:\VirtualMachines\Server2012Standard\
Backed up D:\VirtualMachines\Server2012Standard\Server2012Std-C.vhdx
Backed up D:\VirtualMachines\Server2012Standard\Server2012Std-D.vhdx
Backed up D:\VirtualMachines\Server2012Standard\Server2012Std-E.vhdx
Backed up D:\VirtualMachines\Server2012Standard\Virtual Machines\
Backed up D:\VirtualMachines\Server2012Standard\Virtual Machines\8B677802-0C25-4E6B-BE7F-29F939FA2D54.xml

So what is it that you are actually asking for?

I would like to see a report of the actual files backed up/skipped and their sizes. So If I run Windows Server Backup from within the VM or even just a physical Windows Server - I am not sure where the HyperV part came in. I did not mention it in my original request.

Hyper-V: I simply assumed you had virtual machines but if if you didn't the same still applies; if there are any files that failed/skipped they can be found in C:\Windows\Logs\WindowsServerBackup but the info you want, namely file size is not there. I have looked on numerous powershell websites to see if I can find a script that will get that info for you and I can't find it. You may want to ask for admin help to ask other experts because I can't add anymore to help you--sorry.

Thanks. I will see if the moderator might be able to help.

Got the message to look at this thread.  I think your question has been answered multiple times.  In case it has not been clear:

There are NO files and NO file sizes that have been backed up.  The initial backup copies all the 0s and 1s to the target, the subsequent ones copy the new or changed 0s and 1s to the target in block increments.  No files, no file sizes.  WSB is ignorant of any such.

Therefore, your question:  "could not find anything that would spew out a report with file sizes.  Perhaps I am missing something."  is not meaningful, except you are missing that there aren't any.

Actually when you go to recover you can recover a single file and there is a date beside that file so Windows is keeping track of all files and the dates they were backed up - it is not 0's and 1's - it has stored the name and date of the files backed up.  Then when you recover the file it shows clearly in Data Transferred the size of the file recovered.  So all the info is there - Windows is keeping track of what was backed up when and its size.  It's not 0's and 1's at some level - WSB is very cognizant of what it has backed up - it just seems that the Windows Server Backup team is not forthcoming on how we can access the info other than by using this laborious method for every file.

This is a dead end.  Yes, there are file names and dates.  But there are no files.  What you see when you open recovery is similar to an index in a book (remember those?).  But the file name is only stored one time with links to every incremental backup.  Notice that the files that had NOT changed are listed as well.  You don't have to go back in time and try to figure out when that file was last modified to find the name to restore it.

Similar, but slightly different, to help; understand the point is the PC level backup that Server Essentials or Storage Server does.  In that case it has another index level, which PC.  Because in that case if you have 20 systems all running Windows 7 there is only ONE copy of the OS on the backup media regardless of when the system was brought onto the backup routine.  So, again, file names and sizes are only relevant for indexing purposes as you could restore your PC even though the individual files on it had NEVER been "backed up" in the way you are thinking about it.

Thanks for the further detail.  I still maintain that MS could put a report together as I have wanted - it can generate the file name, the size and the date.  That the file name is linked to a bunch of differentials is  not a deal stopper.  In any case I agree we have reached a dead end. The ball is in MS's court - I have actually put it there.  I will let you know if anything comes of it.

Thanks for the deep dive.

Ok, this is my last try:

"it can generate the file name, the size and the date"

No, it can't.  There aren't any.  just 0s and 1s.  In any case what good would it do you to know that .02% of file1 and .22% of file2 and 98% of file3 were backed up on "date".  Because that is what it does.

It generates all the information already - just not in one place and not easy to read.  I can determine every last piece of information I want - manually one file at a time - no powershelll, no programming.

This came as close as possible to somebody actually trying to provide me with an answer related to the question I asked.  It didn't actually fill the need but the person was listening.