Amanda-Users

Re: features: append, span tapes, compress?

2003-01-23 03:33:00
Subject: Re: features: append, span tapes, compress?
From: Frank Smith <fsmith AT hoovers DOT com>
To: Scott Mcdermott <smcdermott AT questra DOT com>, amanda-users AT amanda DOT org
Date: Thu, 23 Jan 2003 01:50:38 -0600
--On Thursday, January 23, 2003 01:53:07 -0500 Scott Mcdermott <smcdermott AT 
questra DOT com> wrote:

> After searching around in the FAQ-O-MATIC, current projects page, and in
> the mailing list archives, I believe what I understand is that:
> 
>    - the largest filesystem backed up must be smaller than the size of
>      the tapes used (possibly after compression is considered)

Using dump, true, but using tar you can backup subdirectories of the
filesystem and so split your large disk into smaller pieces. Also see
RAIT comments below.

>    - amanda can't do hardware compression without breaking easily

Not true.  Software compression gives you better tape utilization (as
Amanda then knows exactly the size of the backups and whether it will
fit on the current tape, but many people on the list do use hardware
compression successfully.
 
>    - amanda doesn't do parallel backups under any circumstances

Amanda does parallel backups, but only one is streamed to tape
at any one time.  However, with the current version you can do
RAIT and stripe your data across several tape drives.  This gives
you higher throughput and a way to backup an entity larger than
a single tape (but still smaller than your RAIT set).

> do I understand these points correctly? I have several issues this will
> create for me and no idea how to solve them:
> 
>    - I have some filesystems that are LARGE and have no hope of fitting
>      on a single tape, and no hope of fitting in a staging/holding area
>      on a disk.  These are large logical volumes that span across
>      multiple RAID arrays.  Amanda simply can't handle these because it
>      can't span tapes, correct?
 
See above.

>    - I have a nice fast compression ASIC in my tape drives which can
>      probably compress at the drive's write speed, while my backup host
>      is slow and intended mainly for IO.  Do I have it right that Amanda
>      can't just write until EOT (allowing the drive to compress), rewind
>      to last EOF, and move on to the next tape? Instead I have to use
>      CPU in my backup server to do compression?

Yes, you can use your tape's compression, but when Amanda hits EOT
it starts over with the disk entry it was writing.  This can waste
a fair amount of tape with large disks and small tapes.
 
>    - my library has 4 drives in it, which can all write at once.  Do I
>      need to go out and buy 3 more backup hosts, split up my changer's
>      SCSI bus and partition the library into 4 virtual libraries in
>      order to actually do concurrent backups? Maybe I can run separate
>      amdump instances that don't know anything about each other? ugh :)

I'm not sure its possible to run concurrent Amanda's (at least not
without compiling different versions using different ports, etc).
Your best bet would be to use the RAIT driver, which would also raise
the limit on filesystem/directory size to be larger than your tape
size.

Frank

> A lot of the FAQs and stuff have $Id$ strings from eg 2000, so I'm
> hoping that a lot of this is stale information and Amanda can actually
> be used in shops with non-trivial backup requirements (after all if it
> is used for a UMD, those folks must have huge backup requirements)...
> Anyone know if I am mistaken, or have workarounds to address these
> issues?
> 
> Any help or comments are greatly appreciated.



--
Frank Smith                                                fsmith AT hoovers 
DOT com
Systems Administrator                                     Voice: 512-374-4673
Hoover's Online                                             Fax: 512-374-4501