01-26-2021 10:03 AM - edited 01-26-2021 10:04 AM
We have discovered some of the System State Components are missing from our Backups. While we are trying to restore the server's system state, the recovery is failing. System state backup along with Filesystem backups are getting completed without any issues. These components also remain unavailable while performing windows native backup. This issue is under investigation with Microsoft.
At the same time, we would like to have one script created which will be used as bpstart_notify batch script which will check the following components before the backup gets triggered. If the components are missing, the backup will not get triggered.
ASR - Automated system recovery
Background intelligent transfer server
COM + class registration database
vss express writer store
windows management instrumentation
Can anyone help me with such a script? Or if there is an alternate option for this. Thanks in advance.
01-26-2021 11:52 PM
I would try to find out why these items are not backed up. The fact that Windows backup has the same issue is big red flag.
If you use BAR GUI on the client, can you drill down in the Backup tab and see those items?
I previously had an issue where a drive path was not backed, but backup completed with status 0.
We obviously only realized when a restore was needed.
If memory serves me right, we increased bpbkar logging to level 5 and started a manual backup.
It turned out that 'someone' added the folder to FilesNotToBackup registry key.
Please also have a look at NBU Admin Guide I at the different components included in System State directive and Shadow Copy Components directive.
01-27-2021 10:19 AM
Just to throw this into your head, I would really REALLY recommend not skipping the backup because one of those components was missing according to a script. Even assuming you put a script together that works for that, you've just opened a huge audit hole for yourself that I guarantee you'll fall into.
"So, why was this server not backed up for 6 months ? "
"Because the script told it not to." (this is what is known as a Resume-Generating-Event)
Backup errors are valuable data points. They can be ticketed. They can be reported on. The can be audited. The tickets can even be auto-routed to the Windows team's queue to actually fix the issue (which is what it sounds like needs to happen here).
I highly encourage you to never skip backups without auditable paperwork in place behind it. If someone wants backups stopped on a server until an issue is fixed, great - submit a ticket. If backups need to be stopped until they have more space available, great - ticket. Until their migration project is done - ticket. Once backups can be restarted again - ticket.
I'll also point out that sometimes what you need is daily failure tickets getting sent to someone for them to finally prioritize fixing an issue properly. =)