Re: Amrecover Issue in 3.4

2016-10-28 Thread Steven Backus 
The amrecover prompt returned at 595007296 kb, after 3 hours.

Steve
-- 
Steven J. BackusComputer Systems Manager
University of Utah  E-Mail:  steven.bac...@utah.edu
Genetic EpidemiologyAlternate:  bac...@math.utah.edu
391 Chipeta Way -- Suite D  Office:  801.587.9308
Salt Lake City, UT 84108-1266   http://www.math.utah.edu/~backus

Re: Amrecover Issue in 3.4

2016-10-28 Thread Steven Backus 
On a test restore the numbers got to 67971072 kb before the file
restored, it took 20 minutes.  My concern is after the file
restored the numbers continued to grow without ending.  Prior
versions eventually gave me the amrecover prompt back.  Having to
^C out each time would be a pain.  This is an LTO6 drive with
e/sata interface.

Steve
-- 
Steven J. BackusComputer Systems Manager
University of Utah  E-Mail:  steven.bac...@utah.edu
Genetic EpidemiologyAlternate:  bac...@math.utah.edu
391 Chipeta Way -- Suite D  Office:  801.587.9308
Salt Lake City, UT 84108-1266   http://www.math.utah.edu/~backus

Re: Software vs: Hardware compression

2016-10-28 Thread Chris Hoogendyk 
I could. But, I already have on the order of 150 DLEs spread across several servers for each Amanda 
server. Amanda's inherent multi-threading allows for multiple dumpers per server being backed up, 
restricted by spindle number. So, typically, when Amanda fires off, I might have 6 or 8 dump 
processes going, and I can juggle my configuration to adjust that. Under optimal circumstances, 
those would be going on simultaneously with taping, and the SSDs would see all that action coming 
and going. What I'm getting is that the tape is on the order of 10 times faster than the dump 
process when gz is in the mix. So, the tape is seeing a lot of idle time. When gz is not in the mix, 
the dump is significantly faster than the tape, though not double.



On 10/28/16 4:27 PM, Charles Curley wrote:

On Fri, 28 Oct 2016 15:44:09 -0400
Chris Hoogendyk  wrote:


If it were "only" the Amanda server, I could go all out with pigz.
However, it is also the department server and runs mail, web, samba,
printing, etc. If I were to top out all the cores with pigz, I would
have everyone in the department complaining about performance on
other services.

Can you sneak in a -p option to pigz?




--
---

Chris Hoogendyk

-
   O__   Systems Administrator
  c/ /'_ --- Biology & Geosciences Departments
 (*) \(*) -- 315 Morrill Science Center
~~ - University of Massachusetts, Amherst



---

Erdös 4

Re: Software vs: Hardware compression

2016-10-28 Thread Alan Hodgson 
On Friday 28 October 2016 14:27:22 Charles Curley wrote:
> On Fri, 28 Oct 2016 15:44:09 -0400
> 
> Chris Hoogendyk  wrote:
> > If it were "only" the Amanda server, I could go all out with pigz.
> > However, it is also the department server and runs mail, web, samba,
> > printing, etc. If I were to top out all the cores with pigz, I would
> > have everyone in the department complaining about performance on
> > other services.
> 
> Can you sneak in a -p option to pigz?

Maybe set client_custom_compress to a script that does something like"nice -n 
19 pigz $@".

pigz shouldn't interfere much with other workloads, especially niced.

Re: Software vs: Hardware compression

2016-10-28 Thread Charles Curley 
On Fri, 28 Oct 2016 15:44:09 -0400
Chris Hoogendyk  wrote:

> If it were "only" the Amanda server, I could go all out with pigz.
> However, it is also the department server and runs mail, web, samba,
> printing, etc. If I were to top out all the cores with pigz, I would
> have everyone in the department complaining about performance on
> other services.

Can you sneak in a -p option to pigz?


-- 

The right of the people to be secure in their persons, houses, papers,
and effects, against unreasonable searches and seizures, shall not be
violated, and no Warrants shall issue, but upon probable cause,
supported by Oath or affirmation, and particularly describing the
place to be searched, and the persons or things to be seized.
-- U.S. Const. Amendment IV

Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB

Amrecover Issue in 3.4

2016-10-28 Thread Steven Backus 
I upgraded to 3.4 and found amrecover to be quite a bit slower.
Perhaps someone thinks we need to watch it read the tapes.  Is
there some way to turn off these numbers?

Extracting files using tape drive /dev/changer on host serendipity.med.utah.edu.
Load tape gen2011 now
Continue [?/Y/n/s/d]? 
Restoring files into directory /tmp
All existing files in /tmp can be deleted
Continue [?/Y/n]? 

411840 kb 
435424 kb
880064 kb 
901248 kb
 (30 minutes or more of this)
./users/backus/.cshrc  <--file I asked to be restored
69142720 kb 
69251904 kb
70801632 kb 
 (an hour or so of this)
385915232 kb
38632 kb
(still going...)

Steve
-- 
Steven J. BackusComputer Systems Manager
University of Utah  E-Mail:  steven.bac...@utah.edu
Genetic EpidemiologyAlternate:  bac...@math.utah.edu
391 Chipeta Way -- Suite D  Office:  801.587.9308
Salt Lake City, UT 84108-1266   http://www.math.utah.edu/~backus

Re: Software vs: Hardware compression

2016-10-28 Thread Chris Hoogendyk 
If it were "only" the Amanda server, I could go all out with pigz. However, it is also the 
department server and runs mail, web, samba, printing, etc. If I were to top out all the cores with 
pigz, I would have everyone in the department complaining about performance on other services.



On 10/28/16 3:37 PM, J Chapman Flack wrote:

On 10/28/2016 02:37 PM, Chris Hoogendyk wrote:


all of the data is being compressed, and the compression is significant,
but it has become the bottleneck. Top shows multiple of Amanda's gz
processes at the top of the list all day.

In your setup, are there enough DLEs to compress that Amanda can keep
all your cores busy with gz processes working on different DLEs?

Or do you have some cores underutilized, that you could maybe bring
into the game by using pigz instead of gz?

Chapman Flack



--
---

Chris Hoogendyk

-
   O__   Systems Administrator
  c/ /'_ --- Biology & Geosciences Departments
 (*) \(*) -- 315 Morrill Science Center
~~ - University of Massachusetts, Amherst



---

Erdös 4

Re: Software vs: Hardware compression

2016-10-28 Thread J Chapman Flack 
On 10/28/2016 02:37 PM, Chris Hoogendyk wrote:

> all of the data is being compressed, and the compression is significant,
> but it has become the bottleneck. Top shows multiple of Amanda's gz
> processes at the top of the list all day.

In your setup, are there enough DLEs to compress that Amanda can keep
all your cores busy with gz processes working on different DLEs?

Or do you have some cores underutilized, that you could maybe bring
into the game by using pigz instead of gz?

Chapman Flack

Re: Software vs: Hardware compression

2016-10-28 Thread J Chapman Flack 
On 10/28/2016 02:37 PM, Chris Hoogendyk wrote:
> It also knows what a particular DLE can be compressed to based
> on the history. If the tape drive is doing the compression, then it is a
> black box. Amanda doesn't know what the DLE got compressed to, and it
> doesn't know how that relates to the capacity of the tape. That makes
> planning more difficult.

This might be a good place to plug an idea I floated back in January:
http://marc.info/?l=amanda-hackers=145312885902912=2

... it turns out in the SCSI standard for tape drive commands,
there are ways to ask the drive, after writing each fileset,
"hey drive! what did that last set compress to?"

I haven't had time to pursue it ... I think the part I could probably
do without help is teaching the tape driver to ask the drive for the
statistics. It might take a more seasoned Amanda hacker to work out
how to get those numbers stored in the history, similarly to what
happens with software compression, so they can be used by the planner
later.

It still does strike me as worth exploring

Chapman Flack

Re: Software vs: Hardware compression

2016-10-28 Thread Chris Hoogendyk 

That is somewhat of a complicated question.

The simplest statement is that if Amanda manages the compression, and you have told it the capacity 
of the tape, then it knows what can fit on the tape. It also knows what a particular DLE can be 
compressed to based on the history. If the tape drive is doing the compression, then it is a black 
box. Amanda doesn't know what the DLE got compressed to, and it doesn't know how that relates to the 
capacity of the tape. That makes planning more difficult. Also, computers are getting faster and are 
typically multi core, so having gz running compressions for multiple DLEs on multiple cores is 
easily manageable.


Then there are the howevers. I'm currently dealing with a couple of servers that are each getting 
into the range of 50 to 100 TB of capacity that needs to be backed up to LTO6. One of those servers 
has been too frequently running into 36 hour or even 60 hour backup cycles. As I was comparing the 
two servers, I noticed that on one server, the largest amount of data consists of TIFF files for the 
digitized herbarium collection. Those don't compress, so I had set those DLEs to not use 
compression. I was getting well over 200MB/s from disk to holding disk for those, and then on the 
order of 155MB/s out to tape. Then, on both this same server and on the server that was running over 
a day, the DLEs that were being compressed were getting something on the order of 15MB/s from disk 
to holding disk, followed by on the order of 155MB/s out to tape. On the one server, that wasn't 
such a big deal, because the largest amount of data was not being compressed. On the other server, 
all of the data is being compressed, and the compression is significant, but it has become the 
bottleneck. Top shows multiple of Amanda's gz processes at the top of the list all day.


So, I'm beginning to rethink things for this server. These are SuperMicro servers with two AMD 
Opteron2.6GHz12core processor 6344 running Ubuntu LTS 14.04. They both have large external SAS 
multipath disk cabinets that are managed with mdadm and lvm. They both currently have about 24 
external drives ranging from 1TB to 6TB built into a number of Raid5 and Raid6 arrays, and they both 
have two 1TB enterprise SSDs for holding disks. The tape systems are Overland NEOs 200 series with 
IBM LTO6 tape drives. My understanding of LTO6 is that the compression is hardware accelerated and 
is not supposed to slow down the data transfer. It is certainly going to be a bit of an experiment, 
but I'm reaching the point where I need to figure out how to get these backups done more quickly. As 
it is now, the tape is getting a lot of idle time while it waits for DLEs to be completed and ready 
to be written out to tape.


I've been using Amanda for more than 10 years on these servers and their predecessors with LTO6 and 
previously with AIT5, and it has always worked well. I'm only now getting the rapidly increasing 
demand for large data arrays that is putting real stress on our backup capabilities. I've got 3 
Amanda servers with LTO6 libraries backing up about 12 servers in 4 different departments.



On 10/28/16 12:40 PM, Ochressandro Rettinger wrote:


Why does Amanda recommend the use of software compression vs: the built in 
hardware compression of the tape drive itself?  Is that in fact still the current recommendation?


-Sandro



--
---

Chris Hoogendyk

-
   O__   Systems Administrator
  c/ /'_ --- Biology & Geosciences Departments
 (*) \(*) -- 315 Morrill Science Center
~~ - University of Massachusetts, Amherst



---

Erdös 4

RE: Where to acquire the Perl modules?

2016-10-28 Thread Ochressandro Rettinger 
OK, I did that, but now yum complains about the missing 
requires in the rpmdb every time I install something.  :-/  Do you know how 
hard it would be to repackage the RPM to not have this particular packaging bug?

-Sandro

From: Jean-Louis Martineau [mailto:jmartin...@carbonite.com]
Sent: Thursday, October 27, 2016 2:50 PM
To: Ochressandro Rettinger ; 
'amanda-users@amanda.org' 
Subject: Re: Where to acquire the Perl modules?

This is a packaging bug,
Install the package without checking the dependencies: --nodeps

Jean-Louis

On 27/10/16 04:21 PM, Ochressandro Rettinger wrote:

I'm trying to install Amanda on an RHEL 7 machine.  I 
downloaded the rpm from the zmanda downloads page, but when I went to install 
it, there were complaints about unfulfilled dependencies.  Google has not 
revealed the location of these packages to me.

Error: Package: amanda-backup_server-3.4-1.rhel7.x86_64 
(/amanda-backup_server-3.4-1.rhel7.x86_64)
   Requires: perl(Dancer2)
Error: Package: amanda-backup_server-3.4-1.rhel7.x86_64 
(/amanda-backup_server-3.4-1.rhel7.x86_64)
   Requires: perl(Amanda::Recovery)
Error: Package: amanda-backup_server-3.4-1.rhel7.x86_64 
(/amanda-backup_server-3.4-1.rhel7.x86_64)
   Requires: perl(Amanda::DB)
Error: Package: amanda-backup_server-3.4-1.rhel7.x86_64 
(/amanda-backup_server-3.4-1.rhel7.x86_64)
   Requires: perl(Amanda::Service)

Any suggestions?

-Sandro

Software vs: Hardware compression

2016-10-28 Thread Ochressandro Rettinger 

Why does Amanda recommend the use of software compression vs: 
the built in hardware compression of the tape drive itself?  Is that in fact 
still the current recommendation?

-Sandro

restoring from vtapes on client machine

2016-10-28 Thread John G Heim 
I am using the ubuntu amanda-server and amanda-client packages (3.3.6) 
on ubuntu server 16.04 to backup to virtual tapes on an NFS mounted file 
system. Everything is great on the backup server. I can run amrecover 
locally and recover files. But I thought I'd try mounting the  NFS share 
on a client machine to see if I could recover files that way. I thought 
if the backup server ever goes down, I might still be able to recover 
files on the client machine.



So I installed amanda-server on the client machine and copied the 
contents of /etc/amanda/DailySet1/ to the client. Then I ran:



# amrecover DailySet1 -o auth=local -s localhost

That gives me the error message, ""501 Could not read config file for 
DailySet1!". I amd doing this as root. Root does have permission to open/read 
/etc/amanda/DailySet1/amanda.conf.





--
--
John G. Heim; jh...@math.wisc.edu; sip://jh...@sip.linphone.org