On Mon, Sep 11, 2006 at 04:27:08PM +0200, Dominik Schips wrote:
> Hello,
> 
> I am new to AMANDA but I like it very much but I didn't get a good answer 
> from 
> all the documentation I read already and hope to get answers from the mailing 
> list now.
> 
> I use a Overland PowerLoader with a Ultrium LTO (400GB tape) device which 
> change the tapes automatically.
> 
> The clients push all the backup data via rsync (or other tools) to the server 
> and I had to do a full backup every day of this directories the files are 
> stored in. No incremental backup is allowed.
> Don't ask. I know this isn't the best to backup with AMANDA but I
> had to do it in this way.

Nothing wrong with full dumps only.  And there are lots of situations
whereby the original system is not backed up, but only files created
by someother mechanism.

> For the dumpes I use a holding disk before the dumpes are written to tape.
> 
> The problem I have is that the last dump is to big (145GB) and doesn't fit on 
> the first tape. So it is no problem. The PowerLoader take the next tape and 
> everything is fine.
> 
> But the entire backup take about 12-14 hours for all data (see statistics at 
> the bottom). That is a little bit too much and I like to speed up the 
> configuration.
> 
> I have 2 questions:
> 
> 1. How can I tell AMANDA to start with the big directories first and then the 
> small directories?
> As I have seen AMANDA allways starts with the smallest and then the next 
> biggest and so on.

Probably you are using the default "dumporder".  This specifies the first
five dumpers should dump the DLE with the shortest expected time.  The
next five with the longest expected time.

You can reset dumporder in amanda.conf for time or size ordering.

Be aware that if you have multiple dumps in progress, the small ones
may still finish well before the earlier started large ones.


> 2. I use a holding disk for the configuration. But AMANDA always do only one 
> dump at the same time.
> How can I tell AMANDA to dump more directories at the same time to the 
> holding 
> disk so that the LTO device can backup the data faster and don't have to wait 
> for the dumps of the holding disk?
> 
> It is a problem when the dumps are bigger then about 20GB because the LTO 
> drive had to wait for the next dump until it is written to the holding disk.
> The result is the very high run time of AMANDA I think.
> 
> Are the "maxdumps" and "inparallel" options at the amanda.conf the way to get 
> several dumpes written at once to the holding disk?

They set upper bounds.  Default for maxdumps is one, so unless changed,
only one dump/host at a time is allowed.  This limits the total impact
on the client being backed up.  Default for inparallel is ten, so that
is probably not a problem for you.


> Remember the files to back up are on the server already.
> 

Are the files to be backed up on the same physical disk?
Are those directories on the same disk as the holding disk?
Typically you do not want multiple backups running at the
same time on the same disk.  And it is best to not use holding
space on the same disk as a DLE.  Both scenarios will work,
but can impact performance.

If the holding disk is on the same drive as your data, you might
try a run or two with "holdingdisk no" set in your dumptype.
That would do send the backups directly to the tape.  Maybe
without the thrashing of reading and writing to the same drive
things would improve.

If your directories being backed up are on multiple drives
and you are going to increase maxdumps, make sure you set the
"spindle" parameter appropriately for each of your DLE's.
That will prevent two simultaneous backups on the same drive.


> I dont' have access to the config files today but let me know if you need 
> them 
> to answer my questions.
> For your information the LTO device use hardware compression. Is it better to 
> disable hardware compression to speed up the run time?

Your summary below says that taping time was < 4 hours.  That doesn't
seem to be a bottleneck.  But make certain you don't also do software
compression.  I know LTO deals with it cleanly, but I'm talking about
performance.  If using HW compression, no reason to waste cpu cycles
when performance is an issue.

> 
> Here are some statistics:
> 
> STATISTICS:
>                           Total       Full      Daily
>                         --------   --------   --------
> Estimate Time (hrs:min)    0:40
> Run Time (hrs:min)        13:08
> Dump Time (hrs:min)        8:27       8:27       0:00
> Output Size (meg)      374733.9   374733.9        0.0
> Original Size (meg)    374733.9   374733.9        0.0
> Avg Compressed Size (%)     --         --         -- 
> Filesystems Dumped           12         12          0
> Avg Dump Rate (k/s)     12613.8    12613.8        -- 
> 
> Tape Time (hrs:min)        3:35       3:35       0:00
> Tape Size (meg)        374733.9   374733.9        0.0
> Tape Used (%)             194.1      194.1        0.0
> Filesystems Taped            12         12          0
> Avg Tp Write Rate (k/s) 29707.6    29707.6        -- 
> 
> USAGE BY TAPE:
>   Label                    Time      Size      %    Nb
>   Daily027       1:59  224033.5  116.1    11
>   Daily028       1:36  150700.4   78.1     1
> 
> 
> Best regards
> 
> Dominik
> 
> 
>>> End of included message <<<

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)