DB2 Archive Backup Not running after upgrading the Client to NetBackup 10
After upgrading the NetBackup client to NetBackup 10 Vendor method is not working for archive backup. We have upgrade the client from NetBackup 8.1.1 to 10. Only one node is upgraded. Still archive backups get success in node 2. In node one Archive backup not starts. Vendor method is configured for theLOGARCHMETH2. Please check the following output for the configured archive methods and status. $ db2 get db cfg for xmndb | grep -i logarc First log archive method (LOGARCHMETH1) = DISK:/dbarchfs/ARCH_LOGS/ Archive compression for logarchmeth1 (LOGARCHCOMPR1) = OFF Options for logarchmeth1 (LOGARCHOPT1) = Second log archive method (LOGARCHMETH2) = VENDOR:/usr/openv/netbackup/bin/nbdb2.sl64 Archive compression for logarchmeth2 (LOGARCHCOMPR2) = OFF Options for logarchmeth2 (LOGARCHOPT2) = $ db2pd -logs -db XMNDB Database Member 0 -- Database XMNDB -- Active -- Up 386 days 04:28:00 -- Date 2022-06-22-18.09.06.272877 Logs: Current Log Number 197201 Pages Written 135447 Cur Commit Disk Log Reads 1 Cur Commit Total Log Reads 3 Method 1 Archive Status Success Method 1 Next Log to Archive 197201 Method 1 First Failure n/a Method 2 Archive Status Failure Method 2 Next Log to Archive 197201 Method 2 First Failure 197099 Log Chain ID 1 Current LSO 201380592994029 Current LSN 0x0000003488E917A2 Address StartLSN StartLSO State Size Pages Filename 0x0A000401352DEDA0 0000003488D87D5D 201380040909505 0x00000000 262144 262144 S0197201.LOG 0x0A000401348FCA00 0000000000000000 201381109408449 0x00000000 262144 262144 S0197202.LOG 0x0A00040134396360 0000000000000000 201382177907393 0x00000000 262144 262144 S0197203.LOG 0x0A000401348FADE0 0000000000000000 201383246406337 0x00000000 262144 262144 S0197204.LOG 0x0A0004013439CCC0 0000000000000000 201384314905281 0x00000000 262144 262144 S0197205.LOG 0x0A00040134900000 0000000000000000 201385383404225 0x00000000 262144 262144 S0197206.LOG 0x0A000401352EA360 0000000000000000 201386451903169 0x00000000 262144 262144 S0197207.LOG 0x0A000401352E92C0 0000000000000000 2013875204New Exchange 2019 features and new headaches
FYI: New 8.2 environment backing up Ip-Less DAG on new Exchange 2019 running on Windows 2019 Core Servers. Backup is working ok, restores not so much. We suspect that a new feature in Exchange 2019 causes the restore to fail at the commit/mount database stage. In Exchange 2019 they have implemented a SSD cache database, for quicker searches etc, that are referenced by all mail databases. When you restore an entire database, eg EXDB01, to a recovery database, eg RDB01 , the recovery database have no reference to the cache and mounting the database fails. Progress log filename : N:\Program Files\Veritas\NetBackup\Logs\user_ops\nbadmin\logs\jbp9FAC.tmp.log Restore Job Id=145846 Restore started 08/14/2019 10:33:14 10:33:14 (145846.xxx) Found (4608) files in (1) images for Restore Job ID 145846.xxx 10:33:25 (145847.xxx) Found (4608) files in (1) images for Restore Job ID 145847.xxx 10:33:33 (145847.xxx) Searched ( 10) files of (4608) files for Restore Job ID 145847.xxx 10:33:33 (145847.001) Restoring from copy 1 of image created 2019-08-14 10:27:26 from policy Silver_Exchange2019_DAG 10:33:53 (145847.001) INF - Beginning restore from server xstobup01.ref.xxx.xx to client XSTOEX41.REF.XXX.XX (client_hostname XSTOEX41.REF.XXX.XX). 10:33:55 (145847.001) TAR - Microsoft Exchange Database Availability Groups:\ 10:33:55 (145847.001) TAR - Microsoft Exchange Database Availability Groups:\xstoexdag41\ 10:33:55 (145847.001) TAR - Microsoft Exchange Database Availability Groups:\xstoexdag41\Microsoft Information Store\ 10:33:55 (145847.001) TAR - Microsoft Exchange Database Availability Groups:\xstoexdag41\Microsoft Information Store\EXDB01\ 10:33:55 (145847.001) MNR - The file was renamed to the following: 10:33:55 (145847.001) UTF - Microsoft Information Store:\RDB01\ 10:34:22 (145847.001) TAR - Microsoft Exchange Database Availability Groups:\xstoexdag41\Microsoft Information Store\EXDB01\Database 10:34:23 (145847.001) MNR - The file was renamed to the following: 10:34:23 (145847.001) UTF - Microsoft Information Store:\RDB01\Database 10:34:26 (145847.001) TAR - Microsoft Exchange Database Availability Groups:\xstoexdag41\Microsoft Information Store\EXDB01\Logs_1565771088 10:34:27 (145847.001) MNR - The file was renamed to the following: 10:34:27 (145847.001) UTF - Microsoft Information Store:\RDB01\Logs_1565771088 10:34:36 (145847.001) INF - There are no jobs remaining for this restore request. Exchange database recovery will be performed. 10:34:37 (145847.001) INF - After restoring a Microsoft Exchange LCR, CCR, or DAG database, you must use the Exchange Management Shell to resume replication. 10:35:01 (145847.001) WRN - MountDatabase failed with error(0x0) for machine xstoexdag41, storage group RDB01, database RDB01 10:35:01 (145847.001) WRN - Exchange database recovery may have failed. Please check the event log for further details. 10:35:01 (145847.001) ERR - An Exchange restore error was detected. You may need to manually mount the Database stores to successfully finish the restore. 10:35:01 (145847.001) INF - TAR EXITING WITH STATUS = 5 10:35:01 (145847.001) INF - TAR RESTORED 6 OF 6 FILES SUCCESSFULLY 10:35:01 (145847.001) INF - TAR KEPT 0 EXISTING FILES 10:35:01 (145847.001) INF - TAR PARTIALLY RESTORED 0 FILES 10:35:01 (145847.001) Status of restore from copy 1 of image created 2019-08-14 10:27:26 = tar did not find all the files to be restored 10:35:01 INF - Server status = 5 10:35:02 (145846.xxx) INF - Status = the restore failed to recover the requested files. 10:35:02 INF - Server status = 2810 10:35:02 (145847.xxx) INF - Status = MS-Exchange-Server policy restore error. FROM EXCHANGE SERVERS ERROR LOG: msexchangerepl (5708,U,98,15.02.0330.008) RDB01\XSTOEX41: Database recovery failed with error -1216 because it encountered references to a database, C:\ExchangeMetaCacheDbs\EXDB01\EXDB01.mcdb\EXDB01-mcdb.edb', which is no longer present. The database was not brought to a Clean Shutdown state before it was removed (or possibly moved or renamed). The database engine will not permit recovery to complete for this instance until the missing database is re-instated. I have just now started a case with Veritas support.
Backup Exec Beta registrations are now open!
We are currently recruiting customers who are interested in participating in upcoming Backup Exec Beta program. This NEW Beta program for upcoming release of Backup Exec contain some new features such as Disaster Recovery to Cloud – Powered by Azure Site Recovery (ASR), proliferations such as support for Windows Server RS4, vSphere 6.7, SharePoint 2016 and overall improvements in meeting your recovery time objectives. Please visit the below link and register in this program. Join this Beta Program Please click on above “Join this Beta Program" link to successfully register for this program. You will receive an email notification from us upon successful registration. We are opening registration early to allow enough time to process applications before the Beta build is available for download. So, if you are Veritas partner/reseller, please have your clients sign up early. All applications will be screened for US legal compliance a week or two prior to Beta program start date, which is currently expected to be sometime in June 2018. To join Veritas Customer and Partner Engagement Program, please visit http://cpep.veritas.com/. We look forward to your interest and participation. Best regards, Backup Exec Team Forward-looking Statements Any information regarding pre-release Veritas offerings, future updates or other planned modifications is subject to ongoing evaluation by Veritas and therefore subject to change. This information is provided without warranty of any kind, express or implied. Customers who purchase Veritas offerings should make their purchase decision based upon features that are currently available.