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.
>
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
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
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
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 f
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
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 re
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
On Wed, Oct 20, 2004 at 12:52:12PM -0400, Eric Siegerman wrote:
> echo $* >/securedirectory/sum$$ &
> md5sum >/securedirectory/sum$$ &
Oops: the "echo" command shouldn't have an "&".
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The animal that
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 I
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
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.200409
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
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 [
+[ 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
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
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
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
fileserv._scanne
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
com
Paul Bijnens wrote:
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 any i
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
compression, and I'm as
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.
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
Paul Bijnens wrote:
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 will
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 th
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 212
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
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 5
28 matches
Mail list logo