Chris Cruft

Bought my SmartArray Controller: a 5302-64 model.  I paid about $60 (including shipping) for it.  Compaq Part Number is 171383-001.

Pasted from <http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=5792385278&rd=1&sspagename=STRK%3AMEWN%3AIT&rd=1>

Tested the tape drive in suzuki this weekend with Amanda. It seems to be alive and working!

It did not even come close to finishing by the end of the day.  Instead, it finished Saturday morning.  As a result of the output, I added the following section to the

/etc/amanda/DailySet1/amanda.conf file:

# cch1@hapgoods.com

# 30 July 2005

# amanda 2.4.4p3 on Compaq ProLiant 3000 333MHz

define tapetype CompaqDLT7000 {

comment “Compaq DLT 7000 35/70″

length 29994 mbytes

filemark 19 kbytes

speed 1688 kps

}

I was pretty surprised by these numbers.  Specifically, I expected the capacity to be nearly double that which was reported by amtapetype.  And what the hell is a kps?  I think I will try to run the program again, but with a couple of changes.  First, I will disable compression.  This is the recommended approach per the amanda documentation (http://amanda.sourceforge.net/docs/topten.html#id2557140).

[root@suzuki ~]# mt -f /dev/nst0 compression 0

Secondly, to speed things up a bit, I will help amanda to guess the tape size correctly.  So off I go, running amanda as follows:

[root@suzuki ~]# amtapetype -e 35g -f /dev/nst0

several hours later…

[root@suzuki ~]# amtapetype -e 35g -f /dev/nst0

Writing 128 Mbyte   compresseable data:  28 sec

Writing 128 Mbyte uncompresseable data:  29 sec

Estimated time to write 2 * 35840 Mbyte: 16240 sec = 4 h 30 min

wrote 1077992 32Kb blocks in 94 files in 7197 seconds (short write)

wrote 1077992 32Kb blocks in 188 files in 7412 seconds (short write)

define tapetype unknown-tapetype {

comment “just produced by tapetype prog (hardware compression off)”

length 33687 mbytes

filemark 0 kbytes

speed 4723 kps

}

[root@suzuki ~]#

These numbers seem more reasonable.  Capacity is close to 35 GB, the difference being undoubtedly marketing GBs (1×10^9 bytes) versus normal people GBs (1024×1024x1024 bytes) and unformatted versus formatted capacity.  The speed is also more in line with my expectations (amanda documentation shows that kps is the same as kbps -manual calculation from the output of amtapetype supports this).  Conservatively assuming a 1.5:1 compression ratio, my new tapetype entry into amanda.conf will therefore be:

# cch1@hapgoods.com

# 30 July 2005

# amanda 2.4.4p3 on Compaq ProLiant 3000 333MHz

define tapetype CompaqDLT7000 {

comment “Compaq DLT 7000 35/70 with Compression Enabled & Type IV Tape”

length 50 gbytes

filemark 0 bytes

speed 7 mbps

}

2. The next step requires updating some parameters in the amanda.conf file.  One of the parameters involves the email address of the backup administrator.  Big problem -I haven’t configured anything in the way of email on any of the Fedora boxes.  Time out!

After configuring and enabling sendmail, I have made the following changes to amanda.conf:

1. org “Backup DailySet1″

# Backup name for reports

2. mailto “amanda”

# users/operators to receive backup status notification

3. dumpcycle 2 weeks

# the number of days in the normal dump cycle

4. runspercycle 10 days

# the number of amdump runs in dumpcycle days

5. tapecycle 2 tapes

# the number of tapes in rotation

# 4 weeks (dumpcycle) times 5 tapes per week (just

# the weekdays) plus a few to handle errors that

# need amflush and so we do not overwrite the full

# backups performed at the beginning of the previous

# cycle

6. tapedev “/dev/nst0″

# the no-rewind tape device to be used

I am not very pleased with the dumpcycle/runspercycle/tapecycle parameters.  Only having two tapes available is a severe limitation that Matt must fix.  But I also don’t really understand the relationship of these three parameters.  I am very familiar with the traditional Grandfather/Father/Son tape rotation pattern, and the Tower of Hanoi rotation pattern.  But amanda’s pattern is beyond me.  I am going to plow ahead for now and adjust the parameters later.

3. I now need to label a tape.  I’m a CS-thinking guy, so I will use zero-based numbering (at least for the tape numbers, if not the Backup set name!).  So according to the guide I have been following, the command I need to execute is:

su amanda -c “/usr/sbin/amlabel DailySet1 DailySet100″

Unfortunately, it barfs:

[root@suzuki DailySet1]# su amanda -c “/usr/sbin/amlabel DailySet1 DailySet100″

amlabel: could not load tapelist “/etc/amanda/DailySet1/tapelist”

[root@suzuki DailySet1]#

Somewhere I recall reading that the trick is to create an empty tapelist file:

[root@suzuki DailySet1]# touch tapelist

[root@suzuki DailySet1]# chown amanda:disk tapelist

[root@suzuki DailySet1]# ll

total 36

-rw-r–r–  1 amanda disk 17889 Aug  2 12:16 amanda.conf

-rw-r–r–  1 amanda disk  2099 Jun 28  2004 disklist

-rw-r–r–  1 amanda disk

0 Aug  2 12:17 tapelist

[root@suzuki DailySet1]#

This seems to solve the problem:

[root@suzuki DailySet1]# su amanda -c “/usr/sbin/amlabel DailySet1 DailySet100″

rewinding, reading label, not an amanda tape

rewinding, writing label DailySet100, checking label, done.

[root@suzuki DailySet1]#

Next, I adjust the amanda, amandaidx, and amidxtape files in /etc/xinetd.d/:

Screen clipping taken: 02/08/2005, 12:22

And then restart xinetd with service xinetd restart and confirm xinetd is listening for amanda connections with netstat -ul | grep amanda.

I next configure the disklist file to have only one simple entry for now:

localhost /etc root-tar

Note that I do not use the dumptype comp-root-tar because my tape drive should be doing the compression already.  Finally, I run amcheck to confirm that the backup will be able to run.  There are problems:

Screen clipping taken: 02/08/2005, 14:25

Further investigation reveals that the amanda server (suzuki.hapgoods.com) needs to attach to the amanda client (also suzuki.hapgoods.com) by something similar to rexec and the necessary permissions file is missing.  For rexec, this file is ~/.rusers, but for amanda the file is ~/.amandahosts where the home directory (~) is relevant to the amanda user (amanda).  I found that the file existed, but did not have the FQDN entry for suzuki.  After adding it, I got a new error:

Screen clipping taken: 02/08/2005, 14:40

It turns out that the problem is related to the exclude directive in the dumptype entry for root-tar and comp-root-tar.  For now, I don’t want any excludes so I have commented out this line in both entries:

# exclude list “/usr/local/lib/amanda/exclude.gtar”

Finally, amcheck succeeds.  Of course, I am ignoring the warning about tapecycle <= runspercycle.

Screen clipping taken: 02/08/2005, 14:59

With the success of amcheck, I move on to amdump and, not surprisingly, it works well.  I get an email on the root account (user amanda’s mail goes to root somehow…).

4. Simple enough, I add the necessary crontab entries to ensure amanda is run daily:

[root@suzuki amanda]# crontab -u amanda -l

# backup daily

5 2 * * 1,2,3,4,5 /usr/sbin/amdump DailySet1

0 16 * * 1,2,3,4,5 /usr/sbin/amcheck -m DailySet1

[root@suzuki amanda]#

5. At this point, I have followed the steps in the Fedora News procedure.  However, I don’t intend to add a lot more filesystems for backup yet.  For starters, I need to test the restore process.  I also need to finalize the configuration of suzuki.

One change I decided to make immediately was to eliminate the “relative” host names (e.g. localhost) from the disklist file.  Now all references will use Fully Qualified Domain Names (FQDN).  This immediately invalidates the history files of amanda (which I see when I run the amcheck program).  I may be able to rename some directories and resolve this problem -but that is a problem for another day.

6. Restores in amanda are started from a command line tool called amrecover.  Unfortunately, it dies with an authorization error that is similar to one I received with the amcheck command prior to getting the backups working.  The problem is that amrecover always runs as root and the ~amanda/.amandahosts file (currently) only authorizes the amanda user.  Adding root to the file seems simple enough, but it turns out to be a little tricky.  Simply adding root after amanda on each line (e.g. suzuki.hapgoods.com amanda root) silently fails.  In fact, the file is made up of lines each of which is a host-user pair.  So I need to add a new line for root.  Then amrecover starts nicely.

I also ran the amverify command to do a simple test of the readability of the tapes.  It looked good:

7. The services listed in /etc/xinetd.d/amidxtape and /etc/xinetd.d/amandaidx are disabled.  To support amanda indexing, they need to be enabled.  The usual tradeoff with such a remote service is probably security, but I decided to take a chance and I have enabled both.  These services are detailed in Indexing with AMANDA (Chapter 4) of the current amanda manual (http://www.amanda.org/docs/indexing.html).  I can see that they are enabled with the following:

# netstat -tl | grep am

Using some of the more recent documentation, I have determined that the exclude capability of amanda is entirely inherited from the dumping program where applicable, and more specifically from gnu tar.  Accordingly, I have added the following entry to the global dumptype:

exclude file “core”

This can’t be considered highly tuned, but it will get me some practice.

Here is the source for amanda, support, manuals, etc.:

http://amanda.sourceforge.net/

And here is the “official” user forum:

http://www.mail-archive.com/amanda-users%40amanda.org/

And here is a nice narrative for setting up amanda:

http://www.storagemountain.com/amanda.html

But for this practical implementation, I am following this procedure outlined on Fedora News:

http://fedoranews.org/ghenry/amanda/

1. The first step is to document the tape drive to amanda.  For this test, I have inserted one of the (expensive) brand new Type IV tapes that Matt purchased:

[root@suzuki ~]# amtapetype -f /dev/nst0

Writing 512 Mbyte   compresseable data:  52 sec

Estimate phase 2…

This stage started at about 15:09 on Friday.  Let’s see if it finishes before I have to go home…

Some more sites that document the installation of Linux on ProLiants:

http://www.van-dijk.net/

http://gentoo-wiki.com/HARDWARE_Compaq_Proliant_6500

http://h18000.www1.hp.com/products/servers/linux/compaq-howto-v8-1.html

http://h18000.www1.hp.com/products/servers/linux/documentation.html#howtos

General ProLiant Information

General Specs for PIII models (6/500, 6/550, 6/600)

http://h18002.www1.hp.com/products/quickspecs/10041_div/10041_div.html#Options

It seems that there are two classes of ProLiant 3000s, based on the System ROM Family:

E39

Pentium Pro and Pentium II 333MHz models

P09

Pentium III 400MHz, 450MHz, 500MHz, 550MHz, 600MHz

Won on eBay five 36.4GB drives (Compaq PN 177986-001 or 176496-B22) at $288 including shipping. These are the hot-pluggable 10K RPM Wide-Ultra3 SCSI drives that will work in my new PL3000’s LVD cage. Gotta test them next.

Pasted from <http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=5213769610&rd=1&sspagename=STRK%3AMEWN%3AIT&rd=1>