"Rman Backup Error du to "ORA-12269: client uses weak encryption/crypto-checksumming version
When Taking backup for Oracle data base I keep getting the below error: RMAN-00571: ====================================================== RMAN-00569: ============ ERROR MASSAGE STACK FOLLOWS ============= RMAN-00571: ====================================================== RMAN - 12001: Could not open channel ch02 RMAN-10008: Could not create channel context RMAN: unable to connect to target database ORA-12269: client uses weak encryption/crypto-checksumming version
Unable to connect to the database (Status 252) + 2505
Hello Veritas community, We're running a master server + media server (Linux versions) on NetBackup 8.1. NetBackup processes started failing with database connection errors. Our first step in trying to resolve this was to stop the NetBackup processes and restart them. Unfortunately, that did not resolve our issue. I have been digging through posts and found the common semaphore issue, but the values set seem to be ok (posted below). I'm also adding a few error logs from /var/log/messages. Any help or direction would be greatly appreciated. Thank you https://www.veritas.com/support/en_US/article.100023842 Semaphore settings output: sysctl -a | grep kernel.sem kernel.sem = 400 307200 128 1024 kernel.sem_next_id = -1 ============ /var/log/messages Apr 8 07:28:12 <master_hostname> bash: Error receiving command message: No data to receive from socket. # THIS BLOCK MAY BE RELEVANT (I replaced our actual hostname with master_hostname) Apr 7 09:25:45 <master_hostname> SQLAnywhere(nb_<master_hostname>): Opening dbspace 'EMM_DATA' in file '/usr/openv/db/data/EMM_DATA.db' for database 'NBDB' Apr 7 09:25:45 <master_hostname> SQLAnywhere(nb_<master_hostname>): Opening dbspace 'EMM_INDEX' in file '/usr/openv/db/data/EMM_INDEX.db' for database 'NBDB' Apr 7 09:25:45 <master_hostname> SQLAnywhere(nb_<master_hostname>): Opening dbspace 'DBM_DATA' in file '/usr/openv/db/data/DBM_DATA.db' for database 'NBDB' Apr 7 09:25:45 <master_hostname> SQLAnywhere(nb_<master_hostname>): Opening dbspace 'DBM_INDEX' in file '/usr/openv/db/data/DBM_INDEX.db' for database 'NBDB' Apr 7 09:25:45 <master_hostname> SQLAnywhere(nb_<master_hostname>): Opening dbspace 'DARS_DATA' in file '/usr/openv/db/data/DARS_DATA.db' for database 'NBDB' Apr 7 09:25:45 <master_hostname> SQLAnywhere(nb_<master_hostname>): Opening dbspace 'DARS_INDEX' in file '/usr/openv/db/data/DARS_INDEX.db' for database 'NBDB' Apr 7 09:25:45 <master_hostname> SQLAnywhere(nb_<master_hostname>): Opening dbspace 'JOBD_DATA' in file '/usr/openv/db/data/JOBD_DATA.db' for database 'NBDB' Apr 7 09:25:45 <master_hostname> SQLAnywhere(nb_<master_hostname>): Opening dbspace 'SLP_DATA' in file '/usr/openv/db/data/SLP_DATA.db' for database 'NBDB' Apr 7 09:25:45 <master_hostname> SQLAnywhere(nb_<master_hostname>): Opening dbspace 'SLP_INDEX' in file '/usr/openv/db/data/SLP_INDEX.db' for database 'NBDB' Apr 7 09:25:45 <master_hostname> SQLAnywhere(nb_<master_hostname>): This database is licensed for use with: Apr 7 09:29:33 <master_hostname> SQLAnywhere(nbappdb): Starting database "NBAPPDB" (/opt/NBUAppliance/db/data/NBAPPDB.db) at Wed Apr 07 2021 09:29 Apr 7 09:29:34 <master_hostname> SQLAnywhere(nbappdb): This database is licensed for use with: Apr 7 10:15:30 <master_hostname> SQLAnywhere(nbazdb): Starting database "NBAZDB" (/usr/openv/db/staging/NBAZDB.db) at Wed Apr 07 2021 10:15 Apr 7 10:15:33 <master_hostname> SQLAnywhere(nbdb): Starting database "NBDB" (/usr/openv/db/staging/NBDB.db) at Wed Apr 07 2021 10:15 Apr 7 10:15:33 <master_hostname> SQLAnywhere(nbdb): Opening dbspace 'EMM_DATA' in file '/usr/openv/db/staging/EMM_DATA.db' for database 'NBDB' # SAME BLOCK STARTS OVER AT THIS PIONT ============
Symantec Exec 12 unable to backup some idb files By: Ricky Yau
Hi, I used Symantec Exec 12to backup a database server but I found that it has more exceptions (over 100 idb files can't be backup). It will affected the server restoration. How to setup the backup job for backup db server (idb files)? Unable to open the item \\xxxx11IDB02b\[ROOT]/data/accdb/SYS_ACCCMDVERBTBL.ibd - skipped. Unable to open the item \\xxxx11IDB02b\[ROOT]/data/accdb/ENTP_QUOTATBL.ibd - skipped. Unable to open the item \\xxxx11IDB02b\[ROOT]/data/accdb/SYS_ROLEACCTBL.ibd - skipped. Unable to open the item \\xxxx11IDB02b\[ROOT]/data/accdb/system_servertbl.ibd - skipped. Unable to open the item \\xxxx11IDB02b\[ROOT]/data/accdb/system_server_iptbl.ibd - skipped.
Restoring emails from backup Exec 2010 fails
I have been tasked to recover some emails from an old tape based backup created with Backup Exec 2010. I have spun up a VM of SBS 2003 as this was what the backups were created on. I've set it up with the same domain details as the original server (that no longer exists). I've loaded up backup exec 2010 R3, inventoried and catalogued the tapes. Tested restore of files from drives stored in the backupsand all is fine. Restore completes without issue. Ican see the microsoft exchange mailboxes in question on the backup. One of the mailboxes in the backup has a warning x symbol on it and its status is 'corrupt or contains corrupt items'. All the other mailboxes appear with the status 'normal'. It is one of these 'normal' mailboxes that i want to recover some emails from. I start a restore job, select the emails, Set the settings in backup exec under 'exchange' to automatically recreate user accounts and mailboxes', dismount the database before restore and commit and mount database after restore. I then start the restore. The job then fails with the following error: 'A checksum of the data has failed.' I am wondering if the whole exchange database is corrupt in the backup. My question is, how can i get the exchange database 'out' of the backup, so i can try and run some utilities on it to recover the emails? Many thanks MatthewBackup Exec 2014 Deduplication Disk Offline - spauser database corrupt - solved
We have a BE2014 backup media server running on Windows Server 2012 R2 doing a B2D Deduplication Storage. The system is virtualised using VMWare ESXi v5.5. We had a strange issue where a faulty NIC Driver on (E1000e) on the VM would cause the server to lose connectivity for a few seconds and then automatically come back up causing disruptions and backup failures.The system is running the latest VMWare Tools. Such events are logged in Event Viewer / System Logs as Event 27 and 32. This has been a confirmed problem by VMWare but no fix has been offered except to replace the virtual nic with their recommended "VMXNET 3" Driver. We followed the workaround and replaced the Virtual NICs with the VMXNET 3 and the problem went away, but after a restart of the server, when we tried to bring our storage devices back online, the Deduplication Storage failed with an error something to the extent of "Unable to Authenticate OpenStorage Device". All services including the BE Dedup Agent, Manager, and PostGres DB were running, as the online troubleshooting documentation told us to check. We tried rebooting and restarting all BE Services with no avail. We did some research and found out that there are two user accounts used to operate the Deduplication Storage, one is the one that is configured via the GUI, and another that is automatically created in the embedded POSTGRES database. We reset the password back to the usual one when everything was still working in the GUI, and then tried to reset the second account using the "spauser.exe -c -u <username>" to update the password in the database, the GUI Portion worked but the when trying to update the DB Password it asked for the old password, and none of our passwords worked, even though we have never changed it. The dedup was working until the NIC issues, this led us to believe that the database was corrupt, and there was no literature online to tell us how to solve it. It simply stated that if you forget your old password, you would not be able to bring the Dedup back online and to simply delete and recreate the drive and start over, implying all your old backups would be lost forever. We were in uncharted territory at this point, so we deleted the Dedup Drive in the BE Console and then backed up the entire folder dedup folder with all our existing backups in it to other media, and then renamed it to CORRUPT_BackupExecDeduplicationStorageFolder and created a new dedup device which came online without any issue. This created a brand new uncorrupted user authentication database under D:\BackupExecDeduplicationStorageFolder\databases\spa\database\authentication\ . We then went into that folder and opened up the file named "1" which contains the username and password hash of the account used for the Dedup Device. This file is also what "spauser.exe" and the Dedup Engine uses to authenticate against when bringing the Dedup Device online. "spauser.exe -l" shows this as "User 1". Contents of this file: 0|BEDedup.User|75a9505d992fec489f96ab92619812a1| Likely in the format of DBIndex|UserName|md5PasswordHash| Now we have a fresh and working username and password hash that we know is not corrupt and know the password to, which we tested and authenticated successfully against using the "spauser.exe -c -u BEDedup.User" command. Next we then shutdown all the BE Services and renamed the current (New) D:\BackupExecDeduplicationStorageFolder\ to D:\NEW_BackupExecDeduplicationStorageFolder and the original one with all our backups back to D:\BackupExecDeduplicationStorageFolder\ and went into the D:\BackupExecDeduplicationStorageFolder\databases\spa\database\authentication folder and replaced file contents of "1" with the newly generated password hash (username remains the same as this is required), and restarted the BE Services. Just like that all the services started normally, and BE started to Discover the device, afterwards we were able to do an Inventory and Catalog, and the device was back online! This method in theory can also be used to reset the password without entering the "Old Password:" if you have forgotten it. During the course we have learned that the password hash is simply an unsalted md5 hash, so if this ever happens again, we could use a md5 hash generator to create the new hash instead of having to delete and recreate a new Dedup Device. This is extremely strange has we had never changed the password before. The md5 hash in the corrupted "1" file doesn't match with any other password that we have used in the past either. Hope this helps someone with a similar issue, of course backup the folder before you start making any modifications to the database files in the Dedup Folder! Cheers!
