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 (firstname.lastname@example.org)
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
Unlinking mountpoints … (Dynamic points: )
Synced dpoint(s) detected … :
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.