Thank You all for all your input...you have enlightened me immensely
.became so used to using commercial applications that due the
thinking for you.
Don
Gene Heskett wrote:
>On Thursday 17 January 2002 09:10 am, Don Potter wrote:
>
>>I ran the tapetype test to our tapedrive (ADIC DS9400D)
On Thursday 17 January 2002 09:10 am, Don Potter wrote:
>I ran the tapetype test to our tapedrive (ADIC DS9400D) using
> DLTTAPE IV. I frontpaneled the compression so I expected at
> least 40 GB when the tapetype was completed. But I only got
> about 17GB:
>
>Command: tapetype -d /dev/rmt/0n
>
>
Though I've been administering an amanda setup for some months now, I
still consider myself a newbie as there's so many nuances I haven't
explored yet. Being a live system tends to discourage the kind of
blind experimentation which is my usual learning method :)
It seems that the setup I've inhe
John R. Jackson wrote:
>
> This would be a more accurate test:
>
> dump 0sf 1048576 - /dev/sda5 | (restore -tvf - ; cat > /dev/null)
Suprisingly that ran fine:
dir 478497 ./kerberos/sbin
leaf478498 ./kerberos/sbin/sserver
leaf 176 ./tmp
DUMP: 81.09% done at 8174 kB/s, fin
Hi, thanks for replying.
John R. Jackson writes:
> Could you give some more detail? First, what version of Amanda? Second,
> did Amanda go through all six tapes? The way you have it set up above,
> assuming one tape per day, it should have used the first five tapes
> in the first week, then us
>I have a amanda client on linux box, and I need to run three ( 3) concurrent
>jobs.
By that I assume you mean you want the client to be backed up by three
concurrent amdump's?
>When I run the first set, i have no problems , but the secont and third run
>returns the following message on mail:
For the benefit of those who might be reading this thread in the archives
someday...
This test worked just fine:
> $ .../amindexd -t
> 220 clerk AMANDA index server (2.4.2p2) ready.
> SECURITY USER root
> 200 Access OK
> DATE 2002-01-17
> 200 Working date set to 2002-01-17.
> QU
amverify is trying to recover the data from the tape. you may want to do
some tests using tar or dd. these will probably fail too. what tape
drive are you using and what block size are you using? what OS?
On Thu, Jan 17, 2002 at 09:21:15AM -0500, KEVIN ZEMBOWER wrote:
> Friends, with the recent p
>This makes sense because when I ran my initial Amanda dump on that host, I
>had no holding-disk defined, and it did backup the filesystem at level 0,
>and that filesystem has over 24GB of data on it, albeit, they are all small
>.c files and the such. I am left wondering then how chunksize fits i
>I'm getting errors like the following on the console during my amanda
>runs:
>Jan 16 12:04:20 www kernel: Out of Memory: Killed process 15083
>(dumper).
Some thoughts:
What is inparallel set to? That controls how many dumper processes
are started. You might shrink it down a bit.
Can yo
>dumpcycle 1 weeks
>runspercycle 5
>tapecycle 6 tapes
>...
>As an experiment, at the end of the first dumpcycle, I decided
>to let Amanda do its thing with this set of tapes, and see what
>happened.
Could you give some more detail? First, what version of Amanda? Second,
did Amanda go t
>... Is there any chance my thrashing about has screwed up some vital
>file there that could trigger this error? ...
Possibly, but it doesn't really look like it.
>... I did learn that amindexd is writing debug logs:
>
>amindexd: debug 1 pid 2586 ruid 11 euid 11 start time Tue Jan 15 13:44:32
>The /dev/sda5 (/usr) partition misbehaves in the same way, so I did:
>
>dump 0usf 1048576 - /dev/sda5 | restore -tvf -
First, do **not** use the 'u' option when testing like this. That updates
/etc/dumpdates and will really screw up the incremental scheduling.
You should do an "amadmin force .
>... Everything's gone well with installation et al, but I'm
>confused about dumpcycles, etc.
That's a common issue.
>- 3 tapes per day (about 150Gb to be backed up). Each day's backup is a
>'full' backup i.e. no differential or incremental
>
>- 5 days per week (Monday - Friday)
>
>- 5 weeks
>oh, and in addition, I did NOT use the no-rewind tape device for the eject
>command, so that the ejected tape is already rewound and ready for re-use
>again.
Ummm, that doesn't matter. Tapes are always rewound before being ejected.
If you're using 4mm or 8mm or some type of tape with two reels
Hi,
I have a amanda client on linux box, and I need to run three ( 3) concurrent
jobs.
I have created 3 different configuration for amanda.
When I run the first set, i have no problems , but the secont and third run
returns the following message on mail:
FAILURE AND STRANGE DUMP SUMMARY:
tul
Joshua Baker-LePain wrote:
>
> On Wed, 16 Jan 2002 at 9:40pm, Chris Marble wrote
>
> > ? sendbackup: index tee cannot write [Broken pipe]
> > | DUMP: Broken pipe
> > | DUMP: The ENTIRE dump is aborted.
> > ? index returned 1
> > sendbackup: error [/sbin/dump returned 3, compress got signal 2
Hi everyone.
This problem is bugging me for long. I have a backup server running RH7.2
which has the default ipchains firewall in it. I have two hosts one running
on RH7.2(also ipchains in it) and other running on Mdk 8.1. Using the cue
from Amanda FAQ (with reasonable amt of understanding)
AIT and DLT tape drives take longer to come on-line than the original
chg-*-mtx scripts expected. I have attached the version that I modified to
work with my QualStar that has a wait loop built in to get past this
problem.
markh
-Original Message-
From: Jennifer Peterson [mailt
>Date: 16 Jan 2002 14:23:04 -0500
>From: Axel Haenssen <[EMAIL PROTECTED]>
> Subject: ADIC FastStore DLT
>
> I am trying to get amanda together for a
> Adic FastStore DLT tape drive (robot).
> Anyone ever done that??
Yes-ish. I have a tape changer script from Chris Pascoe
<[EMAIL PROTEC
Funny you should ask. I'm currently working on this very system. I'm
using chg-zd-mtx with some success, but there's still some stuff I
haven't been able to hammer out. If anyone has any insight I would be
much appreciative.
I was able to amlabel my tapes just fine, and "amtape baknon curre
IIRC, the tapetype test uses random data, so hardware compress may (?)
actually increase the amount of the data.
-Kevin Zembower
-
E. Kevin Zembower
Unix Administrator
Johns Hopkins University/Center for Communications Programs
111 Market Place, Suite 310
Baltimore, MD 21202
410-659-6139
>
On Thu, 17 Jan 2002 at 9:10am, Don Potter wrote
> I ran the tapetype test to our tapedrive (ADIC DS9400D) using DLTTAPE
> IV. I frontpaneled the compression so I expected at least 40 GB when
> the tapetype was completed. But I only got about 17GB:
tapetype writes random data, which compresse
If you
read the instructions for tapetype, it says to run it without compression.
It will typically report close to your native capacity which it looks like it is
doing.
-Original Message-From: Don Potter
[mailto:[EMAIL PROTECTED]]Sent: Thursday, January 17, 2002
8:11 AMTo:
Friends, with the recent posting indicating the need to check backup
tapes, I recently ran amverify for the first time. Since I've been
running amanda overall less than a month, I've never had to do a restore
from the tapes.
On the face of it, the amverify pasted in below looks disastrous. Since
I ran the tapetype test to our tapedrive (ADIC DS9400D) using DLTTAPE IV.
I frontpaneled the compression so I expected at least 40 GB when the tapetype
was completed. But I only got about 17GB:
Command: tapetype -d /dev/rmt/0ndefine tapetype unknown-tapetype {
comment "just produced by ta
On Thu, 17 Jan 2002 at 8:29am, R. Bradley Tilley wrote
> Doesn't amreport email what tape was used, and what mount points were backed
> up at which level every night? My amreport email is sent to a seperate
> machine. Wouldn't this solve the problem?
Yep, but it doesn't hurt to have stuff on p
Doesn't amreport email what tape was used, and what mount points were backed
up at which level every night? My amreport email is sent to a seperate
machine. Wouldn't this solve the problem?
> On Thu, 17 Jan 2002 at 10:15am, Andreas Baier wrote
>
> > What do you do, in case there is a real emerg
On Wed, 16 Jan 2002 at 9:40pm, Chris Marble wrote
> ? sendbackup: index tee cannot write [Broken pipe]
> | DUMP: Broken pipe
> | DUMP: The ENTIRE dump is aborted.
> ? index returned 1
> sendbackup: error [/sbin/dump returned 3, compress got signal 24]
> \
>
> If I take out compressio
On Thu, 17 Jan 2002 at 10:15am, Andreas Baier wrote
> What do you do, in case there is a real emergency that you don´t have to
> figure out, on what tape which dump was written without having access to
> the index ???
>
A couple of things:
1) I use the lbl-templ keyword in my tapetype, which
Hi Kasper,
hi all,
would you like to post that script on the list, so everyone could
benefit from it?
Best regards
--
Andreas Baier
MindMatics AG fon: +49 (0)89 322986-0
Frankfurter Ring 193a fax: +49 (0)89 9227 9897
80807 Munich
I have a cron job emailing me a sorted index list every night after backup
has been performed. Look:
date host disklv tape or file file status
2002-01-17 localhost /1 daily6 10 OK
2002-01-17 localhost /boot1 daily6 2
Hi all,
perhaps you asked yourself too, I don´t get the clue:
The index is stored under /var/amanda... and the index stores all
places where to find backups on the different tapes - so far am I right?
Now, the server dies and all disks go south, so /var/amanda --- the
index must be gone - so
33 matches
Mail list logo
