BackupExec Agent for Mac OS X Server not working
I cannot seem to get the BackupExec agent for OS X Server working. I have an XServe running 10.6.4 and RALUS/RAMS 2896.9 (2010r2). I have gone through the installrams script and verified everything is correct. All ports between my server and the backup server are open while troubleshooting this problem. The admin for the backup server has verified everything is correct on his end. Whenever he goes to connect to my server, it is killing the remote agent on my server. I have restarted with the logfile option and can attach if needed. The only thing that stands out to me is that some of the dylib's are not being loaded even though I have added that directory (/opt/VRTSralus/bin) to my DYLD_LIBRARY_PATH variable. Everything else looks normal, at least to me, but the agent is killed when the backup admin tries to connect to it from the BackupExec Console.26KViews0likes6Comments0xe000feb9 - The NDMP subsystem reports (Any real fixes or work arounds)
OK I have seen and read quite a few posts on this matter, with very few solutions. Here is my issue. Here is what I am having for an issue. Iam using the BackupExec 11D (7071) and backing up Windows Systems. The majority of my jobs run fine. There are a few jobs that error out because of the *** Completed status: Failed Final error: 0xe000feb9 - The NDMP subsystem reports that a request cannot be processed because it is in the wrong state to service the request. Final error category: Resource Errors For additional information regarding this error refer to link V-79-57344-65209 **** I have checked out the port 10000 on the affected servers. The port on the affected system is used by Client system I have uninstalled rebooted reinstalled on the affect system with no change. Changing the port on all the servers is not a good option as the amount of systems that is affected is not large, and change it on good systems I fear may cause more harm then good. So anyone have a good solution for htis or a wokr around for the affect systems to be able to back them up? Thanks for any suggetions.24KViews0likes12CommentsBackup Jobs are getting failed with V-79-57344-41488 - Due to one or more errors in \\server\E:, this backup cannot be used for conversion to virtual machines, Simplified Disaster Recovery (SDR), or a complete online restore.
Hello All, We are using Backup Exec 2014 SP2 In a Windows 2012 R2 server as a media server and taking backups of the Clients through Remote agent. Few are windows 2008 server and one of them is Windows 2012 R2 server. The issue started with the Win2012 R2 remote agent while backing up the backup is getting failed for the drives with the above mentioned error.The files are normal flat files. Media Server : Windows 2012 R2 64 bit Remote Agent : Windows 2012 R2 64 bit I have tried to take backup of those problematic folder through WIndows server backup however it got successful in that case. The account which we are using for taking backup is domain user however its been added to remote agents local admin too.But no luck. Would appreciate if any wrokariound or solution can be provided except asking for upgrade it to BE 15 ;) .Solved17KViews0likes10CommentsHow to update Backup Exec Remote Agent For Windows System_
Hi all! I'm excperiencing connecting problems during night becakup to random clients - V-79-57344-65072 "the connection to target system has been lost". I've checked Backup Exec RAWS version at media server as well as on all remote systems - it's 13.0.5204.109. The Backup Exec RAWS version on the media serverin newer than enywhere else - it's 13.0.5204.114. In order to try to resolve this issue I want to update agents first. Is it possible to do it automaticly? The uninstallation process and push install doesn't help - the older version is installed.15KViews1like18CommentsServers disappeared from favourite resources.
Hello, Both of my Backup Exec 2010 R3 installations have started having issues with servers disappearing from under the 'Windows Systems' tree within Favourite Resources on the Selections tab. The backup/restore jobs now fail with the following error: Restore- SQLSRVR-1.tornadowire.local The Media Server was unable to connect to remote machine SQLSRVR-1.tornadowire.local on network interface Local Area Connection. The servers are still communicating fine on the network and I have also re-installed the agents without a problem. Does anybody have an idea what might be going on here? Kind Regards Simon EmmsSolved9.8KViews0likes9CommentsBE Agent for Windows won't install - Error code 1603 Microsoft VC++ Redistributables 2012 x64
Hello all, My team and I have been dealing with this issue for quite a while now. We are trying to upgrade the BE agent on our server. It is a Windows Server2008 R2 Datacenter with Service Pack 1. We previously had BE agent 2010 on it. When we uninstall 2010 and try to install BE agent 14.1 it gives us an error code 1603 saying that the Microsoft VC++ Redistributables 2012 is not the current version. We have checked and verified that it is indeed the current version. We have been on and off the phone with Symantec support and Microsoft support for weeks now and still no resolution. Things we have tried are: - windows updates - moving the RAWSx64 folder and VCredist to the C: drive for local install - moving the RAWSx64 and VCredist folder to desktop for local install - push install of BE agent - clean install from disc - creating a directory C:\program files\Symantec\Backup Exec\Agents\ where I have RAWSx64 and VCredist along with all of the other items located in agents and just about every other option on the support forums. I have read about the security update 2918614 from Microsoft and installing the patch 3000988. I installed the new patch update and it did not work. I tried deleting the update 2918614 and still did not work. I have tried copying the RAWSx64 and VCredist and MSXML to the C: drive and running setup however I get an error saying it cannot run because it failed the checksum requirements. ( I copied those files from the ISO image file). Here is the error I get in the log: 12-22-2014,11:03:21 : C:\Agents\VCRedist\V10.0\vcredist_x64.exe /q /norestart /log "C:\ProgramData\Symantec\Backup Exec\Logs\V10.0_x64_msruntime_install.log" + 12-22-2014,11:03:21 : ERROR - 1314: Failed to load user profile for DOMAIN\USER. 12-22-2014,11:03:21 : Return Value of Microsoft Visual C++ 2010 Redistributable (x64) : 1603 + 12-22-2014,11:03:21 : V-225-299: ERROR: Failed to execute VC 10.0 runtime installer. Error code 1603. ***To search for information about this error, click here + 12-22-2014,11:03:21 : Review this log file for details: C:\ProgramData\Symantec\Backup Exec\Logs\V10.0_x64_msruntime_install.log 12-22-2014,11:03:22 : The return value for Microsoft VC++ Redistributables (x64) returned error code: 1603 12-22-2014,11:03:22 : Clean up Symantec installer keys. 12-22-2014,11:03:25 : AgentSeqDlgs::Misc_BE_CommonOps 12-22-2014,11:03:25 : Dialog Sequence Returning errorlevel 1603 + 12-22-2014,11:03:25 : The Installation Failed! Any other solutions or ideas?Solved8.8KViews4likes19CommentsV-79-57344-34108 - An unexpected error occurred when cleaning up snapshot volumes. Confirm that all snapped volumes are correctly resynchronized with the original volumes. *********** is a corrupt file. This file cannot verify.
Hi, We use BackupExec 2012 SP4 to backup (with an agent installed) a 2008 r2 server that holds among other things a small sql (CCSSQL). The schedualed backup of the server usually fails with the response code:V-79-57344-34108,An unexpected error occurred when cleaning up snapshot volumes. Confirm that all snapped volumes are correctly resynchronized with the original volumes. But,whenever I choose to manually backup it, by clicking on 'Run next backup now', the job is always succesful. The job fails because it cannot verify a couple of files, but Ihave to backup them, they seem to be important. i've already tried all the the KB regarding codeV-79-57344-34108 and non of them seem to apply to my problem. Did any one encounter such a mystery? Many Thanks, Nadav.Solved8.6KViews2likes18CommentsJob fails each time - Error e000fe30 - A communications failure has occurred
Hello, I get the following link when I try to run a backup job that has never run successfully: V-79-57344-65072. I have an agent running on one server running WS 2008 r2, and the BE server is running Windows 2012. The storage unit is a NAS. The BE server is also a file server and it runs like clockwork to the same NAS with no failures. However, the agent running on another server (it's a fax server) has never successfully backed up even a single bit of data; it errors out each time. I've ensured that the agent has local admin access to both the BE server and the local server where it's running, and the NAS allows the same user read/write access (it's actually open to anyone). The server running the BE agent can open and write to the NAS's file share. It can telnet on port 10000 to the BE server and vice-versa. What else can I cover? I tried disabling IPv6 but it still fails each time.Solved8.6KViews1like10CommentsHow to configure the Backup Exec Oracle Agent - Practical Step by Step Instructions
Hi All, I had a few problems with this, even after a support call, so I thought I would publish a detailed "click-here", "click-there" how-to article. 1. First, this should work for at least versions 11d and 12 since I did this on version 12 and compared it to a version 11d installation. I cannot verify that it will work for any other versions. This should also work for DB2 by substituting the DB2 component where I mention an Oracle component since they appear to configure the exact same way, but again, I could not verify this with certainty since I do not have a DB2 database. 2. Start the “Backup Exec Remote Agent Utility” from the “Backup Exec for Windows Servers” start menu group or if the shortcut is missing, from “c:\Program Files\Symantec\Backup Exec\vxmon.exe”. 3. On the “Status” tab, check the “Start the Remote Agent Utility every time you log on” check box. 4. On the “Publishing” tab, check the “Enable the Remote Agent to publish information to the media servers in the list” check box. Click “add” and add the media server IP address or server name. Assuming that your main Backup Exec application is on that server, I recommend using the local host IP address (127.0.0.1) for ease since you would never have to change it if you later change the server name or IP address. NOTE: The definition of Symantec term “media server” is the server where the main Backup Exec services reside. 5. On the “Oracle” tab, click new, and select the “instance” you wish to backup. The user name here should be the Oracle “SYS” user and the proper password. Enter the media server IP address or server name. Again, I recommend using the local host IP address, 127.0.0.1. This user will correspond to the user we will create later during step 7 in the main program in “Network>Logon Accounts”. 6. On the “Database Access” tab, check the “Enable media server authentication for Oracle and DB2 operations” check box. Enter the user as Domain\Administrator and click the “Change password” button and set the proper password for the Domain\Administrator account. This user will correspond to the user we will create later during step 8 in the main program in “Tools>Options>Oracle>Modify List”. Check the “Use the full computer name or IP address for Oracle and DB2 operations” check box. Enter the “Name or IP address” of the Oracle Server. Again, since our Oracle was on that server, I used the local host IP address, 127.0.0.1. NOTE: The documentation states that whatever you filled in here to backup, you must use the same exact value to restore. If you use the server name to back up, you will need to use the server name to restore, etc. 7. Go to the main Backup Exec for Windows Servers program. Go to the menu item “Network>Logon Accounts” and click “New”. Add the Oracle user “SYS” with the proper password and hit “OK”. This needs to match the user you created in Step 5 on the “Oracle” tab. If it does not exist, also add the Domain\Administrator user also and set it as default by clicking the “Set as default” button to the right. Add this user even if “System Logon Account” already exists since they need to match the format exactly with the user you entered in the “Database Access” tab of the “Backup Exec Remote Agent Utility” per the Symantec/VERITAS support article 292442. 8. Go to the menu item “Tools>Options>Oracle>Modify List” and click “New”. Add the IP address of the Oracle Server and pick the Domain\Administrator account from the “Logon Account” drop-down box and hit “OK”. This needs to match the user you created in Step 6 on the “Database access” tab. Again, I used the local host IP address, 127.0.0.1, since our Oracle database is on the same server as the Backup Exec. All the information you entered here should correspond to the information you entered in the “Database Access” tab. 9. You should now be able to select your Oracle database as a backup resource. You should also check the credentials for your job by going to the “Job Setup” tab and double-clicking any backup selections you have in the “Backup Selection Lists” pane, then going to the “Resource Credentials” in the left pane, and then hit “Test All”. The computer level at the top should use the Domain\Administrator account, the rest will inherit from that, with the exception of the “Oracle Database”, which should be using the SYS account we created in step 7. If not, highlight it and click “Change” on the right side. Other common problems include the database needing to be placed in “automatic archive log mode” as described in Symantec/VERITAS support article 266835; and the need to change the “Archive Log Mode” from “NOARCHIVE LOG” to “ARCHIVE LOG” (in version 9, in the Oracle Enterprise Manager Console, go to “Network>Databases>DatabaseName>Instance>Configuration” and then to the “Recovery” tab, and check “Archive Log Mode” box. This needs to be done as the Oracle SYS user and this can be changed in “Configuration>Edit Local Preferred Credentials” if necessary. KEYWORDS: 0xe0001403; 0xe0001014; “Failed to access Oracle database”; “Cannot start an Oracle session. Check that the logon credentials are correct, and have sufficient privileges.”; “The database is in NOARCHIVELOG mode and is OPEN. To back up the database when it is in NOARCHIVELOG mode, the database must be MOUNTED but not OPEN.” Relevant Symantec/VERITAS support articles regarding common errors, setup, backup, and restoration using the Oracle agent: 266835; 292497; 292442; 300135; 300134; 300133; 300130; 300119; 300125; 300123; 300118; 300116. You may also go to this page for a complete list of Backup Exec for Windows Server support articles, including those regarding the Oracle agent: http://seer.entsupport.symantec.com/docs/BEWNT_index.htm. Best Regards, Kevin Cotreau MCSE+I, MCNE, et al.Solved8.1KViews3likes8Comments