Page 1 of 3 123 LastLast
Results 1 to 10 of 24

Thread: 2.5.0b1 test reports

  1. #1

    Default 2.5.0b1 test reports


    If you have used 2.5.0 (successfully or otherwise), please post a test report here. If you find a bug, note that too.

    Useful information in test reports:
    • Test date
    • Platform and version of server and clients
    • Number and size of volumes backed up.
    • Dump tools used (tar, dump, samba, etc) and version
    • Type of backup media: LTO/DLT/AIT/Disk
    • Tapetype used
    • Strategies/levels tested
    • Authentication method used
    • What amanda commands used during testing?
    • If you find any problems, please document them.
    Last edited by ian; November 23rd, 2005 at 10:48 AM.

  2. #2

    Arrow I'll start.

    Tested successfully on a Fedora Core 3 laptop, backing up only itself to disk with the on-disk vtape API. Tape-spanning was used without issue, and data was sucessfully restored. This test used tar dump format and BSD authentication.

    I ran multiple runs of amdump, but since there is only one disk, Amanda likes to do a full dump every time.

  3. #3
    Join Date
    Nov 2005

    Default amanda 2.5.0 testing

    I have done many test before 2.5.0b1 was released:

    - interoperability between 2.4.5 and 2.5.0
    - 2.4.5 as server or client
    - 2.5.0 as server or client
    - only with gnutar
    - with and without indexing
    - with server, client or no compression

    The other were done with 2.5.0 as server and client.

    - I killed some program to see how amanda recover and retry the backup.
    - gnutar
    - index gtar
    - sendbakcup
    - client gzip
    - server gzip
    - dumper
    - chunker

    - I tested one dump direct to tape.

    - I tested ssh and rsh auth method.


  4. #4

    Default 2.5.0b1 testing

    just tried building on Solaris9/10 and AIX 5.2. when configured from another directory e.g. ../../amanda-2.5.0b1/configure ... i get at compile-time:

    In file included from ../../../amanda-2.5.0b1/tape-src/output-file.c:38:
    ../../../amanda-2.5.0b1/common-src/amanda.h:241:26: amanda-int.h: No such file or directory
    make[1]: *** [output-file.lo] Error 1
    make[1]: Leaving directory `/home/amanda/src/amanda-2.5.0b1-builds/Solaris10/tape-src'

    get this result when using --with-src=<absolute path> also, using gcc 3.4.2, GNU make, ...

  5. #5
    Join Date
    Oct 2005

    Default configure output

    Can you please provide the output of configure run?

    I'm interested in the line

    "checking whether posix fcntl locking works..."


  6. #6

    Default configure output Solaris9

    checking whether posix fcntl locking works... yes

    # uname -a
    SunOS tron 5.9 Generic_118558-14 sun4u sparc SUNW,Ultra-60

  7. #7

    Default compiling on AIX 5.2

    tried building in src-tree, using VisualAge C 6 gives:

    cc -DHAVE_CONFIG_H -I. -I. -I../config -I../common-src -I../common-src -I../restore-src -I../tape-src -q32 -D_LARGE_FILES -qlonglong -q32 -D_LARGE_FILES -qlonglong -g -c -M driverio.c -DPIC -o .libs/driverio.o
    "logfile.h", line 74.1: 1506-046 (S) Syntax error.
    make[1]: *** [driverio.lo] Error 1
    make[1]: Leaving directory `/space/src/amanda-2.5.0b1/server-src'

    using gcc 3.4.2, compiler options for native cc are used (used CC=gcc when configure'd, gcc in PATH):

    gcc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -q32 -D_LARGE_FILES -qlonglong -q32 -D_LARGE_FILES -qlonglong -g -O2 -MT alloc.lo -MD -MP -MF .deps/alloc.Tpo -c alloc.c -DPIC -o .libs/alloc.o
    gcc: unrecognized option `-q32'
    gcc: unrecognized option `-qlonglong'
    gcc: unrecognized option `-q32'
    gcc: unrecognized option `-qlonglong'
    In file included from alloc.c:33:
    amanda.h:816: error: conflicting types for 'bind'
    /usr/include/sys/socket.h:434: error: previous declaration of 'bind' was here

    (somewhen later make bails out)

  8. #8

    Default Another successful test report.

    Over the course of the last week, I gave 2.5.0b1 another test. The server was Redhat FC4, with three clients: itself, a RHEL4 machine, and a FC3 laptop. Used BSD authentication.

    Backed up a total of 10 DLEs, totalling 15.5 GB. Did full and level 1 dumps, with a successful multi-level restore.
    Used tar on all hosts, versions ranged from 1.14 to 1.15.1.

    Drive is a Quantum DLT7000 with standard tapetype.

    In this test, I managed to get a stack trace/core dump for a niggly intermittent crash in chg-scsi. Details in separate bug report.

  9. #9
    Join Date
    Oct 2005
    Bay Area, CA

    Default client-side, server-side encryption dumptype option added

    I have added a dumptype "encrypt" option. Code has been commited to the sourceforge,
    rpm will be available next week on [url][/url].
    I have updated the encryption section on :

    I have tested it on different configuration,
    a) client-compress, server-encrypted.
    b) client-compress, client-encrypted
    c) server-compress, server-encrypted

    Please use it and send us your feedback. Thanks!

    Kevin Till
    Amanda Developer

  10. #10
    Join Date
    Nov 2005


    I am running 2.5.0b1 successfully since Nov, 26th.
    The AMANDA-server is a Suse 10.0 OSS system, with itself and 3 other Suse-systems as clients. There are two main configs dumped, one dumps ~40GB per run to a HP-DLT1 drive, the other dumps ~20GB to a HP-DDS3 drive.

    The DLT still has hw-compression enabled (haven't yet found out how to disable that, mt doesn't work) so I am not using any sw-compression with this. I use GNUtar 1.15.1 for all the DLEs, incrementals are doing fine and restoring also.

    I am now going to have a closer look at the new encrypt-option ...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts