Hi,
'amrecover' would suggest that the tape server can be differnet than
the index server. Is this possible ( if so, I don't know how this
would be set)? This is not at the heart of what I'm getting at but
it is good place to start.
--
Paul Yeatman (858) 534-9896[EMAIL
Hi, I started an amdump of a configuration containing a few laptops and
which was still running when I left for the weekend on Friday. One of
the laptops was shutdown while a dump was actively being performed to
tape. Coming in this Monday, amdump is still running but (as the
machine is
I've been told (I'm sure on this list) that generally hardware
compression is better than software compression. I throw that out
for whatever it is worth.
Paul
(It would be great to get ~47G on a tape. I get about ~14G,
being a different--DDS3--type tape, of course.)
-In response to your
-In response to your message-
--received from Chris Marble--
I've got a mix of 2.4.2 and 2.4.2p2 on Linux, Solaris, HP-UX and
IRIX systems. I'm using varients of dump everywhere. I've never had
a problem with amanda processes restarting once I got them killed.
Have you run an amcleanup
Hi, I'm trying to figure out why I still get level 0 dumps when in
degraded mode (no tape available).
I took the default of 100% for the reserve parameter first being that
the result, as I understand it to be, is as I desire. When Amanda
would still run level 0's on some machines in degraded
Whoops. I noticed retroactively that the level stated for sabre:/biff
in the after start degraded mode schedule is level 7. There is a 0
in that row and looking too quickly I mistook that for the dump level
column. I noticed this after discovering that the file created on the
holding disk for
-In response to a message from John R. Jackson-
Hi, thanks for the reply.
I answer all your questions below but, first, the best clue that I
could find in the amdump file causing the problem is the following:
PROMOTING DUMPS IF NEEDED, total_lev0 0, balanced_size 3465982...
promote:
-In response to your message-
--received from John R. Jackson--
.
.
.
Are you going to reuse the old tapes or start over? If you use the
old tapes, they have the old labels and Amanda will refuse them if you
change labelstr to the new name.
My current plan is to not reuse tapes. Writing
Hi, I have some interest in changing names of a much used configuration
but don't want to screw myself over here. I figure the code will need
to be recompiled for the new name, the reports directory will have to
be renamed and the appropriate changes will need to be made in
amanda.conf (such as
Hi and thanks for the help.
--From John R. Jackson--
I'm not sure that's what's going on. Note the following:
driver-idle: no-diskspace
As far as I can tell from the code, Amanda will run everything it can
before those with a delay (but see below). The problem is, the best
client
Hi, I'm trying to do what Mark Chang started a thread concerning March
6th: back up a laptop that's only available during the day with a host of
computers that are preferentially backed up at night. Jan Edler jumped
in on the topic, too. Seems to be somewhat a problem and one that
isn't easily
Hi, if multiple tapes are needed to complete all the disks in
one's disklist, is taper: FATAL syncpipe_get: w: unexpected EOF
on all but the last tape expected? Or does this imply an incorrect
tapetype setting?
--
Paul Yeatman (858) 534-9896[EMAIL PROTECTED]
Hi,
am I pitching Amanda a curve ball by deleting one of the dated
directories from the holding disk? One night's backups went to
the holding disk. The next night's went to tape
without flushing the previous night's. This second backup was identical in
dump levels to the backups on disk.
Thanks, everyone. I'll take what I believe to be the general
consensus of writing all but the backup in question to tape yet
setting this backup aside to be safe. Thanks for all
the input.
Paul
-In response to your message-
--received from David Lloyd--
You could just rm -rf them but
--received from Chris Karakas--
That the dumpcycle is 12 weeks does not mean that in an interval of 12
weeks AMANDA will have to do *exactly one* full backup of your disk, but
that she will have to do *at least one*. In your case, she "promoted"
the disk. You should have got a note from
Hi,
The backup for one of my disks in my configuration jumps back to a
level 0 dump every few days. The others hold and advance levels as
expected even another disk on the same host. Yet the backup of
this one disk will only go a few days before unpredictably jumping
back to level 0 and
Hi,
The tapes for one of my configurations seems to expire tapes and then .
. . decide they are active again. If I grep for the label string of the
tapes in this config on the mail folder with saved amanda reports (I
intentional force several nights' backups to disk by not loading a tape):
My uncertainty is whether this partial, interupted level 0 backup
on a removed tape will have any effect on future incremental backups of
this disk.
I wouldn't think so. The database only gets updated after dumper
completes. Do an "amadmin config info host disk" and I'll bet
it's all
Hi,
anyone have an interpretation of this:
"planner: isengard:/isen1/iraf mismatch: no tapelist record, but
curinfo next_level0: 59."
seems to have run ok but . . . doesn't seem like a nice message.
--
Paul Yeatman(858) 534-9896 [EMAIL PROTECTED]
I didn't poke around real hard, but it seems like Amanda tried to look
up the tape label listed in the curinfo database for the last backup
and didn't find it in your tapelist file (which might be because of the
amrmtape you did yesterday) and it notices that it's going to be a while
before
Hi,
I forced a level 0 on a few disks today and began to back them
up to tape. When I realized that one of them, a large one, had
received a level 0 backup only a few days ago and that Amanda was
dumping that one to tape at the moment, I Ctrl C'd the amdump and
amrmtape'd the tape (I won't bore
Hi,
Which version of GNU tar are you using? You **must** use either 1.12 and
apply the patches in the Amanda distribution (or on the web page), or get
the latest version (1.13.17?) from alpha.gnu.org. If you have an earlier
version of 1.13, it's almost for certain broken in one way or
Well, thanks for the inputs on this.
I can gladly report that when I go to the trouble of
restoring two subdirectories of the directory I tarred with Amanda
( each about half a gig ) to a temporary location, a 'du -sk' reports
the exact same size for the original and restored subdirectories.
Hi,
(Is there a limit to how many questions you can post in a week?
I've had my share of problems lately.)
I have some disks on some Sun systems that are larger than the
capacity of the dds3 tapes I'm using for backups with Amanda.
This has caused me to compile GNUtar on the Sun machines and
(Is there a limit to how many questions you can post in a week?
No. :-) :-)
Good. Thanks :)
Which version of GNU tar are you using? You **must** use either 1.12 and
apply the patches in the Amanda distribution (or on the web page), or get
the latest version (1.13.17?) from
25 matches
Mail list logo
