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)Great news about restoring incremental backups !
Dear all, I have great news about people like me that asked how to restore easily incremental backups... Currently you can't see what's in a folder and if you a 1 full and 35 incremental you have to select 36 times the folder to restore it ! But starting from Backup Exec 2010 it will be possible to browse an incremental backup and see the consolidated view of all previous backups at this date... This is great ! Isn't it ? (I saw it working today)
Bug - Backup Exec 2010 returns "Access denied" if a directory is moved during the backup
It's a bug report. When we're running a backup of a file using RALUS, if the directory which contains the file is moved (for example, renamed), the backup of this file (and of all the other files inside this dir) will fail with the error "Access is denied to directory ...". However, we had permission to access this directory during all the backup time. The log error is wrong. Description (step-by-step) We have a "Selection List" with one resource: \\backup.2aliancas.com.br\[ROOT]/var/exports/backups/mydir/*.* /SUBDIR The directory mydir is a directory (EXT4 backend) in the backup.2aliancas.com.br server (a Linux server with RALUS) with the following structure: /mydir |-> dir1 |-> file1.txt |-> file2.txt For simplicity, consider that these files are big (like 10G each one). So, it will be easier to reproduce the problem. Now, let's start the RALUS deamon in debug mode: $ /opt/VRTSralus/bin/beremote --log-file /tmp/bug.log & $ ps aux | grep beremote root 21725 0.1 0.1 222900 14540 pts/0 Sl 13:27 0:00 /opt/VRTSralus/bin/beremote --log-file /tmp/bug.log $ ls -lh /proc/21725/fd total 0 lrwx------ 1 root root 64 2015-07-01 13:29 0 -> /dev/pts/0 lrwx------ 1 root root 64 2015-07-01 13:29 1 -> /dev/pts/0 lrwx------ 1 root root 64 2015-07-01 13:28 2 -> /dev/pts/0 l-wx------ 1 root root 64 2015-07-01 13:29 3 -> /tmp/bug.log lrwx------ 1 root root 64 2015-07-01 13:29 4 -> socket:[18882216] lrwx------ 1 root root 64 2015-07-01 13:29 5 -> socket:[18882217] Now, let's start a backup (the used settings are attached). After some time, we can see that RALUS is backing up the file file1.txt and also two file descriptors are opened (one for the directory dir1 , and one for the file file1.txt ): $ ls -lh /proc/21725/fd total 0 lrwx------ 1 root root 64 2015-07-01 13:29 0 -> /dev/pts/0 lrwx------ 1 root root 64 2015-07-01 13:29 1 -> /dev/pts/0 lrwx------ 1 root root 64 2015-07-01 13:28 2 -> /dev/pts/0 l-wx------ 1 root root 64 2015-07-01 13:29 3 -> /tmp/bug.log lrwx------ 1 root root 64 2015-07-01 13:29 4 -> socket:[18882216] lrwx------ 1 root root 64 2015-07-01 13:29 5 -> socket:[18882217] lrwx------ 1 root root 64 2015-07-01 13:42 6 -> socket:[18886347] lr-x------ 1 root root 64 2015-07-01 13:42 7 -> /var/exports/backups/mydir/dir1 lrwx------ 1 root root 64 2015-07-01 13:42 8 -> socket:[18886422] lr-x------ 1 root root 64 2015-07-01 13:42 9 -> /var/exports/backups/mydir/dir1/file1.txt Now, let's rename dir1 (same inode and file descriptor, different name) and create a new dir1 directory (a new inode): $ mv /var/exports/backups/mydir/dir1 /var/exports/backups/mydir/dir2 $ mkdir /var/exports/backups/mydir/dir1 Now, let's check the opened file descriptors: $ ls -lh /proc/21725/fd total 0 lrwx------ 1 root root 64 2015-07-01 13:29 0 -> /dev/pts/0 lrwx------ 1 root root 64 2015-07-01 13:29 1 -> /dev/pts/0 lrwx------ 1 root root 64 2015-07-01 13:28 2 -> /dev/pts/0 l-wx------ 1 root root 64 2015-07-01 13:29 3 -> /tmp/bug.log lrwx------ 1 root root 64 2015-07-01 13:29 4 -> socket:[18882216] lrwx------ 1 root root 64 2015-07-01 13:29 5 -> socket:[18882217] lrwx------ 1 root root 64 2015-07-01 13:42 6 -> socket:[18886347] lr-x------ 1 root root 64 2015-07-01 13:42 7 -> /var/exports/backups/mydir/dir2 lrwx------ 1 root root 64 2015-07-01 13:42 8 -> socket:[18886422] lr-x------ 1 root root 64 2015-07-01 13:42 9 -> /var/exports/backups/mydir/dir2/file1.txt PS: This is the expected behavior of Linux at this point. After some time, the backup of file1.txt ends, and RALUS logs some errors. After, RALUS tries to get the next files to backup and logs another error. When the backup ends, Backup Exec logs "Access denied to directory /var/exports/backups/mydir/dir1.", which is a unuseful message. There is not access denied (both the old dir1 (now dir2 ) and the new dir1 are accessible all the time). The RALUS log file is attached at this bug report also. Expected behavior There's no well defined expected behavior for this. However, good solutions could be: Keep copying the others files in the directory dir1 ; It is, at the end of the backup, both files would be backed up at mydir/dir1/file1.txt and mydir/dir1/file2.txt ; This is what cp and rsync would do; This is possible because the file descriptor, the directory stream, the inode number and all the other attributes of the directory are still the same after the rename; After realise that dir1 was renamed, stop copying the other files (only mydir/dir1/file1.txt would be backed up) inside dir1 . A warning "Directory renamed: Skipping directory /var/exports/backups/mydir/dir1" could be logged instead of "Access denied".
