* John R. Jackson <[EMAIL PROTECTED]> (Thu, Jul 19, 2001 at 10:53:03PM -0500)
>>The Apollo fails to return an estimate and fails to backup. The estimates
>>are taking about 6hrs to complete. ...
> Ick. I'm sure that's because GNU tar does not perform estimates as fast
> as ufsdump can.
> One
"John R. Jackson" schrieb:
>
> >One of my clients does not backup. amcheck detects no error. What do I
> >check for?
>
> First, see if it ever gets done by looking at /tmp/amanda/sendsize*debug.
> Also, watch for the dump process to go away.
After a few hours, all the processes are have gone
Joseph McDonald schrieb:
>
> is there a way to setup amanda to do a full backup say every week to a tape
> drive, and do incremental backups to a hard disk storage?
That's not recommended. Anaway, just use amadmin once a week (possibly
out of cron) to do your full dump to tape, then have an in
Hi!
>> Does anybody have a clue, what could be the reason for the dumper
>> failing to write large level 0 files? The amdump file just says:
>>
>> driver: result time 6459.975 from dumper3: \
>> FAILED 03-4 ["data write: Invalid argument"]
John> What OS are you using on the tape server (hol
Yup,
Tried this. When I first installed amanda on the client (yes I am
talking about the client) dump wasn't present so I installed it using:
apt-get install dump and recompiled amanda. I ran make distclean and removed
config.cache before running config again. I've checked the paths for
/sbin/
John,
I tried what you suggested and this is what I got:
bash-2.02$ mt -f /dev/rst0 rewind
bash-2.02$ dd if=/dev/rst0 bs=32k
0+0 records in
0+0 records out
0 bytes transferred in 14.688649 secs (0 bytes/sec)
My OS is FreeBSD and I am using DAT DSS2 4Gbytes...
I will be on vacation for two weeks b
There appears to be a bug in the way that Redhat decides to load the ST
module. It checks to see if /proc/scsi/scsi is present then it checks
for a tape device. The problem is that /proc/scsi/scsi doesn't exist if
the tape drive is the only device on the SCSI chain.
So, I manually load the ST m
OK,
it works.
The reason for these strange messages was the following. In one of my
attempts to rebuild the package I used the --with-udpportrange option and
was cool enough to select the range above 1024. Which was not good for
bsd_security_ok in security.c. And after that I didn't clean the so
Hi everyone
I've been using Amanda now for about 2 months to back up 5 Unix machines
with great success. It's a wonderful tool that makes life s much
easier for a time-strapped grad student.
I'm running Amanda 2.4.1p1 on Irix 6.5.11. Over the last week or so,
amdump has not been able to ge
Yes.
The main problem exists when I run `amcheck -c ` from the tape host
(a different box), all looks fine on the client.
Matt
- Original Message -
From: "Jolet, John" <[EMAIL PROTECTED]>
To: "'Matthew Baker'" <[EMAIL PROTECTED]>
Sent: Friday, July 20, 2001 2:34 PM
Subject: RE: [DUMP pro
Also Sprach Jan Boshoff:
> Hi everyone
>
> I've been using Amanda now for about 2 months to back up 5 Unix machines
> with great success. It's a wonderful tool that makes life s much
> easier for a time-strapped grad student.
>
> I'm running Amanda 2.4.1p1 on Irix 6.5.11. Over the last we
On Thu, Jul 19, 2001 at 03:28:27PM -0500, John R. Jackson wrote:
> >I've set up amanda successfully, with a tape in the drive (labelled
> >with amlabel). amcheck was passed. ...
> Did it say it was happy with the tape?
> >When I tried to run amdump straight ...
> >*** A TAPE ERROR OCCURRED: [no t
Hi all! me again :-)
I got this strange message this morning from amreport.:
===
These dumps were to tape Day11.
The next tape Amanda expects to use is: Day01.
FAILURE AND STRANGE DUMP SUMMARY:
San/dev/sd0j lev 0 FAILED [errfile open "/tmp/amanda/San._dev_s
>calcsize does all 3 estimates in one go ...
But it does not support exclusion patterns. That's the one major
thing holding me back from supporting it.
Now if someone wants to figure out how to link calcsize with the GNU
tar pattern matching code ... :-)
> Gerhard
John R. Jackson, Techn
>Tried this. When I first installed amanda on the client (yes I am
>talking about the client) dump wasn't present so I installed it using:
>apt-get install dump and recompiled amanda. I ran make distclean and removed
>config.cache before running config again. ...
Oh, fine. So you're one of
>Comparing this to the total number of filesystems, sendsize is
>outrageously slow. Any idea why? ...
>Anyhow, may this be related in any way with the error message in
>...
>killpgrp: debug 1 pid 45070 ruid 1003 ...
>/usr/local/libexec/amanda/killpgrp: version 2.4.2p2
>error [must be invoked by
>It's a Solaris 2.5.1 box. I didn't specify any chunksize, so my
>thinking was that the default of 1 Gb is fine.
It should have been. You might set it explicitly just to be sure.
You might also check the ulimit values (and maybe the disk quota) for your
Amanda user to make sure you're not bang
>What will cause a failure in estimating the filesystem size?
It might be taking too long, or something else may have failed. Take a
look at /tmp/amanda/sendsize*debug on the client. Look for any errors,
of course, but also subtract the end time on the last line from the
start time on the first
>I tried what you suggested and this is what I got:
>bash-2.02$ mt -f /dev/rst0 rewind
>bash-2.02$ dd if=/dev/rst0 bs=32k
>0+0 records in
>0+0 records out
OK, that says the tape is empty. It's as though someone did:
mt -f /dev/nrst0 rewind
mt -f /dev/nrst0 eof
BTW, you should use /dev/nrst
>Hi all! me again :-)
Hello, again :-).
> San/dev/sd0j lev 0 FAILED [errfile open "/tmp/amanda/San._dev_sd0j.0.err
>out": No such file or directory]
This comes from dumper **on the tape server machine**. It tried to do
a simple create of that file and got back an error. About the only wa
I'm running backups on 3 Linux systems, one of the systems is a Cobalt
Qube. All the backups are done using GNU tar. It works OK but the
estimation time on the backups is nasty. I think I'll turn off the
estimation and just run full dumps every day. The Qube is the slow system
with the problem be
I am having problems running amdump. Everything seems to be fine with
amcheck. But when I run amdump I get this message:
spindletop 46% ./amdump DailySet1
amdump: must be run as user backup
spindletop 47% whoami
backup
what's the meaning of this?
Nupur
>My question is this. Why run a separate estimate at all? Why not just
>monitor the last couple of backups and extrapolate?
That's been suggested before, but nobody has had the time to work on it.
It should probably be a dumptype option. I'm perfectly happy with the
way estimates are done on my
>spindletop 46% ./amdump DailySet1
>amdump: must be run as user backup
>spindletop 47% whoami
>backup
>
>what's the meaning of this?
That you're not who you think you are? :-)
It's harder than you think for a script to find out who it is running
as, and amdump used to have problems with this.
Wow!
I was just going to write about this. I have just turned on gnutar
backups. I noticed that the estimates are basically tar operations with
all of the ouput going to /dev/null. That is what's taking the time.
Not to get the file's size, but to move the date through that system
pipe into
Hi,
on a particular host (Linux 2.4.6-prexy-xfs, RH 7.1 + LVM + XFS, Amanda
2.4.2p2) sometimes sendsize fails to estimate sizes with xfsdump.
If it fails, it's always /var/spool/news and /var/spool/squid.
/tmp/amanda/sendsize lists "xfsdump: estimated dump size: xy bytes".
Other filesystems like
>... I noticed that the estimates are basically tar operations with
>all of the ouput going to /dev/null. That is what's taking the time.
>Not to get the file's size, but to move the date through that system
>pipe into /dev/null.
Nope. Tar knows it is writing to /dev/null and optimizes out the
> I was just going to write about this. I have just turned on gnutar
> backups. I noticed that the estimates are basically tar operations with
> all of the ouput going to /dev/null. That is what's taking the time.
> Not to get the file's size, but to move the date through that system
> pipe int
> I was just going to write about this. I have just turned on gnutar
> backups. I noticed that the estimates are basically tar operations with
> all of the ouput going to /dev/null. That is what's taking the time.
> Not to get the file's size, but to move the date through that system
> pipe int
29 matches
Mail list logo
