Results 1 to 3 of 3

Thread: Help me understand how this works

  1. #1

    Default Help me understand how amrecover overhead works

    I am running Amanda 2.6.0 p2 on a fedora core 10 server. I backup to an HP StorageWorks 1/8 Autoloader.

    I have been backing up and restoring file for years now without a problem, but for the first time I have had a major server failure and have a large number of files to restore.

    Luckily I have a copy on a remote server so my initial downtime was very short.

    I am using amrecover from the newly rebuilt failed machine (amanda-client). I set the date, the host, the disk. Navigated to the correct directory and executed and add <dir> command for the directory to restore.

    This directory contains 567,311 files consuming 156GB of space.

    After executing the add command amindexd immediately went to 100% on one of the processors and has remained there on the server. It is apparently scanning for each of the files to be restored.

    The amindex.*.debug file appears to contain one line consisting of between 84k and 124k of data for each file. The amindex.*.debug file is now at 23G and according to my calculations should be about 50% of the way thorough the filelist.

    Each of these lines consist of the following data:

    1256222881.669673: amindexd: < 201- 2009-10-06-01-00-02 0 DailySet103:5,6,7,8,9,10......,22934,22935 5 "/export/boise/Employee Folders/Exchange/Jim Rayner/Laurin MS2007_7_19/generated/graphics/hp_1stage_exh_gh.view/lvl5/resources/line_horizontal_dotted_10px.gif"

    I am assuming that it needs to complete and will reach around 46G before amrecover responds with a prompt so that I can execute the extract command.

    This has been running for 34 hours so far and once again I am assuming that it is about 50% complete that I have to wait another 34 before I can actually start the restore process.

    The server is an Hp Proliant server with Dual Xeon Quad Core processors and 4G of Ram. Amindex is keeping one of the cores at 100% and is using about 5% of my ram.

    My questions are:

    Is this normal?

    Is there anything I can do to speed up the process?
    72 Hours seems like a long time to run before I can even begin to extract files from tape.

    How much overhead space do I need to allow on the server when restoring files to a client machine, according to my estimates so far I will need to allow approximately 46G to restore 156G worth of data?
    And that is assuming nothing more is added to the debug files during the actual restore/extraction process.

    It seems to me that the restore process should be more or less equivilant to the backup process in terms of space and time which does not appear to be the case here.
    Last edited by powertoaster; October 23rd, 2009 at 03:14 PM. Reason: Clarify the issue in the title.

  2. #2

    Default Still don't understand what amrecover is doing.

    I used amfetchdump to get my archives off of the tapes and was able to restore from there, But I still don't understand what the hangup is with amrecover and all the overhead.

  3. #3
    Join Date
    Nov 2005


    amindexd log too many things.
    But all that informations must be sent to amrecover.
    I don't remember if amrecover also log it.

    Increasing the splitsize by 2 will reduce by 2 the information processed by amindexd/amrecover.

    The attached patch reduce the logging by amindexd.
    Attached Files Attached Files

Tags for this Thread

Posting Permissions

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