What follows is unix centric, and won't tell you much if you're not a programmer/unix user, but you should enjoy it otherwise (please note that I do own a legal copy of bru backup for personal use, which I got with an old boxed set of Red Hat)


I'm trying to get my backup tape library to work as I've never been able to backup the 1TB+ of media files (don't ask) I have (I've been copying them on my other drives, but now I have too many for that to fit)

So, I decided to move my tape library to another machine, just for testing (to see if the library was bad, or my SCSI connection or host PC was flaky)
But, problem, it wouldn't back up a single file over NFS.

After a while, I realized:
gargamel:~# bru --version
bru: invalid option -- -
usage: bru -cdeghitx [-#AabBCEfFGjlLmnNoOpPQRSsuUvVwXYZ] file(s)...

Copyright (c) 1994-97, Enhanced Software Technologies, Inc.
All Rights Reserved

BRU is a backup software product licensed by EST.
It is NOT public domain or shareware. Versions are
available for almost any type of Unix system.

This is the Personal Edition version of BRU 2000. It does not offer
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
support for backup or restore of remote/network filesystems.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
To order a copy of the full version of BRU 2000 or for further
information or technical support, please contact Red Hat Software

Ah, great.
There had to be a way to trick it to backup over NFS anyway (this software is more than 7 years old, I'm probably not able to buy a license today, and I'm not violating the spirit of the license, I'm just doing a backup of one system, but without being able to have the library connected to it)

So, I did a couple of straces, one of a local file and one of an NFS file and diffed them.
What did I see?

open("/bru/.serial_number", O_RDONLY) = -1 ENOENT (No such file or directory)
uname({sys="Linux", node="host.svh.domain.tld", ...}) = 0
-lstat64(0x806e5a4, 0xbffff298) = 0
-lstat64(0x8070978, 0xbffff280) = 0
-statfs("dshelf3_X10:D3_MD5_.bz2", {f_type="NFS_SUPER_MAGIC", f_bsize=8192,
f_blocks=14836773, f_bfree=1564919, f_files=15073280, f_ffree=14353562,
f_namelen=255}) = 0
^^^^^^^^^^^^^^^^^^^^^^^
-lstat64(0x8070978, 0xbfffee1c) = 0
-access("dshelf3_X10:D3_MD5_.bz2", R_OK) = 0
+lstat64(0x806e5a4, 0xbffff2a8) = 0
+lstat64(0x8070978, 0xbffff290) = 0
+lstat64(0x8070978, 0xbfffee2c) = 0
+access("profile", R_OK) = 0
+lstat64(0x8070978, 0xbfffe6f0) = 0
+access("profile", R_OK) = 0
+open("profile", O_RDONLY|O_NONBLOCK) = 4
+write(1, "c 4k of 6k [1] profile\n", 27) = 27


Aaahahh. man statfs said that NFS_SUPER_MAGIC was 0x6969, which is "ii" in ascii.
So, I just opened the bru binary with vi, found one instance of "ii" (I was lucky) and it was around the text strings, so it was definitely in the variable sections of the binary.
I changed the string to "ij", and voila, nfs backups.

Yeepee! :)

The joys of a simple geek may be hard to convey sometimes :)

Current Music: none while my disk array is being rebooted every 5mn :)
Current Mood: Hardware, you will submit :)

So, I can't believe that after two years of having that tape autoloader I finally got the thing to work. It took more sweat and tears than I care to write about, but basically, in the end, one of the two busses on one of the 4 SCSI cards in that machine was flaky (some of the cables were too though).
I can't believe that I ended up fixing the problem by putting no less than 6 SCSI busses in that machine (I had to add yet another card). That just feels wrong...
Anyway, it works now and it's happily backing up data. With a little luck, the backup will be over in a week's time.

Cool, now I only need to fix my Replay TV with its broken hard drive and my older archos jukebox player so that I can ebay it. So much to do, so little time :)
I sometimes wonder how "normal" people manage :) (but seriously, it must suck to have to throw those things away, or pay god knows how much to get them fixed by someone else)