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?
* 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 away. See
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
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 (holding disk)
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
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
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
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
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
Yes.
The main problem exists when I run `amcheck -c config` 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
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 week or
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
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,
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
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/nrst0,
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 way
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
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. You
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
24 matches
Mail list logo
