l be enforced, limiting the total size
of the
volume. This property is not available on all devices; see
below.
Set the ENFORCE_MAX_VOLUME_USAGE
The tapetype length is use in the estimate phase, so it must be the same
as the MAX_VOLUME_USAGE.
Jean-Louis
On 10/25/2013 09:50 AM, John G. H
e in the estimate phase, so it must be the
same
as the MAX_VOLUME_USAGE.
Jean-Louis
On 10/25/2013 09:50 AM, John G. Heim wrote:
Last week I asked a few questions about virtual tape size. Well, I
wouldn't say I resolved them but I think I have one clue. One of
the
things I asked about is the me
volume. This property is not available on all
devices; see
below.
Set the ENFORCE_MAX_VOLUME_USAGE
The tapetype length is use in the estimate phase, so it must be the
same
as the MAX_VOLUME_USAGE.
Jean-Louis
On 10/25/2013 09:50 AM, John G. Heim wrote:
Last week I asked a few q
y is not available on all devices; see
below.
Set the ENFORCE_MAX_VOLUME_USAGE
The tapetype length is use in the estimate phase, so it must be the
same
as the MAX_VOLUME_USAGE.
Jean-Louis
On 10/25/2013 09:50 AM, John G. Heim wrote:
Last week I asked a few questions about virtual tape size. Wel
e phase, so it must be the
same
as the MAX_VOLUME_USAGE.
Jean-Louis
On 10/25/2013 09:50 AM, John G. Heim wrote:
Last week I asked a few questions about virtual tape size. Well, I
wouldn't say I resolved them but I think I have one clue. One of the
things I asked about is the meaning of
uis
On 10/25/2013 09:50 AM, John G. Heim wrote:
Last week I asked a few questions about virtual tape size. Well, I
wouldn't say I resolved them but I think I have one clue. One of the
things I asked about is the meaning of the "length" parameter for a
tape definition. I had set
is property is not available on all devices; see
below.
Set the ENFORCE_MAX_VOLUME_USAGE
The tapetype length is use in the estimate phase, so it must be the same
as the MAX_VOLUME_USAGE.
Jean-Louis
On 10/25/2013 09:50 AM, John G. Heim wrote:
Last week I asked a few questions about virtual tape
volume. This property is not available on all devices; see
below.
Set the ENFORCE_MAX_VOLUME_USAGE
The tapetype length is use in the estimate phase, so it must be the same
as the MAX_VOLUME_USAGE.
Jean-Louis
On 10/25/2013 09:50 AM, John G. Heim wrote:
Last week I asked a few questions about virt
SAGE
The tapetype length is use in the estimate phase, so it must be the same
as the MAX_VOLUME_USAGE.
Jean-Louis
On 10/25/2013 09:50 AM, John G. Heim wrote:
Last week I asked a few questions about virtual tape size. Well, I
wouldn't say I resolved them but I think I have one clue. One
spect that in the case of vtapes, amanda will finish writing
the current DLE even if it crosses the size boundry, but that it
will not write additional DLEs to tape above the set tape size limit.
hum, not seeing what I'm looking for. My vtapes do fill though.
On Fri, Oct 25, 2013 at 08:50:28AM -
Last week I asked a few questions about virtual tape size. Well, I
wouldn't say I resolved them but I think I have one clue. One of the
things I asked about is the meaning of the "length" parameter for a tape
definition. I had set it to 25G for my virtual tapes but amanda was
hanger broke so long ago I'm not sure. IIRC, most days it was
> around 50%. But we were doing backups just twice a week, Mondays and
> Thursdays. We sent the thing out to be repaired twice and it always
> worked for a week or two and then broke again. It's out of warran
wiki.zmanda.com/index.php/How_To:Set_Up_Virtual_Tapes.
>
> The example tapetype definition on the wiki has a tape size of just 3Gb.
> But the real tapes I'm using have a capacity of 100Gb uncompressed and
> 500Gb compressed. That is such a huge disparity that I am uncertain as
> to how to pro
I am trying to replace a physical tape changer with a virtual tape
changer on NFS mounted hard disk. I started with the virtual tape
configuration on the amanda wiki at
http://wiki.zmanda.com/index.php/How_To:Set_Up_Virtual_Tapes.
The example tapetype definition on the wiki has a tape size
I only do HW compression. I tried the software compression once before and
it was excruciating slow. I have a newer tape server with many more cores
so maybe I should give SW compression another try.The big question is how
much better is the SW compression than the HW compression? What do I gain.
On Fri, May 24, 2013 at 07:24:01AM +0300, Toomas Aas wrote:
> Hello!
>
> On Thu, 23 May 2013 "McGraw, Robert P" wrote:
>
> >
> >I use hardware compression to max the size of the tape.
> >Uncompressed the tape is 800GB compressed the theoretical max size
> >is 1.6TB. I know that I will not get the
Hello!
On Thu, 23 May 2013 "McGraw, Robert P" wrote:
I use hardware compression to max the size of the tape. Uncompressed
the tape is 800GB compressed the theoretical max size is 1.6TB. I
know that I will not get the 1.6TB.
In the amanda.conf file I tell amanda that my tape is "length 1
Robert,
On Thu, May 23, 2013 at 10:04:29AM -0600, Charles Curley wrote:
> On Thu, 23 May 2013 13:59:33 +
> "McGraw, Robert P" wrote:
>
> > Why does amanda stop at %52 when I still have 1.5TB of data in the
> > holding disk to write to the tape? It is hard to believe that the
> > LTO4 compr
On Thu, 23 May 2013 13:59:33 +
"McGraw, Robert P" wrote:
> Why does amanda stop at %52 when I still have 1.5TB of data in the
> holding disk to write to the tape? It is hard to believe that the
> LTO4 compression is so bad that I am not getting any compression at
> all.
It would be if you h
On Thu, May 23, 2013 at 01:59:33PM +, McGraw, Robert P wrote:
> Amanda Server Info:
>
> Thu May 23 05:36:00 2013: amandad: build: VERSION="Amanda-3.2.3"
> Thu May 23 05:36:00 2013: amandad:BUILT_DATE="Tue Feb 5 17:10:59
> EST 2013" BUILT_MACH=""
> Thu May 23 05:36:00 2013: ama
Robert,
Do amanda report a tape error?
What it doesn't put on tape? dump from the current run or from previous run?
You give us nothing to look at it, can you post the amdump.? log file?.
Jean-Louis
On 05/23/2013 09:59 AM, McGraw, Robert P wrote:
Amanda Server Info:
Thu May 23 05:36:00 2013:
Amanda Server Info:
Thu May 23 05:36:00 2013: amandad: build: VERSION="Amanda-3.2.3"
Thu May 23 05:36:00 2013: amandad:BUILT_DATE="Tue Feb 5 17:10:59
EST 2013" BUILT_MACH=""
Thu May 23 05:36:00 2013: amandad:BUILT_REV="3994"
BUILT_BRANCH="3_2_3"
Thu May 23 05:36:00 20
messages from cron about the planner segfaulting. I culled some
items from my disklist, and all of a sudden it starting working
again. After a little experimenting, I've come to the conclusion
that it's happening whenever a backup estimate generates a backup
size that's big
On Tue, Apr 22, 2008 at 9:55 PM, Telsin <[EMAIL PROTECTED]> wrote:
> Anyone else seen this or have a fix? I havn't had a chance to look into the
> source yet, figured I'd ask here before I started poking around at something
> I wasn't familiar with :)
I haven't heard boo about it. I'll see if I
ng. I culled some items
from my disklist, and all of a sudden it starting working again. After
a little experimenting, I've come to the conclusion that it's
happening whenever a backup estimate generates a backup size that's
bigger than the current tape size. The debug logs don&#x
ittle experimenting, I've come to the conclusion that it's
happening whenever a backup estimate generates a backup size that's
bigger than the current tape size. The debug logs don't help, they
just end after closing a connection for an estimate. I do not
currently have tape s
On Jan 14, 2008 3:09 PM, Jeremy Mordkoff <[EMAIL PROTECTED]> wrote:
> I would like to set the tape size parameter each night to the space
> remaining on my USB-drive. Is there a way to do this besides editing the
> Amanda.conf file?
I *think* it would also work to call amdum
I would like to set the tape size parameter each night to the space
remaining on my USB-drive. Is there a way to do this besides editing the
Amanda.conf file?
I suppose I could create a small file that was included by the main
file, but I was wondering if there was an official way.
Any
ginal Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alexander Jolk
Sent: Tuesday, 25 October 2005 3:29 a.m.
To: Lloyd Weehuizen
Cc: amanda-users@amanda.org
Subject: Re: Tape size problem
Lloyd Weehuizen wrote:
> I have been using Amanda to automate backups to a Ultri
Lloyd Weehuizen wrote:
I have been using Amanda to automate backups to a Ultrium LTO 2 device
for about a year now. Up until now there have been no issues and the
backups were easily fitting on the tapes. However lately the datasize is
going above 100Gig and for some reason Amanda is reporting it
I have been using Amanda to automate backups to a Ultrium LTO 2 device
for about a year now. Up until now there have been no issues and the
backups were easily fitting on the tapes. However lately the datasize is
going above 100Gig and for some reason Amanda is reporting it has
reached the end of
Toralf Lund wrote:
I've been meaning to ask about this for a long time:
Does anyone here use AIT2 tapes, a.k.a. SDX-50C, for Amanda backup?
What tape length are you using? [ ... ]
I've now finally run amtape - after making absolutely sure H/W
compression was off - and it said:
-sh-2.05b$
[ ... ]
(*) I used to say "on all linux versions", but it seems there
are different implementations in different versions.
Some systems can control the tapesettings with the file
/etc/stinit.def (see "man stinit" if that exists).
Yes. I think maybe you can do something like that on this
Paul Bijnens wrote:
Toralf Lund wrote:
Paul Bijnens wrote:
amtapetype will tell you too if hardware compression is on.
OK.
Does amanda have any built-in support for switching it off? I mean,
can any of the changer scripts or whatever do this? Or even amdump
itself?
No. Controlling
apes"
length 43778 mbytes
filemark 3120 kbytes
speed 5371 kps
}
This has proven pretty accurate.
> Please note that I'm not asking for the tapetype entry from the
> amanda.org archives, as it does not seem quite correct. I mean, the tape
> size is specified as 50Gb,
Toralf Lund wrote:
Paul Bijnens wrote:
amtapetype will tell you too if hardware compression is on.
OK.
Does amanda have any built-in support for switching it off? I mean, can
any of the changer scripts or whatever do this? Or even amdump itself?
No. Controlling hardware compression is a
On Thu, 18 Aug 2005 at 3:26pm, Paul Bijnens wrote
> Toralf Lund wrote:
> > Ah, yes, of course. No, hardware compression is not supposed to be on.
> > But I'm not sure it isn't... In fact, now that to mention it, I suspect
> > it's on after all. I'll a have a closer look. And I very much doubt th
Paul Bijnens wrote:
Toralf Lund wrote:
Ah, yes, of course. No, hardware compression is not supposed to be
on. But I'm not sure it isn't... In fact, now that to mention it, I
suspect it's on after all. I'll a have a closer look. And I very much
doubt that the drive will auto-detect compressed
Toralf Lund wrote:
Ah, yes, of course. No, hardware compression is not supposed to be on.
But I'm not sure it isn't... In fact, now that to mention it, I suspect
it's on after all. I'll a have a closer look. And I very much doubt that
the drive will auto-detect compressed data.
amtapetype wil
does not seem quite correct. I mean, the tape
> size is specified as 50Gb, and that's more or less what the "length"
> parameter in entry says, but it seems to me that it isn't actually
> possible to write that much data to these tapes. The maximum seems to be
>
Toralf Lund wrote:
Does anyone here use AIT2 tapes, a.k.a. SDX-50C, for Amanda backup?
What tape length are you using?
This is the tapetype entry we use in our amanda.conf:
# christian found this definition on the internet
# @ http://www.sun.com/bigadmin/features/articles/backups_amanda.htm
Alexander Jolk wrote:
Toralf Lund wrote:
the tape size is specified as 50Gb, and that's more or less what the
"length" parameter in entry says, but it seems to me that it isn't
actually possible to write that much data to these tapes. The maximum
seems to be clos
Toralf Lund wrote:
the tape
size is specified as 50Gb, and that's more or less what the "length"
parameter in entry says, but it seems to me that it isn't actually
possible to write that much data to these tapes. The maximum seems to be
closer to 40Gb, actually.
That
I've been meaning to ask about this for a long time:
Does anyone here use AIT2 tapes, a.k.a. SDX-50C, for Amanda backup? What
tape length are you using?
Please note that I'm not asking for the tapetype entry from the
amanda.org archives, as it does not seem quite correct. I mean
On Tuesday 18 January 2005 04:25, Peter Guhl wrote:
>Hi
>
>On Mon, 2005-01-17 at 17:09, Gene Heskett wrote:
>> Is that tape being properly rewound Peter? Most drives will fully
>> rewind a tape before they allow it to be ejected, maybe you should
>> eject it and look at it between each pass.
>
>It
Hi
On Tue, 2005-01-18 at 10:58, Michael Loftis wrote:
> Dumb question, maybe already asked,
No ;)
> 1) is any other app using the tape and
No.
> 2) has anyone checked to make sure the mechanism isn't jamming since you're
> not there to watch it at all.
The customer did change tapes, insert
--On Tuesday, January 18, 2005 10:25 +0100 Peter Guhl <[EMAIL PROTECTED]>
wrote:
Hi
On Mon, 2005-01-17 at 17:09, Gene Heskett wrote:
Is that tape being properly rewound Peter? Most drives will fully
rewind a tape before they allow it to be ejected, maybe you should
eject it and look at it betwe
Hi
On Mon, 2005-01-17 at 17:09, Gene Heskett wrote:
> Is that tape being properly rewound Peter? Most drives will fully
> rewind a tape before they allow it to be ejected, maybe you should
> eject it and look at it between each pass.
It's probably not rewound, you're right. Eject and look at
On Monday 17 January 2005 07:45, Peter Guhl wrote:
>Hi Paul
>
>On Mon, 2005-01-17 at 12:38, Paul Bijnens wrote:
>> But you can do just the same using dd:
>>
>> dd if=/dev/random of=/dev/st0 bs=32k
>>
>> and count how many 32Kbyte blocks get on the tape.
>> Expect about 150 / 32768 or ab
On Monday 17 January 2005 05:38, Peter Guhl wrote:
>Hi
>
>On Mon, 2005-01-17 at 10:27, Paul Bijnens wrote:
>> To prove hardware problems, use a fresh tape, and do a
>> "amtapetype -e 20g -f /dev/..." (takes about 4-5 hours!) and
>> verify
>
>Hmm, looks like there's no amtapetype around...
> amanda-
Peter Guhl wrote:
root@:/usr/local/etc/amanda/backup> dd if=/dev/urandom of=/dev/nrsa0 bs=32k
dd: /dev/nrsa0: short write on tape device
1301+0 records in
1300+1 records out
42598476 bytes transferred in 13.372441 secs (3185542 bytes/sec)
root@:/usr/local/etc/amanda/backup> dd if=/dev/urandom of=/d
Hi Paul
On Mon, 2005-01-17 at 12:38, Paul Bijnens wrote:
> But you can do just the same using dd:
>
> dd if=/dev/random of=/dev/st0 bs=32k
>
> and count how many 32Kbyte blocks get on the tape.
> Expect about 150 / 32768 or about 457763 blocks.
>
> Remember, it takes about 2-3 hours
Peter Guhl wrote:
Hi
On Mon, 2005-01-17 at 10:27, Paul Bijnens wrote:
To prove hardware problems, use a fresh tape, and do a
"amtapetype -e 20g -f /dev/..." (takes about 4-5 hours!) and verify
Hmm, looks like there's no amtapetype around... amanda-server-2.4.3,1
Too old or just not in that particu
Peter Guhl wrote:
Well, I did just look what was left on the holding disk after the backup
process ended (using "du"). It was between 0.5 and 2 GB. Since the tape
can hold at least 15GB uncompressed at least "amflush" to a completely
new tape can't possibly fill it.
Fine. At least if that is the o
Hi
On Mon, 2005-01-17 at 10:27, Paul Bijnens wrote:
> To prove hardware problems, use a fresh tape, and do a
> "amtapetype -e 20g -f /dev/..." (takes about 4-5 hours!) and verify
Hmm, looks like there's no amtapetype around... amanda-server-2.4.3,1
Too old or just not in that particular port?
Re
On Mon, 2005-01-17 at 10:30, Paul Bijnens wrote:
> Peter Guhl wrote:
> >
> > I still have my "short write"-Problem. The weekly backup fails and every
> > amflush fails too - even though the tape (DLT) is 10 times bigger than
> > any data left on the holding disk.
>
> One more thing. What number
Peter Guhl wrote:
I still have my "short write"-Problem. The weekly backup fails and every
amflush fails too - even though the tape (DLT) is 10 times bigger than
any data left on the holding disk.
One more thing. What number in the report makes you believe the tape
is 10 times bigger than data on
Peter Guhl wrote:
I still have my "short write"-Problem. The weekly backup fails and every
amflush fails too - even though the tape (DLT) is 10 times bigger than
any data left on the holding disk.
"Short write" means that there was a permanent error writing to tape.
Most (all?) tapedrives detect "e
Hello
I still have my "short write"-Problem. The weekly backup fails and every
amflush fails too - even though the tape (DLT) is 10 times bigger than
any data left on the holding disk.
Does somebody have any clue? We tried all sorts of software tests using
amcheck, mt etc. without any result. Som
On Tuesday 17 August 2004 09:19, Mark Wormgoor wrote:
>Hi,
>
>I have recently switched to Amanda for making my backups (yes, that
>means I'm new to Amanda). I have several small (/etc, /var/lib/rpm,
>/var/spool/mail) directories to backup and one large directory
> (/home). I would like to back the
On Tue, 17 Aug 2004, Mark Wormgoor wrote:
> I have recently switched to Amanda for making my backups (yes, that
> means I'm new to Amanda). I have several small (/etc, /var/lib/rpm,
> /var/spool/mail) directories to backup and one large directory (/home).
> I would like to back these up to disk.
Hi,
I have recently switched to Amanda for making my backups (yes, that
means I'm new to Amanda). I have several small (/etc, /var/lib/rpm,
/var/spool/mail) directories to backup and one large directory (/home).
I would like to back these up to disk. I have followed the HOWTO and
all is working
I am trying to break up a 60 GB partition into chunks that will fit on 32 GB
(native) AIT-1 tapes. I am using a Sony AIT i90-a tape drive on a Linux 9
system. The big partition is on a remote client named "hsadm2". The
following lines show the output running amcheck on the "hsadm2"
configuration
[sorry about that half-a-reply, folks; clumsy fingers...]
On Fri, Mar 26, 2004 at 04:04:05PM +0100, BRINER Cedric wrote:
> + These dumps were to tape WeeklySet076.
> + *** A TAPE ERROR OCCURRED: [[writing file: short write]].
>
> so the tape have for example 45Gb already on it, when it tries
On Fri, Mar 26, 2004 at 04:04:05PM +0100, BRINER Cedric wrote:
> the tapes are 70Gb
Is that 70 GB native, or with hardware compression taken into
account? (If the latter, it can only be approximate; depends how
compressible the data is.)
Do you in fact have hardware compression enabled? (See th
hi,
I'm having problem with amanda when it backups big partition compared to
what a tape can contain.
the tapes are 70Gb
and some dumps are about 30Gb
I've set the autoflush to yes.
Some times a get :
+ These dumps were to tape WeeklySet076.
+ *** A TAPE ERROR OCCURRED: [[writing file: shor
On Monday 07 July 2003 18:16, Joshua D. Bello wrote:
>Thank you to everybody for their help and suggestions. I went ahead
> and disabled hardware compression on my drive.
>
>Unfortunately, I am running into further problems in my attempts to
>clear out the previously spooled dumps with amflush. a
On Mon, Jul 07, 2003 at 03:16:33PM -0700, Joshua D. Bello wrote:
> I get the same results, whether I pick A, B, or ALL. The amflush report
> looks like:
>
> STATISTICS:
>
>
> "--">
It would be useful if you could post the *full* versions of:
- the amflush mail report
- log file
- amflus
Thank you to everybody for their help and suggestions. I went ahead and
disabled hardware compression on my drive.
Unfortunately, I am running into further problems in my attempts to
clear out the previously spooled dumps with amflush. amflush fails
after a short time without writing anything at
On Monday 07 July 2003 13:26, Joshua D. Bello wrote:
>I am currently experiencing problems with Amanda backup runs
> completing successfully, supposedly due to running out of tape. I
> am using Amanda 2.4.3 on a FreeBSD 4.8-STABLE machine, backing up
> to 35/70GB DLT 7000 drive. Compression is en
On Mon, 7 Jul 2003 at 10:26am, Joshua D. Bello wrote
> I am currently experiencing problems with Amanda backup runs completing
> successfully, supposedly due to running out of tape. I am using
> Amanda 2.4.3 on a FreeBSD 4.8-STABLE machine, backing up to 35/70GB
> DLT 7000 drive. Compression is
I am currently experiencing problems with Amanda backup runs completing
successfully, supposedly due to running out of tape. I am using
Amanda 2.4.3 on a FreeBSD 4.8-STABLE machine, backing up to 35/70GB
DLT 7000 drive. Compression is enabled on the drive, and we are also
using compression within
On Monday 16 December 2002 17:44, Sykora, Dale wrote:
>Hello,
> I am new to amanda and want to determine if fits my needs. Any
> pointers are appreciated. Will backup_size>tape_size work? Old
> backup routine... Weekly full backup on Fri and incremental
> Mon-Thu. Full~=20Gb"2tapes" and i
At 04:44 PM 12/16/2002 -0600, Sykora, Dale wrote:
Hello,
I am new to amanda and want to determine if fits my needs. Any
pointers are appreciated. Will backup_size>tape_size work? Old backup
routine... Weekly full backup on Fri and incremental
Mon-Thu. Full~=20Gb"2tapes" and inc~=1Gb
Hello,
I am new to amanda and want to determine if fits my needs. Any pointers are
appreciated. Will backup_size>tape_size work? Old backup routine... Weekly full
backup on Fri and incremental Mon-Thu. Full~=20Gb"2tapes" and inc~=1Gb. Tape drive
is dds3/12Gb. I read that amanda can
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
I have a VXA tape and a 2GB removable disk.
I was wondering if it was possible to have Amanda do full backups using
the VXA tapes and incrementals using the small disks with the new file
tapeio of 2.4.3b3. Would it be that I
just do two different runs - say a daily incremental cron for the disk
OK, I was able to reproduce your problem on a 2.4.2p2 build.
The following patch seems to take care of it. Let me know how it goes.
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
planner-tape-length.diff
Description: planner-tape-length.diff
>runtapes set to 7
>...
>DELAYING DUMPS IF NEEDED, total_size 94289500, tape length 21504
>mark 2000
> delay: Total size now 94289500.
Thanks. That's just what I needed. I'm pretty sure I see where the
problem is.
I've forgotten. What version of Amanda are you using (so I can generate
an
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 )
>...
>i guess i should ask why I didnt get any of these errors?
Don't know without more information.
Take a look at the amdump. fil
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 ) ...
If Amanda hits any tape error (including EOT) it will start the current
image over, from the beginning, on the next tape
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
Hello all,
I am trying to implement Amanda on an AIX box with 7337 tape unit. I haven't even
started the chg-scsi part yet.. which I think is going to be difficult. Right now I am
trying to get Amanda recognize my DLT tape size as 35GB instead of 14 GB? Here is my
configurati
>I presume "Tape Size" means amount of tape used, rather than size of
>the whole tape. ...
Correct.
>I am having 5 out of 23 partitions fail to get to tape and 4 of those 5
>complain about lack of tape (log.20010505.0):
>
>FAIL taper zhongsgi /home/data 0 [o
In "AMANDA Backup AMANDA MAIL REPORT FOR May 5":
Tape Size (meg) 5378.5 5378.50.0
Tape Used (%) 22.9 22.90.0
I presume "Tape Size" means amount of tape used, rather than size of
the whole tape. In amanda.conf I have:
Thanks. I overlooked that option. :-)
David Wolfskill wrote:
> How many tapes does your amanda.conf say amanda is allowed to use in a
> given run ("runtapes")?
>
> Cheers,
> david
> --
> David Wolfskill [EMAIL PROTECTED] UNIX System Administrator
> Desk: 650/577-7158 TIE: 8/499-7158
iginal Size (meg) 23627.823210.2 417.5
Avg Compressed Size (%) -- -- --(level:#disks
...)
Filesystems Dumped 31 1 30 (1:24 2:2 3:4)
Avg Dump Rate (k/s) 791.2 791.4 775.8
Tape Time (hrs:min)8:24 8:21
89 matches
Mail list logo
