Last updated at Mon, 06 Nov 2017 21:04:42 GMT
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
Logentries can capture log data from any source. With support for Windows, Linux and much more centralizing, reporting and alerting off of your log data has never been easier. Try it out for yourself! Sign up for a free 30-day trial.
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 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.
Logentries offers AWS-based S3 archiving for the backup logs and files you stream to the company’s Datahub. 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 can not 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.
