Don’t get me wrong, I am happy Symantec finally released a Mac OS X 10.6 Agent for Symantec Backup Exec 2010 but it is a little buggy. So much so, that we feel we really need to just have it restart daily on the OS X servers. Here is what we did. This is just a simple cron job.
1. Login via Terminal or SSH to the OS X server
2. su to the root user (or sudo everything if you want)
3. enter ‘crontab -e’
4. insert (i) the cron information because there will probably not be any existing cron information in there
Then press the ‘esc’ and ZZ to save the crontab out. The above crontab entry will restart VRTSralus.init every day at 12:15. You can set it for any time you wish that makes sense or whatever.
5. You can check to see if it is actually working by going into the /var/VRTSralus directory and looking at the modification dates of the error logs and pid file.
6. Doing an ‘ls’ you can see the modification date/time of the pid and log files. They both get new modification dates whenever the service is started.
So, having the server restart it every day or so seems to make it run a little more reliably. There might just be something in the code that is buggy and perhaps they can fix it next release.
Symantec’s Backup Exec 2010 R2 just came out and it was a huge deal for us because we have an Xserve we have had to have on a different backup cycle because Symantec did not support it. So, when R2 was released with 10.6 support, we were eager to get it going. Only problem is, the Agent didn’t install.
After Anthony (works for me at Lick-Wilmerding) banged around on it for a while with Symantec Tech Support, there was still no resolution. We tested on my MacBook and it did install. It had to do with the kernel and 32 bit vs 64 bit. Symantec’s installrams install script checks for x86 and if it doesn’t find it, it kicks up a big ‘Not Supported’
So, one way we got around it was to boot the machine in 32-bit mode for the install. Get into a Terminal and then
and reboot. The beremote process will run and you will see it as a backup option in your BE Job Creation screens.
DISCLAIMER: Messing around with system internals can cause all kind of bad stuff, so if you are not comfortable with it, there is probably a reason so don’t do it. Switching stuff like this can really do some crazy damage, so you are on your own and we just wanted to put it out there for those who are capable and willing to take the responsibility.
Kerio changed some things in the latest major version beyond the branding of Mailserver to Connect. The way one could modify/personalize the login screen for users also changed. It used to be that you could just edit the .css file in a directory and insert a logo, etc. and it is similiar to the way it was done in pre-7, pre-Kerio Connect, but the files are different.
I am running Kerio Connect on OS X currently, but Linux installs should be the same path.
First files you want to backup and then mess with is located here:
These are the main css files for that login page. You will be able to change colors and backgrounds, etc. here. I always copy the default one off to the side as well as the customized one to have around after updates reset them back to defaults.
This file controls the page title, and design content of the page. Always good to change some stuff so it isn’t so generic.
Good luck and it takes some time to play with it to get it the way you want, but backup and always keep something off to the side for quickly being able to swap it back in after Kerio updates are played. I always create a directory in the vicinity that houses optimized logos, etc. and backup files just in case the get hosed during testing.
We took the bubble images and turned them black since we didn’t want to mess too much with the design knowing that Kerio will stick to this for a while. I also did sym-links (ln -s) to the file names so those symlinks will get hit with the same filenames on upgrades but not the actual image files.
Drives: Installing easy, one drive lower than fans, notice it runs a littel hotter too. To install the lowest of the 4 trays, you need to remove the back fans, but no biggie. The sleds are nice and simple. The kit comes with little baggies of screws so that is great. Also, the drive sleds slide right in and the SATA connector is aligned perfectly so you can just nudge the drives into place without any stress on the drive or sled. I went with some Western Digital 2TB Green drives. I have never had great luck with WD, but the power consumption on these newer drives seemed like a good call and the price point was great.
Operation: It is just amazingly quiet! Geez, you put in 4 2TB drives and you expect the thing to be noisy, but it is super quiet. This is a huge benefit for me as I hate the electronics sounds around the house, so this is great even though it will be the garage. I have a Nextstar simple RAID-1 with a couple of SATA drives and it is super loud in comparison.
Building the RAID: RAID-5 took forever due to size of the logical volume. I could have gone with the fast/rapid option, but anyone who has ever been burned by a bad RAID setup because they did the quick format only to have to do a full low-level format later knows why I went this route right off the bat.
Little Things: There are many things to appreciate throughout their setup process I wanted to note. After setting up a ton of different network devices, we all know changing network address is a pain because the device can get confused during the process and if the configuration is web-based, it can get messy when you lose contact with the old address. I was waiting for that to happen when I went from DHCP to fixed IP through the web GUI, but to my surprise it redirected to the new IP address (nice!). I am so used to HP, Cisco, Linksys and other that don’t care to take this into account and force the admin to enter the new URL / IP address but when it is done right, it is so nice to see. Nice GUI touches throughout. They use AJAXy stuff, but not overdoing it. Linux support in documentation. Date and time already correct due to network time.
Initial Setup: The box came with CD with a Mac, Windows or Linux installer. I am really happy that Synology has Linux ‘baked-in’ to everything they do with their products and I really want to support that. My DS410 came with DS v 2.2, so had to upgrade to latest 2.3. I downloaded the updated firmware (v2.3) and in the expansion process, Archive utility expanded a little too much so it didn’t keep the .pat file in-place for the GUI to recognize that the update was a legit firmware update. But, in going to their support site and FAQ, they had an article for that and I had change archive utility to not expand more.
Support Site: As mentioned above, their support website rocked. The FAQ area was great and exactly what I needed. They have this down.
Testing: after initial setup, I went to move the DS410 and the power cable was loose causing the DS410 to lose power. Plugged it back in and all was well! Copied some files across the network and the drives and throughput felt great. I also turned-on the various applications and have been testing with a great success on the internal network, from work and from remote on my iPhone using the Synology iPhone Apps. Being able to consolidate music and stream anywhere will be awesome the more I consolidate it on the Diskstation.
Always had a heck of a time with BackupExec 12.5 and below backing up CentOS versions. I think early versions of RALUS were operational and worked back in the BackupExec 8-10.5 days prior to Symantec’s acquistion of Veritas. But, it has never been really easy to get this going well and incorporating a RedHat-like but not RedHat system into the BackupExec remote client world. Bring in 64-bit CentOS, and it got even more of a pain.
Well, now it seems it is possible and repeatable with Symantec BackupExec 2010. The change in naming conventions off the versions to years (even though everyone else is going back to the versions and moving off of years now!) signifies some code investment from Symantec in what must be a cash-cow for them in BackupExec.
We have a few Windows 2003 and 2008 servers along with some OS X 10.5.x servers and are backing them up to a LTO3 library on a 2008 server and made the move to BackupExec 2010 recently to try and shake some of the lingering issues with 12.5 rehashed code and makeshift RALUS client patches for Unix, Linux and Mac clients Symantec seems to have inherited and continued.
It seems you need to disable IPv6 to get the negotiation to happen correctly on top of the obvious IPTables and IPTables configurations to allow TCP ports 10000 and 6101 to communication between the BackupExec Server and your RALUS client.
Disabling IPv6 on CentOS (run all as root or you can sudo everything below)
– in /etc/sysconfig/network you need to add
– in /etc/modprobe.conf add:
alias ipv6 off
alias net-pf-10 off
– make sure IPTablesv6 is disabled at startup
/sbin/chkconfig ip6tables off
After all of that, give your network a restart
Then run the RALUS install from the Symantec BE 2010 download. If you have issues here during the install and possibly have multiple network interfaces straddling different networks, try ip addresses in lieu of hostnames. Also, on the BE 2010 server, restart all the services. Starting the RALUS client on CentOS 5 is