Re: amrecover very slow

2004-10-20 Thread Paul Bijnens
Joe Konecny wrote: FreeBSD 5.2.1, Amanda 2.4.4p2 Had to do the first real amrecover today and it was painfully slow. I am using indexing and the file to recover was about 140K. It took from 14:47 to 16:22. Any tips? Here is a link to the debug file if anyone wants to look at it... (It's about

Re: [OT] Tape changer recommendations

2004-10-20 Thread Alexander Jolk
Daniel Bentley wrote: So, anyone have suggestions on external changer devices, 8 tape capacity? Any brands/model families you would particularly recommend, or would recommend we -avoid-? Also, as we've been dealing exlcusively with DDS here, what are pros- and cons- of the different media

estimation is _very slow_ and hangs.

2004-10-20 Thread Iulian Topliceanu
Hi, I had amanda running in the same configuration as now, for over 4 months without any major problem. After migrating the filesystem from XFS to EXT3 everything is a mess. The biggest problem I have is with this volume. /dev/vol0/mailspool1 212G 37G 175G 18% /var/spool/mail It might be

Re: Multi-Gb dumps using tar + software compression (gzip)?

2004-10-20 Thread Toralf Lund
Michael Schaller wrote: Hi Toralf, I'v had nearly the same problem this week. I found out that this was a problem of my tar. I backed up with GNUTAR and compress server fast. AMRESTORE restored the file but TAR (on the server!) gave some horrible messages like yours. I transferred the file to the

Re: amrecover very slow

2004-10-20 Thread Joe Konecny
Paul Bijnens wrote: snip Different possibilities. First make sure the network is not in the way (e.g. a duplex mismatch on one of the switches, frequent mistake). I'm backing up the server with the tape drive in it. Then, do you have amrecover_do_fsf yes in the configuration? If not, then amanda

Re: Multi-Gb dumps using tar + software compression (gzip)?

2004-10-20 Thread Toralf Lund
Gene Heskett wrote: On Tuesday 19 October 2004 11:10, Paul Bijnens wrote: Michael Schaller wrote: I found out that this was a problem of my tar. I backed up with GNUTAR and compress server fast. AMRESTORE restored the file but TAR (on the server!) gave some horrible messages like yours. I

Re: amrecover very slow

2004-10-20 Thread Paul Bijnens
Joe Konecny wrote: Paul Bijnens wrote: Next, how large is the image itself. If the dump file is 30 Gbyte then it still takes some time to crawl through that amount to locate your 140K file. A tape device is a sequential device. Indexing with amanda does not turn it into a random access device.

Re: amrecover very slow

2004-10-20 Thread Joe Konecny
Paul Bijnens wrote: snip Common misconcepton. Amanda actually only schedules and manages the backup, but the backup itself is done by another program, dump or gnutar or smbclient currently. You run into limitations of the dump/restore programs (supplied by the OS). Dump or restore does not have

Re: Multi-Gb dumps using tar + software compression (gzip)?

2004-10-20 Thread Toralf Lund
Paul Bijnens wrote: Toralf Lund wrote: Other possible error sources that I think I have eliminated: 1. tar version issues - since gzip complains even if I just uncopress and send the data to /dev/null, or use the -t option. 2. Network transfer issues. I get errors even with server

Re: [paul.bijnens@xplanation.com: Re: Multi-Gb dumps using tar + software compression (gzip)?]

2004-10-20 Thread Toralf Lund
Patrick Michael Kane wrote: If you restore a dump file to disk someplace and run file on it, what type of file does it tell you it is? Do you mean a normal amrestored'ed file, or a raw recovery? Actually, I have examples of both: # file fileserv._scanner2_Hoyde.20041008.6

file restoring problem

2004-10-20 Thread Kuba Molek
Hellow, I've got a tape with amanda backup with GNUTAR option set. I heve restored one disk file with command: # mt -f /dev/nst0 rewind # amrestore -h /dev/nst0 so I have one file: amanda.__foo_backup.20040904.0 and finaly I don't know how to restore a file from this dump. When I

Re: file restoring problem

2004-10-20 Thread Alexander Jolk
Kuba Molek wrote: so I have one file: amanda.__foo_backup.20040904.0 dd if=amanda.__foo_backup.20040904.0 bs=32k count=1 gives you an explanation of how to proceed. Most probably you need to do something like dd if=amanda.__foo_backup.20040904.0 bs=32k skip=1 | gunzip -dc | tar

Re: all estimates failed for gnutar

2004-10-20 Thread Fernan Aguero
+[ To Toomas Aas [EMAIL PROTECTED] (13.Oct.2004 16:26): | [snipped] | | Further, the directory listing below shows that files owned by operator | | are dated Sep 28, whereas files owned by amanda are dated Sep 30. | | | | This leads me to think that you have somehow made two installations

Re: Multi-Gb dumps using tar + software compression (gzip)?

2004-10-20 Thread Eric Siegerman
On Wed, Oct 20, 2004 at 01:18:45PM +0200, Toralf Lund wrote: Other possible error sources that I think I have eliminated: [ 0. gzip ] 1. tar version issues [...] 2. Network transfer issues [...] 3. Problems with a specific amanda version [...] 4. Problems with a special disk [...]

Re: amflush problem

2004-10-20 Thread Jon LaBadie
On Thu, Oct 14, 2004 at 11:10:47AM -0400, Frederic Medery wrote: Hello, every time I do a amflush i received this report : The dumps were flushed to tape daily-05. The next tape Amanda expects to use is: daily-02. STATISTICS: Total Full Daily

Re: file restoring problem

2004-10-20 Thread Jon LaBadie
On Wed, Oct 20, 2004 at 06:40:43PM +0200, Kuba Molek wrote: Hellow, I've got a tape with amanda backup with GNUTAR option set. I heve restored one disk file with command: # mt -f /dev/nst0 rewind # amrestore -h /dev/nst0 so I have one file: amanda.__foo_backup.20040904.0 and

Re: tape verify

2004-10-20 Thread Alexander Jolk
Matt Hyclak wrote: man amverify ...and if you have a tape changer, `amverifyrun'. Alex -- Alexander Jolk / BUF Compagnie tel +33-1 42 68 18 28 / fax +33-1 42 68 18 29

Re: newb: getting started

2004-10-20 Thread Erik Anderson
On Thu, 14 Oct 2004 16:25:01 -0500, Erik Anderson [EMAIL PROTECTED] wrote: lpdlnx00 etc # mt -f /dev/sg2 offline /dev/sg2: Operation not permitted Here's what the changer currently looks like: lpdlnx00 etc # mtx -f /dev/sg1 status Storage Changer /dev/sg1:1 Drives, 6 Slots ( 0

Re: Multi-Gb dumps using tar + software compression (gzip)?

2004-10-20 Thread Eric Siegerman
On Wed, Oct 20, 2004 at 12:52:12PM -0400, Eric Siegerman wrote: echo $* /securedirectory/sum$$ md5sum /securedirectory/FIFO$$ /securedirectory/sum$$ Oops: the echo command shouldn't have an . -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / The

amanda-2.4.4p3, file driver, chg-disk, and infinite driver retries

2004-10-20 Thread Todd Pfaff
I'm using amanda-2.4.4p3 with the file driver and chg-disk changer for vtapes. Sometimes a dump fails and driver retries: driver: client /some/path 1 [dump to tape failed, will try again] and then it fails again and retries again, and this repeats until I kill the amanda processes. This last

Re: amanda-2.4.4p3, file driver, chg-disk, and infinite driver retries

2004-10-20 Thread Jon LaBadie
On Wed, Oct 20, 2004 at 05:02:38PM -0400, Todd Pfaff wrote: I'm using amanda-2.4.4p3 with the file driver and chg-disk changer for vtapes. Sometimes a dump fails and driver retries: driver: client /some/path 1 [dump to tape failed, will try again] and then it fails again and retries

Re: amanda-2.4.4p3, file driver, chg-disk, and infinite driver retries

2004-10-20 Thread Gene Heskett
On Wednesday 20 October 2004 17:54, Jon LaBadie wrote: On Wed, Oct 20, 2004 at 05:02:38PM -0400, Todd Pfaff wrote: I'm using amanda-2.4.4p3 with the file driver and chg-disk changer for vtapes. Sometimes a dump fails and driver retries: driver: client /some/path 1 [dump to tape failed,

Re: amanda-2.4.4p3, file driver, chg-disk, and infinite driver retries

2004-10-20 Thread Jon LaBadie
On Wed, Oct 20, 2004 at 10:08:59PM -0400, Gene Heskett wrote: On Wednesday 20 October 2004 17:54, Jon LaBadie wrote: On Wed, Oct 20, 2004 at 05:02:38PM -0400, Todd Pfaff wrote: I'm using amanda-2.4.4p3 with the file driver and chg-disk changer for vtapes. Sometimes a dump fails and

Re: amanda-2.4.4p3, file driver, chg-disk, and infinite driver retries

2004-10-20 Thread Todd Pfaff
Thanks to Jon LaBadie, Gene Heskett, and Jean-Louis Martineau for replies. Jean-Louis supplied me with a patch which I modified slightly and that I'm now using. It turns out that some code in server-src/driver.c will allow a dump to be retried indefinitely, if dumper returns TRYAGAIN and taper

Re: amanda-2.4.4p3, file driver, chg-disk, and infinite driver retries

2004-10-20 Thread Gene Heskett
On Wednesday 20 October 2004 22:33, Jon LaBadie wrote: On Wed, Oct 20, 2004 at 10:08:59PM -0400, Gene Heskett wrote: On Wednesday 20 October 2004 17:54, Jon LaBadie wrote: On Wed, Oct 20, 2004 at 05:02:38PM -0400, Todd Pfaff wrote: I'm using amanda-2.4.4p3 with the file driver and chg-disk

Re: amanda-2.4.4p3, file driver, chg-disk, and infinite driver retries

2004-10-20 Thread Jon LaBadie
On Wed, Oct 20, 2004 at 10:52:47PM -0400, Todd Pfaff wrote: Jean-Louis supplied me with a patch which I modified slightly and that I'm now using. He's good isn't he :)) It turns out that some code in server-src/driver.c will allow a dump to be retried indefinitely, if dumper returns

Re: amflush problem

2004-10-20 Thread Jon LaBadie
On Wed, Oct 20, 2004 at 01:04:12PM -0400, Jon LaBadie wrote: On Thu, Oct 14, 2004 at 11:10:47AM -0400, Frederic Medery wrote: Hello, every time I do a amflush i received this report : The dumps were flushed to tape daily-05. The next tape Amanda expects to use is: daily-02.