Over a million developers have joined DZone.

Backup Log Checks and What They Can Tell You

DZone 's Guide to

Backup Log Checks and What They Can Tell You

Ed Tittel shares how your backup logs can tell an important story and how to capture those log files to administer checks.

· Performance Zone ·
Free Resource

There is simply no substitute for a recent, accurate backup when it comes to recovering from file or system damage or outages. But that backup must be complete and error-free to make a full recovery possible. That’s why inspecting log files from backups is a critical and important step in verifying their accuracy or coverage, and a necessary check before performing a restore that converts any backup image or files into production status.

Your backup logs tell an important story. Every backup facility we know of records status messages as backup is underway, and provides a summary report when the backup job concludes. Thus, you might see this in those log files to report on backup results (in %Windir%\Windows\Logs\WindowsBackup on clients, and in %Windir%\Windows\Logs\WindowsServerBackup on server PCs)

Backup of volume \\?\GLOBALROOT\Device\HarddiskVolume14\ succeeded.
Backup of volume C: succeeded.
Backup of volume \\?\Volume{85678ac2-9b8a-4d31-9dcd-7247ff78241c}\ succeeded.

A successful outcome means you can restore the backup without being concerned about internal issues in the backup data that’s being restored, and is an essential check before initiating such activity. If, on the other hand, a review of the log file produces something different it may be a different story. Here are some samples, by way of illustration:

Backup of volume \\?\GLOBALROOT\Device\HarddiskVolume14\ succeeded.
Backup of volume C: succeeded, but some files were skipped.
File \\T520\Music\Albums… skipped: not present
File \\X220T\Music Albums… skipped: not present
Backup of volume \\?\Volume{85678ac2-9b8a-4d31-9dcd-7247ff78241c}\ succeeded.

The preceding log indicates that files were skipped during the backup, but careful inspection of the file specifications indicates that the files were omitted because they originate on other PCs, as indicated by the UNC names that appear at the head of each skipped item. This means that it’s still OK to restore the backup. Even though not all linked files are present, these will not affect its restoration nor will they affect the PC itself after the backup is restored.

On the other hand, consider a log trace like this instead (or perhaps one with a large number of reports of damaged or corrupted files):

Backup of volume \\?\GLOBALROOT\Device\HarddiskVolume14\ succeeded.
Backup of volume C: failed.
File C:\Windows\regedit.exe\ is damaged and could not be copied.
Backup of volume \\?\Volume{85678ac2-9b8a-4d31-9dcd-7247ff78241c}\ succeeded.

Capturing the Log Files

Deciding whether or not to restore the backup requires deciding whether or not the system can function properly without those files present. For system components or key data files, it’s best not to use such a backup for restoration unless there are no other options. In that case, you’ll need to use the log file to guide manual repairs (or use a tool like the Windows Deployment Image Servicing and Maintenance took, aka DISM.exe, or the system file checker, aka SFC /scannow, to perform repairs where applicable).

Backup log checks can also provide information about the freshness of the data involved, which may be important if you are trying to roll a system back to eliminate malware that may have been introduced in the wake of a known or recognizable event with a definite time stamp. Individual data files that haven’t been compromised can be brought into an older image once it’s been updated and patched as a way of stitching together a runtime that is free of infection and as current as possible.

The same principles apply to those archives as for backups, though with 9-nines durability and 2-nines availability, there shouldn’t be anything to report from an integrity or availability standpoint. But that archive discussion also makes it clear that such archives can serve important compliance requirements, to prove that sensitive data related to PCI-DSS or HIPAA has not been tampered with. The same thing goes for other log data that may need to be retained for legal discovery purposes, or to demonstrate adherence to the terms of security policy, legal agreements or settlements, and so forth.

Thus, backup logs cannot only tell you whether or not to use some specific backup to perform a restore, they can also document system snapshots at various specific points in time. The data in these snapshots may be needed later on to prove compliance, or to demonstrate adherence to some legal agreement or the terms of some legal settlement. That’s why checking backup logs is so important when working with backups and dealing with retained or historical system logs and other data.

Editor's Note: This post originally appeared on the company blog of Logentries. Logentries is a company that offers a product by the same name. It has ten integrations with other products, including Docker and Slack, as well as AWS-based S3 archiving and scalability. You can learn more about it here.

performance ,backup logs ,log entries

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}