Amanda-Users

Re: [Amanda-users] Advice needed on Linux backup strategy to LTO-4 tape

2009-08-14 15:37:38
Subject: Re: [Amanda-users] Advice needed on Linux backup strategy to LTO-4 tape
From: Chris Hoogendyk <hoogendyk AT bio.umass DOT edu>
To: Cyrille Bollu <Cyrille.Bollu AT fedasil DOT be>
Date: Fri, 14 Aug 2009 14:27:01 -0400


Cyrille Bollu wrote:
Here's my (very) small personnal experience:

A few years ago, when I tried it, I couldn't enable server-side software compression while bypassing the holding disk with my IBM ULTIUM LTO-3 drive: Tape speed was sinking to about 5MB/s.

My backup server was a Dell PowerEdge 2850 with 4 Intel Xeon 3GHz and 8MB RAM using RHEL-4.0 and amanda-2.4.4p3-1.

Maybe did I do something wrong at that time (I just had 1 try). Beware though.

That actually makes perfect sense.

By not using a holding disk, you are disabling Amanda's ability to run multiple things in parallel. The tape device now controls everything. That is to say, you cannot do a backup without streaming it to the tape. So, you cannot do more than one at a time. Furthermore, as that one backup gets done, the compression has to be done as it is being streamed to the tape. So all the processes from reading a remote disk, to transferring it over the network, to compressing it, to writing it to the tape are all tied together in a single pipe. Any slowdown along that pipe will affect everything else. When the tape doesn't get what it needs to keep going, it will stop and then have to start up again and reposition, and then you get shoe shining.

When you use a holding disk, Amanda can stream multiple backups to the holding disk simultaneously. It can compress them there when it has them and do it in parallel with other processes. Once it has something ready to go to tape, it can dd it straight from the disk to the tape as an independent process in parallel with the other things that are going on. That final step out to the tape is no longer constrained by any of the other steps along the way. Now all you have to worry about is tuning various pieces of hardware and software to get the throughput you want.


--
---------------

Chris Hoogendyk

-
  O__  ---- Systems Administrator
 c/ /'_ --- Biology & Geology Departments
(*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
<hoogendyk AT bio.umass DOT edu>

---------------
Erdös 4



<Prev in Thread] Current Thread [Next in Thread>