>- we will be starting with about 50 machines to backup, but this size will
>grow.
This number of clients won't be a problem. The more important question
is, how much data will be backed up from them? Total? Largest individual
image? Largest client?
>- we will start with a native storage capacity of around 10-11 TB this will
>grow, too.
>...
>. As i wrote we want to work without tapes and instead use
>IDE-RAIDs. As one PC can hold 2 RAIDs with up to 1.44 TB we will have a
>least 7 PCs providing diskspace for backup. ...
I'm not sure I fully understand how you're planning to set all this up.
Is it correct that you're not going to use tape, but instead, use the
"tapeio" feature to store the dump images in this big RAID area?
And you're going to have (maybe) three Amanda tape servers reaching out
to the clients to back them up, and that data will be then stored into
the 7+ boxes that actually have the RAID attached to them?
How is that RAID space going to be presented to the Amanda servers? NFS?
If so, that means you'll be sending the data across the wire twice.
Not to mention using NFS for writing. And is Linux NFS working well now?
The last I heard from someone putting up a server here (this was a while
ago, and I don't have much Linux contact), it was pretty broken.
Why not have each RAID server be an Amanda backup machine instead of
three other machines? Then you're not doing the double network transfer.
>In special i couldn't figure out by reading the archive and documentation:
>
>- whether an Amanda setup can use more than one Storage-Server (Tape-Server) ?
Assuming I've followed how you're thinking of setting this up, are you
asking if you can run the non-tape portions of Amanda on your three
Amanda servers but put the tape portion on the 7+ RAID boxes?
Amanda will not currently do that, although it's in the plans. Also,
as with NFS above, you're still going to send the data across the wire
twice, once to the dumper on one of the three servers, and then from
there to the taper on the RAID box. It might be that that could also
be worked on, but it's an even deeper change to how Amanda works.
>- When using virtual tapes ...
By "virtual tapes" are you referring to the "tapeio" Amanda code in one
of the development branches? How does that fit with the questions above
about disk space usage and whether you're going to write to (real) tape?
>, will Amanda assign the diskspace on demand or will
>it use eg. 500 MB for each virtual tape even if it effectively only uses 300
>MB of it ?
If you're talking about tapeio and the "file" device driver, it will
only use what it needs to. If you set the length to 500 MBytes and only
write a 300 MByte image, only 300 MBytes will be used (well, there's a
little more for headers and such, but certainly not the full 500 MBytes).
Note that tapeio still does not fix the problem of image overflow.
Amanda cannot handle a dump image larger than a "tape", even a virtual
one. So you will want to set the length of the virtual tape larger than
the largest full dump image.
>- if the clients could be dynamically assigned (based on backup-size/free
>space on storage-machine, load of the storage-machines, and stuff like that)
>to one of our storage machines on each backup run and talk
>directly to them, would be just great. Something like backup-clustering ;-)
>my favorite solution.
Alexandre and I talked about this roughly forever ago :-). I've still got
the notes (someplace :-) but haven't looked at them for a while.
One possibility would be to do your own amdump script. Have one machine
run planner on all the clients (they run in parallel anyway, so multiple
servers isn't buying you much) and split out the results to the other
two servers, keeping some for itself. Each machine would take the list
and create a disklist file then start with the driver step.
You'd probably want to merge the results so each Amanda server knew
about everything (since who did what would vary from day to day), or
at least send them back to the "master" (the one that runs planner),
since it would need them for the next run.
The hardest part would probably be dealing with end cases, like one of
the Amanda servers being down.
>Arne Kloecker
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
