Backup Exec 20.3 now available to modernize your Data Protection
Backup Exec 20.3 is now available with Day 1 support for Microsoft Windows Server 2019 and Microsoft Exchange Server 2019, new GDPR Guard capability for compliance enforcement, support for Alibaba Cloud, support for VMware vSphere 6.7 Update 1, Granular VMware VM-disk backups, enhanced job logic persistence and more.
Retry Only Failed Resources in Backup Job with Backup Exec™ 20.3
Administrators usually have SLAs to protect all the important resources and have a restore point in time ready. Backup job can be configured to backup several resources in the same job. When such job is successful for some of the resources and fails for some, the latest recovery point is available only for the resources for which job succeeded. For example, a job backed up 10 out of 12virtual machines and failed for 2 virtual machines. In such scenario, the administrator has the following options: Rerun the entire failed job: This takes a lot of unnecessary time and space since resources already backed up are backed up again. Create a new job only for failed resources Job creation, configuration takes a lot of time. Introducing 'Retry Only Failed Resources' option Backup Exec™ 20.3 introduces a new option to ‘Retry Only Failed Resources’, which addresses this problem by giving you an option to run a failed job for only the failed resources. When this option is selected, the job will run for only the resources which failed in the previous run of the job. This option can be selected by doing right-click and select ‘Retry only failed resources’ in the Backup Exec console. The option is available in all places where ‘Run now’ option is present. This option is available for backup jobs. This option is enabled only when the most recent run of the job has failed. Backup Exec checks the latest run of the job, whether full backup or incremental / differential backup for failure and the option is enabled. Job logs provides information about the resources which are skipped in the job. These resources were successful in the previous run of the job. Simplified Disaster Recovery’ / ‘System State Protection’ Enabled Jobs If System State Protection is enabled for a backup job, the ‘Retry Only Failed Resources’ option considers all the critical resources. It does not skip the critical resources even if they were successfully backed up in the job which failed for some other resources. This allows Simplified Disaster Recovery at the point in time for the retried job. This option is not designed to work as a replacement for the ‘Check Point Restart’ feature. Check Point Restart allows to restart from the point of the failure, at a file level granularity. For example, if NTFS volume E: had 100 files, and backup failed after backing up 50 files, Check Point Restart allows the next run of the job to start backing up from the failed file, that is the 50th file. If a job had D: and E:, and the backup failed for E: but was successful for D:, then ‘Retry only failed resources’ would backup E: entirely (depending on the backup method of the job) but skip D:. Inside the failed resource, ‘Retry only failed resources’ job does not start from the failed file. ‘Retry Only Failed Resources’ is a perfect example of our customer focus and commitment, because this option was requested by customers. If you are not a current Backup Exec customer, we invite you to learn more about the solution at the following link: www.backupexec.com
BE 21.4 randomly hangs but then is ok during backup operations
Hello. We are running BE 21.4 on Windows Server 2022 and at random times during backup operations, the console just hangs and shows not responding but then after several minutes, is all good again. This isn't a huge issue as it doesn't seem to affect backup operations just more of an annoyance. Any suggestions are greatly appreciated.
BE system state backup stuck
Hello, we have a BE server which backups 4 MS Hyper-V servers and a lot of Windows and Linux VM's on these servers. Normally this works just fine, but every few weeks the backup of some of the Hyper-V hosts just get stuck at the backup system state. There is no longer any progress in the backed up files/sizes and the througput of the back just drop and drops. Attached an example of today, where the backup just stuck at 7GB in the system state, the job is already running for 9:33 hours and nothing happens any longer. And the same for the second Hyper-V server, already running for 9:03 hours, 2.75GB backed up and also stuck Also a stop of the backup does not work. We use BE 21.0 1200.2536 and the latest windows 2019 updates. We have seen this many times over the last 2-3 years.
NetBackup SQL job failures - network connection timed out 41
Hi All, This is not a query for help but a note on a solution to a rather pesky problem with NetBackup SQL job failures and status message "network connection timed out 41". While it took me some time to figure out the root cause behind these failures, in the end it turned out to be nothing related to the usual suspects such as DNS/Hosts resolution, network bottlenecks or similar issues. I've been checking literally all aspects of all involved components (NBU Master, Media, Client, SQL DB, networking, etc.) but unfortunately nothing useful appeared in any of the logs. The most misleading part was when tracing error messages such as: ERR - Error in VxBSACreateObject: 3. CONTINUATION: - System detected error, operation aborted. ERR - Error in GetCommand: 0x80770004. DBMS MSG - ODBC return code <-1>, SQL State <37000>, SQL Message <3202><[Microsoft][SQL Server Native Client 11.0][SQL Server]Write on "VNBU0-9280-5168-1609373275" failed: 995(The I/O operation has been aborted because of either a thread exit or an application request.)>. CONTINUATION: - An abort request is preventing anything except termination actions. INFO Server Status: Communication with the server has not been initiated or the server status has not been retrieved from the server. INFO Error in VxBSACreateObject: 3. INFO System detected error, operation aborted. INFO Error in GetCommand: 0x80770004. INFO An abort request is preventing anything except termination actions. INFO ODBC return code <-1>, SQL State <37000>, SQL Message <3202><[Microsoft][SQL Server Native Client 11.0][SQL Server]Write on "VNBU0-8380-13048-1609410056" failed: 995(The I/O operation has been aborted because of either a thread exit or an application request.)>. ...and also SQL errors like: 2020-12-30 23:52:19.11 Backup BackupIoRequest::ReportIoError: write failure on backup device 'VNBU0-9808-5248-1609367774'. Operating system error 995(The I/O operation has been aborted because of either a thread exit or an application request.). 2020-12-30 23:52:19.11 Backup Error: 3041, Severity: 16, State: 1. 2020-12-30 23:52:19.11 Backup BACKUP failed to complete the command BACKUP DATABASE DB01. Check the backup application log for detailed messages. 2020-12-30 23:52:19.11 spid56 Error: 18210, Severity: 16, State: 1. 2020-12-30 23:52:19.11 spid56 BackupVirtualDeviceFile::RequestDurableMedia: Flush failure on backup device 'VNBU0-9808-5248-1609367774'. Operating system error 995(The I/O operation has been aborted because of either a thread exit or an application request.). 2020-12-31 00:00:19.10 spid31s This instance of SQL Server has been using a process ID of 8844 since 12/30/2020 10:23:10 PM (local) 12/30/2020 9:23:10 PM (UTC). This is an informational message only; no user action is required. 2020-12-31 00:10:03.71 Backup Error: 3041, Severity: 16, State: 1. Unfortunately neither "dbclient" nor "bprd" provided any useful indication on what's going on, but at the same time taking SQL backups natively via SQL Management Studio worked just fine. So, long story short... If you encounter such messages and you are using SQL instances in a VMware virtualized environment, make sure to check also against your "VSS appliaction quiescing" settings. In case you may have this set to "disabled", then this could be very much the source of the issue as it was in my case. In normal circumstances quiescing shouldn't be disabled at all, however I've seen many discussions over the years where users are suggesting to do so in order to avoid a long existing problem with failures over generic VM backups about which vendors are fingerpointing to each other but no effective long-term solution has been made available yet. The process of disabling VSS quiesced application based snapshots is outlined on the link below where in my case I had a legacy VM which was applied with the "tools.conf" option. https://kb.vmware.com/s/article/2146204 After removing the "vss.disableAppQuiescing = true" line from the "tools.conf" file the backups started to work immediately. I didn't test if disabling the disk UUID would end up with the same results but if I get a spare moment, then I may actually check it and report back here on the results. Perhaps this whole scenario should be tested by NetBackup engineers and in case they can confirm the behavior then a side note on the below link would be appropriate: https://www.veritas.com/content/support/en_US/doc/44037985-142651971-0/v15097395-142651971 Cheers
