How-To: Downgrade Backup Exec 2012 to 2010 R3
Two months ago I decided to upgrade our backup environment to Backup Exec 2012. I have upgraded Backup Exec in the past and always had relatively few issues during the upgrade process. I had tried to find some detailed information about Backup Exec 2012 but all I could find was some vague descriptions of what was new. I figured I would give it a shot(totally going against my own if it aint broke don't fix it policy). After the relatively smooth upgrade process my jaw dropped at the interface. I thought it was terrible. But I thought I would give it a chance. I eventually got used to the interface although after two months I still preferred the old interface. My problem was the bugs. Maybe it was because I upgraded rather than installed fresh. But over the course of two months I ran into numerous bugs. The application would randomly quit with exception errors. Sometimes during the middle of my jobs it would just stop backing up and I could not perform any jobs (inventory, erase, etc) without restarting the services. It was terrible. I was having to babysit the thing constantly and still not having reliable backups. After working with Support and them telling my to just "repair" the installation and having the same problems, I decided to take matters into my own hands and downgrade. Luckily before I upgraded I made a copy of my Catalog and Data folders that are located in the Backup Exec program files folder. I would like to preface by saying the intro to this article is not meant to start a discussion about the fallacies of BE 2012 - there are plenty of forums for that - just giving a little background on why I chose to downgrade. The following are the steps I used to downgrade my installation. 1. Locate your backed up Data and Catalogs folders.Hopefully, you backed up your Data and Catalogs folder before you upgraded. If you didn't then this article doesn't apply to you. 2. Uninstall BE 2012 choosing to remove everything when asked. 3. After uninstall is complete reboot the server. 4. Install BE 2010 and select the options you need during the wizard, choose to use a new SQL Express instance. 5. After installation run Live Update and update to R3. 6. Reboot the server. It doesn't prompt you to reboot but if you try opening the application it tells you that you need to so go ahead. 7. Stop all the BE services. 8. Navigate to C:\Program Files\Symantec\BackupExec\ and rename the Data folder to Data.new and the Catalogs folder to Catalogs.new 9. Copy your backed up Data and Catalogs folder to the directory in Step 8. VERY IMPORTANT STEP - WILL NOT WORK IF NOT PERFORMED 10. Run thebeutility.exefound in the location from Step 8. Ignore the warning message that pops up when you open it. 11. Select All Media Servers in the left pane. 12. Select your media server in the right-pane and right-click. 13. Select Copy Database. 14. Navigate to the .mdf database file that is located in your Data folder that you copied over in Step 9. 15. Do the same thing for the .ldf log file located in the same location. 16. Press OK. It will run through stopping services re-attaching the database and starting the services again/ NOTE: The first time I did this I didnt do steps 10-16 and the BE services would not start correctly. Thanks to owner ofthis blogI was able to follow their steps and get it going. Big shoutout. 17. You now have an almost fully-restored BE 2010 installation again. It will be running in trial mode. You will still need to contact Symantec Licensing (1-800-721-3934) to get your license keys donwgraded to BE 2010. But at least you can run backups now for 60-days. Now the time-consuming part...This will vary depending on how many servers you are backing up. After I restored my BE 2010 installation I edited my policies and checked my selection list. The first thing I noticed was I was not able to select anything other than user shares on each server. I then proceeded to check my resource credentials. They all failed stating the agent was not installed or the credentials were invalid. I was sure the service account I was using was valid but just to make sure I went ahead and logged into another machine succesfully using it. After I confirmed it wasnt the service account, I knew it was most likely the newer agents I had installed for using BE 2012. I tried to install the BE 2010 agents through the BE 2010 interface. It said they installed correctly but I was still getting the same error. Here is what I did to get the agents going again. 1. Log into each server you are backing up. (I used RDP, but console would work also) 2. Navigate to the backup exec program files unc path located on your media server. ex: \\servername\c$\program files\symantec\backupexec\agents 3. You will see RAW32 and RAW64. These obviously are the Windows installation agents for 32-bit version and 64-bit. 4. Select the appropiate folder for your server architecture and run setup.exe 5. Select the Uninstall option (repair doesnt work - I tried). 6. After the uninstall is complete, run setup.exe and this time install. NOTE: You could also just run the uninstall on all your servers and then re-install the agents using the BE 2010 interface. Actually this would have been my preferred method but I didn't think about it until after I installed all the agents. 7. Most of my servers did not require a reboot but if you get an error about a missing file after the install - uninstall again, but this time reboot after the uninstall and re-install after the server reboots. 8. Go back to your media server and test your resource credentials and selection lists. They should all pass and you should be able to see and select all the drives, SQL database, and Exchange IS'. You are done! I would say for a ~20 server environment this process might take around two hours to complete. It took me much, much longer but I was figuring things out as I went. Like I said the most time consuming part was the agent installs and this will greatly affect how long it takes in your environment. I hope this helps someone out. Again, I'm sure BE2012 is right for someone but for us, we'll stick with 2010 as long as we can. We already bought Avamar and will be moving to that in the next 30 days but we still have to keep BE for at least 7 years
HOW TO install BackupExec 2010 agent on Debian (RALUS)
I hope this post will be useful to many people (please vote for it or mark it as solution if it helps you). Installing directly RALUS on Debian will not always work. First problem : ../perl/Linux/bin/perl: No such file or directory Second problem : at the end "was not successfully installed" and "impossible to add VRTSralus to (server)" And some others that will get solved when following my solution This is a simple way to install it and avoid these (and other) problems : 1. (optional) Create a folder to keep all RALUS files and copy the archive into it : mkdir /root/BE mkdir /root/BE/RALUS2010 mv RALUS_RMALS_RAMS-2896.9.tar.gz /root/BE/RALUS2010/ cd /root/BE/RALUS2010 2. Unpack the archive provided by Symantec tar xzf RALUS_RMALS_RAMS-2896.9.tar.gz 3. Stop the RALUS service if it is already installed and runnig /etc/init.d/VRTSralus.init stop 4. Very important, if you are under a 64 bit Linux you have to this Extract debian package : tar xzf RALUS64/pkgs/Linux/VRTSralus.tar.gz Install debian package : dpkg -i VRTSralus-13.0.2896-0.x86_64.deb Start installation : ./RALUS64/installralus 5. But if you are under a 32 bit Linux you have to this (I didn't tested under 32 bits) : Extract debian package : tar xzf pkgs/Linux/VRTSralus.tar.gz Install debian package : VRTSralus-13.0.2896-0.i386.deb Start installation : ./RALUSx86/installralus or ./installralus 6. Be sure to answer all questions correctly especially the one about the host server (XXX.XXX.XXX.XXX), you must give the IP of the Backup Exec server. 7. Do a restart of the RALUS Backup Exec agent, and it should say "[ OK ]" /etc/init.d/VRTSralus.init start I hope it will help ! Send me questions if you have other problems... Denis P.S. Tested with Debian 5.0.3 P.P.S. If you still have some problems : A) If you get "ERROR: VXIF_HOME is invalid. It must point to the root of VxIF. Exiting ...", simply edit ./RALUS64/installralus, and change line 3 : from : VXIF_HOME=../;export VXIF_HOME to : VXIF_HOME=/root/BE/RALUS2010/;export VXIF_HOME B) If you get "./RALUS64/installralus: line 50: ../perl/Linux/bin/perl: No such file or directory", simply edit ./RALUS64/installralus, and change line 50 : from : ../perl/$OS/bin/perl -I.. -I$PATH -I$VXIF_HOME -I../perl/$OS/lib/$PERL_VER ../installralus.pl $* to : ../perl/$OS/bin/perl -I.. -I$PATH -I$VXIF_HOME -I../perl/$OS/lib/$PERL_VER ./installralus.pl $* or to : perl -I.. -I$PATH -I$VXIF_HOME ./installralus.pl $* (to be clear, remove one dot in front of"/installralus.pl", keep only one dot instead of two) C) If the installation is sucessful but VRTSralus refuses to start, launch /opt/VRTSralus/bin/beremote –-log-console to see the error. If you get error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory you simply need to install the package : Under Debian 6.0.3 : apt-get install libstdc++5 (Thanks to RockwellMuseum)How to use external hard-disks and rotate them
Are you thinking of using external USB or eSata hard-disks for your backups and you also want to rotate them? If you do not know how, read my articles For BE 2012 - https://www-secure.symantec.com/connect/articles/how-rotate-external-harddisks-be-2012 For BE 2010 and earlier versions of BE - https://www-secure.symantec.com/connect/articles/how-rotate-external-harddisks
My BE 2010R3 --> 2012 Upgrade Experience
I hope this will help out other users and also the Symantec tech support team: I would like to preface this by saying that I have been working on trying to get BE2012 installed on my system since it came out. I waited for SP1 with abated breath hoping it would solve my issues, no luck. I went to the forums, emailed tech support, spoke with tech support…all of that, no magic bullet. One of the reasons it has taken me this long was because I didn’t have the amount of consecutive time needed to troubleshoot such an issue. It wasn’t until September that I was able to start dedicating real time to this. We were also having some licensing woes, seems that Dell way over allocated our licensing that I had to take care of. All in all, betMy BE 2010R3 --> 2012 Upgrade Experienceween the licensing and this upgrade issue, I needed to invest about 60 hours of time and it actually may be closer to 80. Symantec Tech Support was of assistance and they were helpful (after explaining the situation what seemed like a dozen times to different people), but unfortunately they couldn’t solve my problem. Here is what started it all, DLO. BE2012 upgrade refused to install if I had the DLO option selected. We don’t use DLO, it was a lingering part of our license that we tested once and found it less useful than anticipated for our situation (using Win7 backup to a network drive and backing up to tape that resultant Win7 backup structure.) OK, so it was unselected, uninstalled, DBs renamed and removed, Symantec had me run a DLO removal tool for x86 and x64, and still, no luck. Registry keys were reviewed, file/folder permissions audited, and yet nothing would work. For months I was going back and forth with a Symantec Tech Support person that PM’d me in the forums. His final response was to wait for 2012SP2, which was to fix some of the upgrade issues. Unfortunately we were using back channels and it ended up needing to stop, I needed to get an official case created. I finally ran that MS Installer Cleanup tool to see if DLO was in there, it wasn’t. However, I did notice 2 BE installs showing up when only one was in Add/Remove programs, R2 and R3. We (Symantec Support and I) also saw this in the registry, however, they told me it wasn’t causing any issues. After working several hours over the phone over several days, the final response was to uninstall BE 2010R3. Hurumph, I didn’t care for that solution, because it isn’t a solution, it is an avoidance. So, I took matters into my own hands. I fancy myself as an excellent black-box troubleshooter but with my job responsibilities I need to unload that work to our various vendors’ tech support, that’s why we pay the support after all. Anyhow, I took the plunge and purged that lingering R2 install using the Installer cleanup. I recalled that the upgrade from SP2 to SP3 would not work using LiveUpdate. I needed to download the manual installer. Even then, the SP2->SP3 update was less than smooth. I suspect this is what caused the whole headache in the first place. So after the cleanup, I ran the upgrade process again and eureka, DLO was no longer showing as an installed product. Hurray!!! The upgrade began to move forward. After about 2 minutes of celebrating, there was another problem. It appeared that nearly all the install registry keys for SP3 had blown ACLs. BE2012 told me it couldn’t access those keys and then would rollback the update to 2010R3. Now, I didn’t realize it was nearly ALL of the keys, I had hopefully thought that it was a manageable dozen or so…Nope, there are 100’s, maybe even over 1,000. Luckily, it was the same key just in lots of places. It appeared that every single BE2010 file had a corresponding installer registry key. So like a good soldier, I began searching for the keys, assigning ownership and then assigning privs., dozens of times. When do you reach the middle of the forest??? After several hours and seemingly not making a dent (or getting to the proverbial middle of the forest), I went and started to look for alternative methods of changing these registry keys. At the same time, I knew because of this registry issue there was a good chance that a repair or uninstall wouldn’t work, so I marched forward with finding a way to discretionarily change reg keys in bulk. However, that search in itself was a challenge. So, I hung my head in defeat and decided to try and uninstall the product and install BE2012. As I suspected, the same keys that were preventing the upgrade also prevent an uninstall, go figure. I was less than hopeful about the repair process and sure enough, the repair failed as well, it just couldn’t read those registry keys. Tried them both twice. So, back to the search for a bulk-registry acl changer. This is the particular key that was causing the problem, it may be different on other systems: D92D4B60317D3FE43B994C43F68BF43F This is the registry path to where all those sub-keys live, but under other keys of course: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components This is a short list of tools I attempted/used to get everything fixed. I tried other things as well, however the below is the most notable. RegEdit would have taken me too long. It is a basic and great tool that works, but in this instance, I would have needed a dozen people finding and fixing ACLs to get it finished in any amount of acceptable time. Powershell (http://technet.microsoft.com/en-us/library/bb978526.aspx) was too cumbersome and I couldn’t get everything just right, although there are some good sites that describe how to use Powershell for situations similar to mine. It probably would have worked if I knew it a little better, but don’t quote me on that. We then thought if PS could generate a list of broken keys, we could create a VBScript or other program to methodically go in and fix it for us, however I didn’t want to spend that kinda dough nor did we have an effective way to test it out. Subinacl (http://www.microsoft.com/en-us/download/details.aspx?id=23510) an older WinNT tool, would be a great option, for 32-bit only. It can’t be fully discretionary, but I can at least start further into the hive so I don’t change too many keys. Problem with this tool is that it does not access the 64-bit registry, where the necessary BE keys live. I found that out after a couple of iterations of trying this solution. SetACL (http://helgeklein.com/setacl/) is a Godsend. It may not be able to support discretionary changes the way I wanted it, but it sure gets the job done. I was able to change the owner and the permissions on all the keys under the …S-1-5-18\Components. The trick with any blown ACL is to set the owner first. This is an important step because if you don’t change the owner FIRST, all other security will fail. In fact, you will likely get an error even when you set the owner first, but that error is a farce. You can check yourself. After the owner is set, you are free to modify the ACL. Be aware you will likely need to add yourself (or the admin group) to the ACL before you actually can open up the key(or folder or file). So, here is the code I ran. NOTE: the SetACL.exe and the two .CMD files I list below need to be in the same directory. You could modify the code to fit your needs if you want a different setup. The options are robust, proceed with caution. ALSO, THESE SCRIPTS ARE FOR MY MACHINE IN PARTICULAR. THEY MAY WORK ON YOUR MACHINE, BUT YOU NEED TO FULLY AUDIT THE CODE BEFORE RUNNING IT ON YOUR SYSTEM. First, I ran the command to set the ownership of all the keys referenced above. I created a txt file, named it owner.cmd and put the below code in. Please note, when running this command, you need to be in a CMD shell that was ‘run as administrator’ and it would be a good idea if the user context you are running this under is also a member of the local server administrators group. SetACL -on HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components -ot reg -actn setowner -ownr "n:Administrators" -rec yes -log setacllog_owner.txt Then, I ran the command to set the ACLs. I created a txt file, named it acl.cmd and put the below code in. SetACL -on HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components -ot reg -actn ace -ace "n:Administrators;p:full;m:grant" -ace "n:DOMAIN\DOMAINADMIN;p:full;m:grant" -ace "n:SYSTEM;p:full;m:grant" -ace "n:Users;p:read;m:grant" -rec yes -log setacllog_ACL.txt Replace DOMAIN\DOMAINADMIN with your particular domain admin user account. After running these 2 scripts, I went and verified I could access those keys in RegEdit, they were accessible. So now, I didn’t want to uninstall, I didn’t want to repair, I just wanted to run through the upgrade. I started the upgrade process. One thing I did not mention before was the DeDupe problem. I could NOT carry over my licenses because as with DLO, the DeDupe option would not fit our needs so we did not license it. BE2012 doesn’t like to upgrade if DeDupe isn’t part of the carry over license. So I selected the trial version of BE2012 to install as mentioned in several other Symantec forums. The upgrade went flawlessly after that!!! Once it was installed, I could enter in all my keys without any problems and deselect that DeDupe option (finally). I sit here with a successful BE2012 updated server now running my first round of full backups. BE2012 is certainly way different. All I need to do now is figure out how to review what the actual job exceptions were and I would have successfully mapped out all the functionality I need to know about. There seems to be some granularity lost with the job setup, for instance, I can’t seem to find how to configure a full SQL Instance backup (we use Simple recovery mode) during an incremental backup as I could before and a few other things, but I think I like the new layout. What I don’t like is having to create a backup job for every server AND every method. I liked the 2010 and earlier way of doing it, just create a job for every method and add multiple servers to it. I hope this is helpful to all those experiencing upgrade woes!
Backup Exec 2012 Has Issues
To help someone who may be thinking about upgrading to Backup Exec 2012, be careful. Backup Exec 2012, while it does have a very nice user interface and much better view of the backup jobs, it has some major issues that are not yet resolved. We did an upgrade over a week ago and we still can not compete our backups. The issues today are: -- The upgrade got us into a look over the "deduplication" feature and needed to call support for a answer (we have placed the solution on the forum) -- The reports are not working at all. It appears it is using the old reports or is just broken. So no reports on media, or jobs, etc. -- We have run out of backup space and there is NO way to manage the "media". You can see media sets but you are unable to sort or figure out which ones you can delete. (other thanjust reading though theunordered list) NOTE: We can not run a report to view the media which was suggested as a work around. -- There is no way to change the "retention" date of a "media set". So we wanted to reduce the retention period for existing backups so the space on the backup to disk folder will be reclaimed. Well since there is no concept of a "media set" in this version, you can only change the date for future backups. -- It keeps doing "discovery" on computers we have already noted as not needed to be backed up. Discovery runs on its own and adds machines that it finds. Even if we delete the machine, the next time discovery runs we are deleting it again from the list. We need to run discovery but once we make a decision on the machine, it should stop showing up. We are committed to Backup Exec 2012 but are really in a bad way with the product right now. So if you thinking of an upgrade, it might be better to delete you old version and start from scratch. Or wait. Hopefully this will prevent another user from going through this nighmare.
Question : Regards backup exec 10d
Issue is Server was carashed re-built a new server with same hardware and trying to restore the backup from old server to a new server Getting error : Invalid physical volume library media identifier. Customer want to know if this is related to hardware issue or software issue ? I found a KB link : "Invalid Physical Volume Library Media Identifier" (a0008105 HEX or e00008105 HEX) is reported when a restore job fails. Please let me know If the above KB link will be helpfull ?Backup Exec 2012 Small Business Edition (SBE) tial software and documentation...
I am trying to get hold of a trial version of "Backup Exec 2012 Small Business Edition". However, when I follow the "Trial Software" link on the product page, log in and download the .ISO files. IT appears to be the full product and not the SBE. Now, I know there are very specific limitations on what agents are covered by the SBE licensing and that there are very specific installation scenarios that the SBE licensing and product will only support. I also recall, during the beta testing of the SBE product, that there was a SBE specific "simplified" interface. So, I'm kind of lost as to how I can get a trial of the SBE version of BE, when I only have the full product, which has none of these limitations/restrictions/benefits!? I also have another issue in that the Backup Exec Administrators Guide still has no information specific to these significant SBE product limitations or supported installation scenarios. For those of you in Symantec involved in the release of this product... I gave feedback on this issue, during the beta testing, and was told that it would be looked into. But it is apparent that this has not been done or deemed important enough. However, I am glad to see that you guys are at least giving some kind of version reference in your admin guide now. So, I have two questions: 1. Why can we not get a trial version of the real SBE product, with all it's relevant limitations and restrictions in place? 2. Why does the BE admin documentation not at least have a SBE appendix that covers the supported installation scenarios and agent licensing limitations This would at least reduce the need for the above specific SBE trial version of the software; as we would be able to install the full product as if it were the SBE product, following the limitations outlined in the documentation. Looking forward to your responses.
