i guess your next step would be the more detailed logs. How about
reviewing the 'amdump.[0-9]' files in the 'logdir' directory defined in
amanda.conf ?
[EMAIL PROTECTED] wrote:
>
> Thanks for your reply...
>
> However, the Ecrix V17 tapesize is set to 35000 mbytes and...
>
>
will amanda tape out the data that cant fit onto that 40gig tape and
then onto the next tape OR will it start over again from the beginning (
as the docs currently say ) and try to fit something that will never fit
onto that tape?. If docs are correct, why does amanda bother bother
attempting to w
Gee fella's, i didnt mean this to be a slam fest ( or was that a 'dis
fest ).
I just think, particularly on this list, that there are caveats out
there AND FOLKS ON THIS LIST would be the best ones to know about such
things. There is one for dump on linux, and it appears that there might
be othe
Sorry, thats a general conclusion to most things in life.
Is there a situation(s) where DUMP can fail. If yes, why are there no
warning labels ( ie the probability of failure is 1 in 1billion ). If
NO, than can I see the proof that absolutely refutes Mr. Torvolds
statement.
/gat
Its interesting
does this mean that there was a definitive conclusion?
Christoph Scheeder wrote:
>
> Please not again this discussion...
Ya, but didnt someone post that "DUMP" on linux can fail - if the
conditions are right? I think is was suggested that SMP systems can
demonstrate the failure sooner.
I think that Mr. Torvolds ( sorry is i mis-spelled) made that comment or
conclusion.
Are there some caveats that need to be added
Jens Rohde wrote:
>
> Hi
>
I suppose that the disk/fs that will/might be restored to, that is to be
recognized by SUN, will be done on a machine that can create the
(unofficial) sun partition correctly?
> I'm changing the dump-method on some of my filesystems from ufsdump to
> gtar (so I can re
I presume u are using tar?!
From My experience, 17gigs of a (few) large files does not take a long
time.
On the other hand, backing up a large amount of files in a (single)
directory takes a long time. The orig tar that came with this (linux)
sys readily reached 80% cpu usage. The later tar fixed
u probably want to back it up with tar - i suppose. There is not enough
info, but i could guess ur using dump.
/gat
Tom Beer wrote:
>
> Hi,
>
> I want to back a dos partition
> on a dual boot machine. I mount
> this parition /mnt/dos and the disklist
> entry is
>
> vaio.system ad0s
I think u are looking for the "OFFLINE_BEFORE_UNLOAD=1" setting in
chg-zd-mtx
Nate DeLong wrote:
>
>
> Ok. It wasn't until I went to BRU's website that I found the following
> command (that worked):
>
> # mt -f /dev/nst0 offline
>
> Then I can finish up by issuing a " mtx -f /dev/sga unload 1
with a dtimeout of 1800 ( seconds, or 30 min ) the 'sendbackup' of
/mnt/hdg3 fails with a data timeout.
The Client side gets a:
=
ckup: argument list: gtar --create --file - --directory /mnt/hdg3
--one-file-system --listed-incremental
/usr/local/var/amand
i guess your next step would be the more detailed logs. How about
reviewing the 'amdump.[0-9]' files in the 'logdir' directory defined in
amanda.conf ?
[EMAIL PROTECTED] wrote:
>
> Thanks for your reply...
>
> However, the Ecrix V17 tapesize is set to 35000 mbytes and...
>
>
i suppose this will do it:
> planner: Dump too big for tape: full dump of solo.americom.com:/ delayed.
> planner: Dump too big for tape: full dump of gorn.americom.com:/ delayed.
a single backup point must be able to fit onto one tape. So if your tape
is 4gig, but your partition is 6 gig, th
There are still some bug-a-boo's.
non-amanda tape in slot 5, and loaded in tape drive.
no tape in slot 6. There is an amanda tape in slot 7
issue an amcheck confname
get
--
[Amanda@kodak Amanda]$ amtape confname slot 5
amtape: change
Interesting, the log file shows that offline_before_unload is set to "0"
:-{
Storage Element 5:Full
Storage Element 6:Empty
Storage Element 7:Full
12:18:14 SLOTLIST -> firstslot set to 1
12:18:14 SLOTLIST -> lastslot set to 7
12:18:14 SLOTLIST -> 1 2 3 4 5 6 7
12:18:15 Config i
This is far short of a million, even if its binary, questions!
actually plugged it in, and linked it to ...sh.in
rebuilt it ( make, not configure ) , but no install. Just cp'd the
chg-zd-mtx to /usr/local/libexec. I know its there bec the old version
is ~17k, and newer one is ~37k
it does not wo
It appears that the offline_before_unload switch/feature does not work
in this script! Am i :-/
/gat
"John R. Jackson" wrote:
>
> I think the following patch fixes that version. Also, there is a new
> copy of the whole thing at:
>
> ftp://gandalf.cc.purdue.edu/pub/amanda/chg-zd-mtx.sh.in-2
DLT's are not flying head technology. They are like 9trk, QIC, i think
travan, colorado. The heads do not spin ( i had to think about it ), as
the heads move up & down to change tracks. But the DLT 8000, now, also
place the heads at an angle to tape direction, as well as going up and
down. I dont
Problem with this is obtaining a definitive PROOF.
you do the amanda process, and you notice that the tape is not spinning,
even though you are in the sendbackup phase. You notice that the
ethernet switch is not blinking. You can also notice the task(s) that
are running. You also notice that the
Its sorta like when you go to your kar mechanic. The job is not complete
till you put all of your tools away, and cleaned your work area for the
next job. That would be the mechanics responsibility, and not the
cleaning staff that follows in the evening.
But at this moment, some 18hours after ama
according to the tar docs, the --listed-incremental will check on the
files listed in the file if the incremental file is not empty. I suppose
the listed-incremental file got filled during the sendsize proceedure?!
During the sendbackup step, tar is apparently going through and checking
the list
'dont do that'.
Jay Lessert wrote:
>
> On Wed, Apr 03, 2002 at 08:58:29AM -0500, Uncle George wrote:
> > Guess I'm from old school. Older 9trk drives when left on, continually
> > have the vacuum on, and under constant tension. Its not healthy for the
> >
Jay Lessert wrote:
>
> On Wed, Apr 03, 2002 at 06:19:19AM -0500, Uncle George wrote:
> > It seems like when the whole procedure ( whether its labeling tape(s),
> > amchecking tape, or amdumping ) is complete, the tape is left in the
> > tape drive in an on-line state.
Maybe they can OPT-OUT of the feature, but on a busy site, allowing the
customers to access the tape drives, would appear to make good business
sense. Particularily when the drives are doing just nothing.
/gat
btw, what do u mean each operation. Each run? If funny things happen,
maybe they should
Guess I'm from old school. Older 9trk drives when left on, continually
have the vacuum on, and under constant tension. Its not healthy for the
tape. Does that happen with a DLT tape, how about the DDS tapes.
I would NOT like a "live" tape to be left in the drive for long periods
of time. Who know
I dunno either, will it work on a 6 drive auto changer/tape library?
/gat
> Dunno,
> my crontab sez:
> 0 18 * * 1-5 /volume/amanda/sbin/amdump lto; mt -f /dev/rmt/3h rewoffl
>
> works like a charm.
>
>
It seems like when the whole procedure ( whether its labeling tape(s),
amchecking tape, or amdumping ) is complete, the tape is left in the
tape drive in an on-line state.
Is there some reason why the tape is not at least rewind-offlined, or
for tape changer folks rewoffl/unload'ed back to the ca
technically yes. A DLT-IV tape is the tape of choice on a quantum 7000,
and quantum 8000. I do not know, however, if the tape that was written
with a 7000 series, and later re-used on an 8000 if it would be reliable
. I suspect that it should work.
But for a definitive answer, give www.quantum.co
I put 3 tapes in ( from a previous run ) with wrong labels ( ie they
look like they are correct but they are not )
What is interesting is that the autochanger goes through tape 1, 2, 3,
1, 2, 3, 1 looking for a label. Slots 1, 2, 3 have tapes. Slots 4, 5 ,
6 , 7 do not have any tapes. changer is
runtapes set to 7
INITIAL SCHEDULE (size 94289500):
lx /mnt/hde4 pri 1 lev 0 size 69069340
lx /mnt/hdg3 pri 1 lev 0 size 6060890
lx /mnt/hdg2 pri 1 lev 0 size 5286010
lx /mnt/hdg4 pri 1 lev 0 size 5186500
lx /mnt/sdb2 pri 1 lev 0 size 4156550
lx / pri 1 lev 0 size 1962280
lx /mnt/sd
Hummm, DLT tape set to 3mb ( 2 + .5 compression )
partition on /mnt/hde4 is 69578056k ( via df ) /mnt/hde4 'sendsizes' to
70727004160 ( 66GB, 4.6MB/s )
at 5am it tried to fit the (/mnt/hde4) partition onto the tail end of
the tape & EOT'd. At 8:30 it tried again onto the next tape. At 9a
will amanda tape out the data that cant fit onto that 40gig tape and
then onto the next tape OR will it start over again from the beginning (
as the docs currently say ) and try to fit something that will never fit
onto that tape?. If docs are correct, why does amanda bother bother
attempting to w
Generally, u try the program. After a week of fustration, maybe then you
think that you should have RTFM first. But so far neither method is
doing me tooo mcchhh ggg. One might
say that I can tar out the 69gb much faster with a simpler tar.
Eventually i will fin
thats interesting, considering that i have "dumpcycle 0 " and "dumpcycle
0" in dumptype global.
Is there a way to stop the second scan, third, 4th, and so on ?
"John R. Jackson" wrote:
>
> >I waited 4 hours for /mnt/hde4 to complete the first run of sendsize.
> >When it completes it appears to r
I waited 4 hours for /mnt/hde4 to complete the first run of sendsize.
When it completes it appears to run the sendsize again on /mnt/hde4.
This would take another 4 hours, and i'm wondering why?
tar is 1.13.19
btw the "lx_mnt_hde4_0.new" does exist, but not just plain
"lx_mnt_hde4_0"
sendsize: ge
shouldn';t the comment "DLT4000 tape drives with Compact-IV tapes" be
placed after the DLT4000-III tapetype ?
define tapetype DLT4000-III {
comment "DLT4000 tape drives with Compact-III tapes"
length 12500 mbytes # 10 Gig tapes with some
There is no tape in slot 6, so I suppose ANY other tape would do .
I suppose this is a bug.
[Amanda@kodak sbin]$ for i in 6; do ./amlabel -f confname
GatWorksSet16$i slot $i; done
labeling tape in slot 1 (/dev/nst0):
rewinding, reading label GatWorksSet161, tape is active
rewinding, writing lab
Sorry, for every NEW run, i would like a set of new logs just for that
run just so that i know are from just that run. from my 'novice' eyes,
its just to much data to figure out where the previous run completed,
and the new one began.
But if i ( ever ) get a complete backup ( after setting it for
Then my current impression is that the feature does not work - exactly
as stated. There are a few file systems on one 'errant' system, where
one filesystem has taken over 224 minuts( wall time ) to complete just
the estimate. I had changed the time to be some 3600 ( an hour ) which,
if one beleiv
does etimeout specify the time that "sendsize" will use to estimate the
time needed to do 'its thing', or does it represent the sum total of
time ( estimate & dumping ) of a filesystem ?
--- Begin Message ---
apparently it did not complete all filesystems.
some appear to be network reliability problems. ( host reset by peer )
some appear to be that the server run out of time [ data timeout ]
some appear to be because is cant open a jibberish filename !.
are there things i can
41 matches
Mail list logo
