Latest Tweets

Using ia32.sh to run multiple BackupPC instances on the same computer and different backup repository volumes

The problem

We have a computer running Debian GNU/Linux and BackupPC software so as to backup our hosts each night. Of course, all data copied is stored on a RAID-5 per hardware volume, more concretely on a VTRAK system, witch a huge disk capacity. Unluckily, this VTRAK unit is not capable of increasing any previous RAID volume space dynamically. And, most awful of that, we don’t have LVM or another kind of volume management software installed. Thus, there is no option to increase the backup repository space in a dinamic way. It is quite important to remark that BackupPC, in turn, works only using Hard Links to save hard disk space, so it is not feasible to increase the repository space using another mount point placed on another partition or VTRAK RAID volume. Having no more options to add more space to our BackupPC installation, we had to think in some kind of a solution to run two BackupPC servers at the same time, each of them in charge of copying some hosts. Again, and unfortunately, BackupPC does not allow more than just one instance per server running simultaneously. So, as usual, we had to make up something.

The very idea

Thinking hard on it, the first approach came to me. What about running two instances of BackupPC but hiding one from being seen by the another? Apart from using, clearly, a Virtual Machine software, such as vmware or whichever, I decided to use a chroot jail environment. Instead of doing this by hand, I chose, practically with no hesitation at all, my well-known script called ia32.sh, developed two years ago so as to run any 32bit binary inside 64bit architectures.  Of course this script had to be modified so that it could be used in this particular and different case, but it was a tool designed, from a lot of points of view, just to do this, I mean, to run software inside a chroot jail.

Altering ia32.sh behaviour

The entire ia32.sh script was designed so as to run 32bit binaries inside a 64bit architecture, from a user’s point of view. That means adding a lot of graphical software, such plug-ins for Firefox Internet Browser, Acrobat Reader, and this sort of things. Obviously, this behaviour had to be changed completely for our purposes. That’s what I did; just comment some lines of code to skip installing this tools.

There was no problem at all to run a 32bit chroot jail inside a 32bit architecture. But the last thing I had to alter of my original ia32.sh script code concerned the dynamic mount points, or MPOINTS. In this case, and thinking about how to run BackupPC and Apache webserver inside this chroot environtment calling them from outside, all I needed was to control one concrete mount point not using this script. This mount point will be the new backup repository, placed on another VTRAK RAID-5 volume and completely independent of the first one we had.

So, I created a new repository and mounted it on /backup_astro2. Then, I had to “bind” this new data volume not using the script, as did for the rest of mount points located on the system, but using /etc/fstab directly, outisde the chroot jail environtment, as shown below:

# The new backup repository, 1TB, placed on another RAID-5 VTRAK Volume.
/dev/sdd1       /backup_astro2  ext3    defaults,data=writeback 0       3

# Bind this new mountpoint for chroot ia32 environtment:
/backup_astro2  /home/ia32/backup_astro2        none    bind,auto       0       0

And, inside the ia32.sh script, I left out this mount point. This way, my script won’t control this volume at all.

Installing Apache and BackupPC inside the chroot environtment

The next step was a piece of cake. All I need to do was install Apache web-server using a chroot xterminal, thanks to ia32.sh xterm& command, running apt-get. Then, I installed the same BackupPC version copying all its binaries, libs and cgi-bin from our original mount point /extra to the “new” extra mountpoint inside the chroot jail doing a trivial rsync command like this: mkdir /home/ia32/extra && rsync -avtHDL /extra /home/ia32/extra

I altered the httpd.conf file in order to listen in a different TCP port. In this case, I chose the 8080/tcp port. The previous Apache web-server, placed outside the chroot environtment, was using the classic 443/tcp port. To conclude, I made a soft link inside our chroot jail to allow BackupPC to use the “new” repository placed physically on /backup_astro2 running ln command, thanks to ia32.sh xterm& command again, this way: ln -s /backup_astro2 /backup.

Creating an Init script to run them outside the chroot jail environment

Running an xterm using ia32.sh I was able to run Apache and BackupPC with no problems at all. But I was in need of doing this automatically, writing some kind of init script so as to skip running this xterm every time by hand. Most important of all, the new Apache and BackupPC had to be executed with no xterm aid, just as another GNU/Linux process. So, I created a trivial script inside the chroot jail, shown below:

#!/bin/bash
#
#       This script was designed so as to allow ia32.sh to execute, directly via a shell command
#       like: ia32.sh this_script_name, Apache and BackupPC servers inside this chroot environtment.
#
#
# $1 must be start|stop
 
# Now run the BackupPC :
sudo /etc/init.d/backuppc_astro2 $1
 
# Run apache as root - at first - .
case "$1" in
        start)
                ap="startssl"
        ;;
        stop)
                ap="stop"
        ;;
esac
 
sudo /usr/local/apache/bin/apachectl $ap

Apache and BackupPC had to be run as root user at first, so that’s why I use sudo in this script. The “$ap” shell variable needs to be implemented because Apache starts whether using SSL or not. In our case, it is executed using “startssl“.

To conclude, outisde the chroot jail environtment, there’s another shell script, the “init one”, to run the previous one using ia32.sh command, shown below:

#!/bin/bash
#
# Run the script stored at /home/ia32/usr/bin/init-backuppc.sh script
#
su backuppc -c "ia32.sh init-backuppc.sh $1"
exit 0

As a result …

Now, we have two Apache instances and two BackupPC instances running on the very same computer simultaneously, each one capable of copying data without interfering each other. As far as user is concerned, the method to access to the BackupPC web service is practically the same as before, just changing the port number of the URI, in case his/her host had been moved to the new repository data. Because of the fact the /home/ directory is mounted each time the init script is ran, rsyncs trough ssh will work pefectly well – it is necessary to be able of using the ssh keys to authenticate with the clients to backup them -.

Using this technique, it is feasible to add another instance running on another VTRAK RAID-5 volume. Each of them completely independent.

From a system’s point of view, all the processes seem to be running in the same file system and, obviously, at the same time, what it is true as far as the latter is concerned. Take a look at this next screen-capture where it is obvious there are different BackupPC instances running on the same computer simultaneously. In color green, two hosts are being copied using instance one; in color blue another host is being copied running the second instance inside the chroot jail environment. This ps output comes from a simple ps outside the chroot environment, of course:

backuppc  3491  0.0  0.6   7840  6044 ?        S    Sep29   0:15 /bin/perl /extra/bin/BackupPC -d
backuppc  3540  0.0  1.2  12848 11252 ?        S    Sep29   0:52 /bin/perl /extra/bin/BackupPC_trashClean
backuppc 12907  4.9 10.0  93932 91036 ?        R    06:15  22:25 /bin/perl /extra/bin/BackupPC_dump host_A
backuppc 13784  7.0 12.0 110960 108816 ?       S    06:59  28:24 /bin/perl /extra/bin/BackupPC_dump host_A
backuppc 15391  0.5  5.5  53140 50640 ?        S    10:48   0:56 /bin/perl /extra/bin/BackupPC_dump -i host_B
backuppc 15410 17.3  6.6  62644 60464 ?        S    10:49  30:25 /bin/perl /extra/bin/BackupPC_dump -i host_B

backuppc 15949  0.0  0.6   7276  5608 ?        S    11:53   0:00 /bin/perl /extra/bin/BackupPC -d
backuppc 15952  0.0  0.5   6700  5168 ?        S    11:53   0:03 /bin/perl /extra/bin/BackupPC_trashClean

backuppc 16598  0.6  2.7  26688 24744 ?        S    13:18   0:09 /bin/perl /extra/bin/BackupPC_dump -i host_C
backuppc 16607 45.5  5.4  53760 49568 ?        R    13:18  12:10 /bin/perl /extra/bin/BackupPC_dump -i host_C

Taking a close look at one of this BackupPC processes running inside the chroot jail, we can find out that, clearly, all opened files are refered to the chroot mount-point, as shown below:

BackupPC_ 16598 backuppc  cwd    DIR        9,9    4096   1654785 /home/ia32
BackupPC_ 16598 backuppc  rtd    DIR        9,9    4096   1654785 /home/ia32
BackupPC_ 16598 backuppc  txt    REG        9,9 1057324   1671233 /home/ia32/usr/bin/perl
BackupPC_ 16598 backuppc  mem    REG        9,9   64924   1672492 /home/ia32/lib/tls/libresolv-2.3.2.so
BackupPC_ 16598 backuppc  mem    REG        9,9   13976   1672485 /home/ia32/lib/tls/libnss_dns-2.3.2.so
BackupPC_ 16598 backuppc  mem    REG        9,9   34748   1672486 /home/ia32/lib/tls/libnss_files-2.3.2.so
BackupPC_ 16598 backuppc  mem    REG        9,9   33440   1672488 /home/ia32/lib/tls/libnss_nis-2.3.2.so
BackupPC_ 16598 backuppc  mem    REG        9,9   73304   1672483 /home/ia32/lib/tls/libnsl-2.3.2.so
BackupPC_ 16598 backuppc  mem    REG        9,9   28616   1672484 /home/ia32/lib/tls/libnss_compat-2.3.2.so
BackupPC_ 16598 backuppc  mem    REG        9,9   34384   1753851 /home/ia32/usr/lib/perl5/auto/File/RsyncP/FileList/FileList.so
BackupPC_ 16598 backuppc  mem    REG        9,9   31548   1721091 /home/ia32/usr/lib/perl/5.8.4/auto/List/Util/Util.so
BackupPC_ 16598 backuppc  mem    REG        9,9   22988   1753848 /home/ia32/usr/lib/perl5/auto/File/RsyncP/Digest/Digest.so
BackupPC_ 16598 backuppc  mem    REG        9,9   29328   1692056 /home/ia32/usr/lib/perl/5.8.4/auto/Data/Dumper/Dumper.so
BackupPC_ 16598 backuppc  mem    REG        9,9   67468   1674532 /home/ia32/usr/lib/libz.so.1.2.2
BackupPC_ 16598 backuppc  mem    REG        9,9   66308   1753761 /home/ia32/usr/lib/perl5/auto/Compress/Zlib/Zlib.so
BackupPC_ 16598 backuppc  mem    REG        9,9   17920   1692044 /home/ia32/usr/lib/perl/5.8.4/auto/IO/IO.so
BackupPC_ 16598 backuppc  mem    REG        9,9   13868   1721139 /home/ia32/usr/lib/perl/5.8.4/auto/Digest/MD5/MD5.so
BackupPC_ 16598 backuppc  mem    REG        9,9   22284   1692038 /home/ia32/usr/lib/perl/5.8.4/auto/Socket/Socket.so
BackupPC_ 16598 backuppc  mem    REG        9,9    9688   1692058 /home/ia32/usr/lib/perl/5.8.4/auto/Cwd/Cwd.so
BackupPC_ 16598 backuppc  mem    REG        9,9   13664   1692048 /home/ia32/usr/lib/perl/5.8.4/auto/Fcntl/Fcntl.so
BackupPC_ 16598 backuppc  mem    REG        9,9   18876   1672479 /home/ia32/lib/tls/libcrypt-2.3.2.so
BackupPC_ 16598 backuppc  mem    REG        9,9 1254660   1672478 /home/ia32/lib/tls/libc-2.3.2.so
BackupPC_ 16598 backuppc  mem    REG        9,9   78233   1672491 /home/ia32/lib/tls/libpthread-0.60.so
BackupPC_ 16598 backuppc  mem    REG        9,9  134496   1672481 /home/ia32/lib/tls/libm-2.3.2.so
BackupPC_ 16598 backuppc  mem    REG        9,9    9872   1672480 /home/ia32/lib/tls/libdl-2.3.2.so
BackupPC_ 16598 backuppc  mem    REG        9,9   90248   1672351 /home/ia32/lib/ld-2.3.2.so
BackupPC_ 16598 backuppc    0w   CHR        1,3             40538 /home/ia32/dev/null
BackupPC_ 16598 backuppc    1w  FIFO        0,5           1175437 pipe
BackupPC_ 16598 backuppc    2w  FIFO        0,5           1175437 pipe
BackupPC_ 16598 backuppc    3w   REG       8,49    5492 117801861 /home/ia32/backup_astro2/pc/host_C/LOG
BackupPC_ 16598 backuppc    4w   REG       8,49       0 117802016 /home/ia32/backup_astro2/pc/host_C/XferLOG.z
BackupPC_ 16598 backuppc    5w   REG       8,49  249856 117802017 /home/ia32/backup_astro2/pc/host_C/NewFileList
BackupPC_ 16598 backuppc    6u  unix 0xe878f800           1175497 socket
BackupPC_ 16598 backuppc    9u  unix 0xe878fb00           1175467 socket

Below, a screen-shot running the init script so as to start the second instance:

ia32.sh , v.0.1b by Toni Castillo Girona (toni.castillo@fa.upc.edu)
Using /home/ia32 directory
Checking /home/ia32 … [DONE]
Checking linked points … [DONE]
Values getted from the terminal: [init-backuppc.sh start]
Making /home/ia32/usr/local/bin/wrapper32_backuppc.sh .. [DONE]
Updating user’s database … [DONE]
Running chroot now … Starting backuppc: ok.
/usr/local/apache/bin/apachectl startssl: httpd started
[COMPLETED!!]
Unlinking mountpoints … (Dynamic points: )
Synced dpoint(s) detected … :
[DONE]
See you soon, check /var/log/chroot_error_log for details! 😉

References and more information about ia32.sh

I wrote an article which was published on Todo Linux magazine, concerning the entrails of  ia32.sh shell script. You can read it HERE.

Finally, there’s a web page where you can find the original ia32.sh shell script. The code changes made on it are not available for security reasons.