20Gb tape not full
Hi all,
I've had a search through the FAQ, generally on the 'net and through the
list archives, but I can't seem to find anyone else reporting similar
symptoms to me, so here I go with my first post to the list. If I've
made a mistake, please be gentle...
I have a Linux box at another site. It's running Amanda 2.4.4p2 and is
plugged into a Compaq DDS4 drive.
Partway through a full nightly backup I'm getting the following email
back:
These dumps were to tape Haslar12.
*** A TAPE ERROR OCCURRED: [[writing file: No space left on device]].
Some dumps may have been left in the holding disk. Run amflush to
flush them to tape. The next tape Amanda expects to use is: Haslar14.
FAILURE AND STRANGE DUMP SUMMARY:
olympic/samba/company lev 0 FAILED [out of tape]
olympic/samba/company lev 0 FAILED [data write: Connection
reset by
peer]
olympic/samba/company lev 0 FAILED [dump to tape failed]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 5:07
Dump Time (hrs:min)1:10 1:10 0:00
Output Size (meg)5208.7 5208.70.0
Original Size (meg) 8918.1 8918.10.0
Avg Compressed Size (%)58.4 58.4--
Filesystems Dumped4 4 0
Avg Dump Rate (k/s) 1272.8 1272.8--
Tape Time (hrs:min)1:10 1:10 0:00
Tape Size (meg) 5208.7 5208.70.0
Tape Used (%) 27.0 27.00.0
Filesystems Taped 4 4 0
Avg Tp Write Rate (k/s) 1274.0 1274.0--
USAGE BY TAPE:
Label Time Size %Nb
Haslar12 1:105208.7 27.0 4
FAILED AND STRANGE DUMP DETAILS:
/-- olympic/samba/company lev 0 FAILED [data write: Connection
reset
by peer]
sendbackup: start [olympic:/samba/company level 0]
sendbackup: info BACKUP=/bin/tar
sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/bin/tar -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
\
NOTES:
taper: tape Haslar12 kb 16875296 fm 5 writing file: No space left on
device
DUMP SUMMARY:
DUMPER STATSTAPER
STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS
KB/s
-- -
olympic /etc/ 0 35090 10956 31.2 0:22 507.0
0:052276.1
olympic /home 0 90793005319769 58.6 69:241277.4
69:251277.4
olympic -ba/company 0 FAILED
---
olympic -a/netlogon 0 10 1 10.0 0:00 0.0 0:13
0.1
olympic /var/log0 17730 2938 16.6 0:04 702.6 0:04
786.5
(brought to you by Amanda version 2.4.4p2)
Now, if I'm reading this right, it's saying that it's hit the end of a
20Gb tape at around the 5Gb mark. Here's what I think are the relevant
parts of my amanda.conf:
tapetype HP-DDS-4
define tapetype HP-DDS-4 {
comment just produced by tapetype prog (hardware compression
on)
length 17021 mbytes
filemark 403 kbytes
speed 1578 kps
}
(Some of you may recognise this - provided by rnaydenov on the Amanda
site).
I'm wondering about a faulty tape drive or tapes?
Any help would be greatly appreciated,
Mark Lidstone
IT and Network Support Administrator
BMT SeaTech Ltd
Grove House, Meridians Cross, 7 Ocean Way
Ocean Village, Southampton. SO14 3TJ. UK
Tel: +44 (0)23 8063 5122
Fax: +44 (0)23 8063 5144
E-Mail: mailto:[EMAIL PROTECTED]
Website: www.bmtseatech.co.uk
==
Confidentiality Notice and Disclaimer:
The contents of this e-mail and any attachments are intended only for
the
use of the e-mail addressee(s) shown. If you are not that person, or one
of those persons, you are not allowed to take any action based upon it
or
to copy it, forward, distribute or disclose the contents of it and you
should please delete it from your system. BMT SeaTech Limited does not
accept liability for any errors or omissions in the context of this
e-mail
or its attachments which arise as a result of Internet transmission, nor
accept liability for statements which are those of the author and not
clearly made on behalf of BMT SeaTech Limited.
==
Re: 20Gb tape not full
On Mon, Mar 14, 2005 at 01:59:13PM -, Mark Lidstone enlightened us:
*snipped for brevity*
Now, if I'm reading this right, it's saying that it's hit the end of a
20Gb tape at around the 5Gb mark. Here's what I think are the relevant
parts of my amanda.conf:
tapetype HP-DDS-4
define tapetype HP-DDS-4 {
comment just produced by tapetype prog (hardware compression
on)
length 17021 mbytes
filemark 403 kbytes
speed 1578 kps
}
The problem is that you're mixing hardware and software compression.
USAGE BY TAPE:
Label Time Size %Nb
Haslar12 1:105208.7 27.0 4
About 5GB was *successfully* written to tape, consisting of 4 files (Nb 4)
NOTES:
taper: tape Haslar12 kb 16875296 fm 5 writing file: No space left on
device
The tape drive hit end of tape just shy of 17GB, which makes sense for a
DDS-4 drive in which both hardware and software compression are being used.
I would strongly recommend shutting off hardware compression on the drive
and readjusting your tapetype to be closer to the 20GB native tape size.
Matt
--
Matt Hyclak
Department of Mathematics
Department of Social Work
Ohio University
(740) 593-1263
pgpb85B8zZxzB.pgp
Description: PGP signature
Re: 20Gb tape not full
On Mon, Mar 14, 2005 at 01:59:13PM -, Mark Lidstone wrote:
Hi all,
I've had a search through the FAQ, generally on the 'net and through the
list archives, but I can't seem to find anyone else reporting similar
symptoms to me, so here I go with my first post to the list. If I've
made a mistake, please be gentle...
I have a Linux box at another site. It's running Amanda 2.4.4p2 and is
plugged into a Compaq DDS4 drive.
Partway through a full nightly backup I'm getting the following email
back:
These dumps were to tape Haslar12.
*** A TAPE ERROR OCCURRED: [[writing file: No space left on device]].
Some dumps may have been left in the holding disk. Run amflush to
flush them to tape. The next tape Amanda expects to use is: Haslar14.
FAILURE AND STRANGE DUMP SUMMARY:
olympic/samba/company lev 0 FAILED [out of tape]
olympic/samba/company lev 0 FAILED [data write: Connection
reset by
peer]
olympic/samba/company lev 0 FAILED [dump to tape failed]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 5:07
Dump Time (hrs:min)1:10 1:10 0:00
Output Size (meg)5208.7 5208.70.0
Original Size (meg) 8918.1 8918.10.0
Avg Compressed Size (%)58.4 58.4--
Filesystems Dumped4 4 0
Avg Dump Rate (k/s) 1272.8 1272.8--
Tape Time (hrs:min)1:10 1:10 0:00
Tape Size (meg) 5208.7 5208.70.0
Tape Used (%) 27.0 27.00.0
Filesystems Taped 4 4 0
Avg Tp Write Rate (k/s) 1274.0 1274.0--
USAGE BY TAPE:
Label Time Size %Nb
Haslar12 1:105208.7 27.0 4
FAILED AND STRANGE DUMP DETAILS:
/-- olympic/samba/company lev 0 FAILED [data write: Connection
reset
by peer]
sendbackup: start [olympic:/samba/company level 0]
sendbackup: info BACKUP=/bin/tar
sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/bin/tar -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
\
NOTES:
taper: tape Haslar12 kb 16875296 fm 5 writing file: No space left on
device
DUMP SUMMARY:
DUMPER STATSTAPER
STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS
KB/s
-- -
olympic /etc/ 0 35090 10956 31.2 0:22 507.0
0:052276.1
olympic /home 0 90793005319769 58.6 69:241277.4
69:251277.4
olympic -ba/company 0 FAILED
---
olympic -a/netlogon 0 10 1 10.0 0:00 0.0 0:13
0.1
olympic /var/log0 17730 2938 16.6 0:04 702.6 0:04
786.5
(brought to you by Amanda version 2.4.4p2)
Now, if I'm reading this right, it's saying that it's hit the end of a
20Gb tape at around the 5Gb mark. Here's what I think are the relevant
parts of my amanda.conf:
tapetype HP-DDS-4
define tapetype HP-DDS-4 {
comment just produced by tapetype prog (hardware compression
on)
length 17021 mbytes
filemark 403 kbytes
speed 1578 kps
}
(Some of you may recognise this - provided by rnaydenov on the Amanda
site).
I'm wondering about a faulty tape drive or tapes?
Wrong reading. It successfully wrote about 5GB.
It failed at about 16.9GB.
taper: tape Haslar12 kb 16875296 fm 5 writing file: No space left on
^^^
Now, this is a 20GB tape, so even that is a bit early.
That number though does pretty well match your tapetype length.
I'd guess you are running gzip compression (output size orig size)
and you have hardware compression turned on. The dds compression
algorithm increases the size of already compressed, or other nearly
random data, and reduces tape capacity by 10-20%.
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: 20Gb tape not full
On Mon, 14 Mar 2005 at 1:59pm, Mark Lidstone wrote NOTES: taper: tape Haslar12 kb 16875296 fm 5 writing file: No space left on device Now, if I'm reading this right, it's saying that it's hit the end of a 20Gb tape at around the 5Gb mark. Here's what I think are the relevant parts of my amanda.conf: No, it hit EOT at about the 16GB mark as indicated in the line from taper above. That would indicate to me that you have hardware compression enabled in addition to software compression. Don't do that. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
RE: 20Gb tape not full
Hi all,
Thanks very much for the replies. It didn't occur to me to check
hardware compression.
One comment to make, though - I am using a holding disk, and currently
it's free space is greater than the amount of data being backed up, so
does this log look like something's going screwy there too?
Many thanks,
Mark Lidstone
IT and Network Support Administrator
BMT SeaTech Ltd
Grove House, Meridians Cross, 7 Ocean Way
Ocean Village, Southampton. SO14 3TJ. UK
Tel: +44 (0)23 8063 5122
Fax: +44 (0)23 8063 5144
E-Mail: mailto:[EMAIL PROTECTED]
Website: www.bmtseatech.co.uk
==
Confidentiality Notice and Disclaimer:
The contents of this e-mail and any attachments are intended only for
the
use of the e-mail addressee(s) shown. If you are not that person, or one
of those persons, you are not allowed to take any action based upon it
or
to copy it, forward, distribute or disclose the contents of it and you
should please delete it from your system. BMT SeaTech Limited does not
accept liability for any errors or omissions in the context of this
e-mail
or its attachments which arise as a result of Internet transmission, nor
accept liability for statements which are those of the author and not
clearly made on behalf of BMT SeaTech Limited.
==
-Original Message-
From: Paul Bijnens [mailto:[EMAIL PROTECTED]
Sent: 14 March 2005 14:46
To: Mark Lidstone
Cc: amanda-users@amanda.org
Subject: Re: 20Gb tape not full
Mark Lidstone wrote:
These dumps were to tape Haslar12.
*** A TAPE ERROR OCCURRED: [[writing file: No space left on device]].
[...]
USAGE BY TAPE:
Label Time Size %Nb
Haslar12 1:105208.7 27.0 4
[...]
NOTES:
taper: tape Haslar12 kb 16875296 fm 5 writing file: No space left on
device
...
Now, if I'm reading this right, it's saying that it's hit the end of a
20Gb tape at around the 5Gb mark.
No, you're not reading this right. 5 Gbyte of dumps for 4 DLE's were
successfully written to tape. While writing the fifth DLE, amanda hit
EOT at 16875296 Kbyte (or about 16 Gbyte).
A few comments.
The report says:
olympic/samba/company lev 0 FAILED [dump to tape failed]
That means that you were not using a holdingdisk for this DLE. Maybe
it's too small? It helps a lot in having a large holdingdisk. Unless
you have really fast hardware and network, the tapedrive must
constantly stop/rewind-a-little/restart again. Besides the fact that
this slows down the whole process enormously, this is also a fast and
proven way to wear the tapedrive in a few weeks!
tapetype HP-DDS-4
define tapetype HP-DDS-4 {
comment just produced by tapetype prog (hardware compression
on)
length 17021 mbytes
filemark 403 kbytes
speed 1578 kps
}
You seem to be using hardware + software compression at the same time.
This is a waste of tapecapacity, and a wast of time, and a wast of cpu.
Put your tapedrive in hardware compression off, and you'll gain almost 4
Gbyte in capacity!
I'm wondering about a faulty tape drive or tapes?
If you keep bypassing the holdingdisk, that answer
will be yes in a few weeks. But currently is it no.
olympic /home 0 90793005319769 58.6 69:241277.4
69:251277.4
This reads much clearer if you add some whitespace between the columns.
Search the man page about columnspec. I have this line in my
amanda.conf (all on one very long line):
columnspec
HostName=0:9,Disk=1:18,Level=1:1,OrigKB=1:8,OutKB=1:7,Compress=1:5,Dump
Time=1:6,DumpRate=1:6,TapeTime=1:6,TapeRate=1:6
--
Paul Bijnens, XplanationTel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512
http://www.xplanation.com/ email: [EMAIL PROTECTED]
***
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...*
* ... Are you sure? ... YES ... Phew ... I'm out *
***
RE: 20Gb tape not full
Ooops. Answering my own question. I had a limit on the amount of space
to use on the holding disk - Just increased it, so that should sort it.
Righto, have turned off hardware compression (using mt -f /dev/nst0
compression 0), changed my tapetype (see below) and, as I said,
increased the size of my holding disk. I will keep an eye on this
tonight.
Thanks a lot for everyone's help.
tapetype HP-DAT
define tapetype HP-DAT {
comment DAT tape drives
length 19300 mbytes
filemark 111 kbytes
speed 468 kbytes
}
Mark Lidstone
IT and Network Support Administrator
BMT SeaTech Ltd
Grove House, Meridians Cross, 7 Ocean Way
Ocean Village, Southampton. SO14 3TJ. UK
Tel: +44 (0)23 8063 5122
Fax: +44 (0)23 8063 5144
E-Mail: mailto:[EMAIL PROTECTED]
Website: www.bmtseatech.co.uk
==
Confidentiality Notice and Disclaimer:
The contents of this e-mail and any attachments are intended only for
the
use of the e-mail addressee(s) shown. If you are not that person, or one
of those persons, you are not allowed to take any action based upon it
or
to copy it, forward, distribute or disclose the contents of it and you
should please delete it from your system. BMT SeaTech Limited does not
accept liability for any errors or omissions in the context of this
e-mail
or its attachments which arise as a result of Internet transmission, nor
accept liability for statements which are those of the author and not
clearly made on behalf of BMT SeaTech Limited.
==
-Original Message-
From: Mark Lidstone
Sent: 14 March 2005 15:06
To: amanda-users@amanda.org
Subject: RE: 20Gb tape not full
Hi all,
Thanks very much for the replies. It didn't occur to me to check
hardware compression.
One comment to make, though - I am using a holding disk, and currently
it's free space is greater than the amount of data being backed up, so
does this log look like something's going screwy there too?
Many thanks,
Mark Lidstone
IT and Network Support Administrator
BMT SeaTech Ltd
Grove House, Meridians Cross, 7 Ocean Way
Ocean Village, Southampton. SO14 3TJ. UK
Tel: +44 (0)23 8063 5122
Fax: +44 (0)23 8063 5144
E-Mail: mailto:[EMAIL PROTECTED]
Website: www.bmtseatech.co.uk
==
Confidentiality Notice and Disclaimer:
The contents of this e-mail and any attachments are intended only for
the use of the e-mail addressee(s) shown. If you are not that person, or
one of those persons, you are not allowed to take any action based upon
it or to copy it, forward, distribute or disclose the contents of it and
you should please delete it from your system. BMT SeaTech Limited does
not accept liability for any errors or omissions in the context of this
e-mail or its attachments which arise as a result of Internet
transmission, nor accept liability for statements which are those of the
author and not clearly made on behalf of BMT SeaTech Limited.
==
-Original Message-
From: Paul Bijnens [mailto:[EMAIL PROTECTED]
Sent: 14 March 2005 14:46
To: Mark Lidstone
Cc: amanda-users@amanda.org
Subject: Re: 20Gb tape not full
Mark Lidstone wrote:
These dumps were to tape Haslar12.
*** A TAPE ERROR OCCURRED: [[writing file: No space left on device]].
[...]
USAGE BY TAPE:
Label Time Size %Nb
Haslar12 1:105208.7 27.0 4
[...]
NOTES:
taper: tape Haslar12 kb 16875296 fm 5 writing file: No space left on
device
...
Now, if I'm reading this right, it's saying that it's hit the end of a
20Gb tape at around the 5Gb mark.
No, you're not reading this right. 5 Gbyte of dumps for 4 DLE's were
successfully written to tape. While writing the fifth DLE, amanda hit
EOT at 16875296 Kbyte (or about 16 Gbyte).
A few comments.
The report says:
olympic/samba/company lev 0 FAILED [dump to tape failed]
That means that you were not using a holdingdisk for this DLE. Maybe
it's too small? It helps a lot in having a large holdingdisk. Unless
you have really fast hardware and network, the tapedrive must
constantly stop/rewind-a-little/restart again. Besides the fact that
this slows down the whole process enormously, this is also a fast and
proven way to wear the tapedrive in a few weeks!
tapetype HP-DDS-4
define tapetype HP-DDS-4 {
comment just produced by tapetype prog (hardware compression
on)
length 17021 mbytes
filemark 403 kbytes
speed 1578 kps
}
You seem to be using hardware + software compression at the same time.
This is a waste of tapecapacity, and a wast of time, and a wast of cpu.
Put your tapedrive in hardware compression off, and you'll gain almost 4
Gbyte in capacity!
I'm wondering about a faulty tape drive or tapes?
If
Re: 20Gb tape not full
On Monday 14 March 2005 08:59, Mark Lidstone wrote:
Hi all,
I've had a search through the FAQ, generally on the 'net and through
the list archives, but I can't seem to find anyone else reporting
similar symptoms to me, so here I go with my first post to the
list. If I've made a mistake, please be gentle...
I have a Linux box at another site. It's running Amanda 2.4.4p2 and
is plugged into a Compaq DDS4 drive.
Partway through a full nightly backup I'm getting the following
email
back:
These dumps were to tape Haslar12.
*** A TAPE ERROR OCCURRED: [[writing file: No space left on
device]]. Some dumps may have been left in the holding disk. Run
amflush to flush them to tape. The next tape Amanda expects to use
is: Haslar14.
FAILURE AND STRANGE DUMP SUMMARY:
olympic/samba/company lev 0 FAILED [out of tape]
olympic/samba/company lev 0 FAILED [data write: Connection
reset by
peer]
olympic/samba/company lev 0 FAILED [dump to tape failed]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 5:07
Dump Time (hrs:min)1:10 1:10 0:00
Output Size (meg)5208.7 5208.70.0
Original Size (meg) 8918.1 8918.10.0
Avg Compressed Size (%)58.4 58.4--
Filesystems Dumped4 4 0
Avg Dump Rate (k/s) 1272.8 1272.8--
Tape Time (hrs:min)1:10 1:10 0:00
Tape Size (meg) 5208.7 5208.70.0
Tape Used (%) 27.0 27.00.0
Filesystems Taped 4 4 0
Avg Tp Write Rate (k/s) 1274.0 1274.0--
USAGE BY TAPE:
Label Time Size %Nb
Haslar12 1:105208.7 27.0 4
FAILED AND STRANGE DUMP DETAILS:
/-- olympic/samba/company lev 0 FAILED [data write:
Connection
reset
by peer]
sendbackup: start [olympic:/samba/company level 0]
sendbackup: info BACKUP=/bin/tar
sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/bin/tar -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
\
NOTES:
taper: tape Haslar12 kb 16875296 fm 5 writing file: No space
left on
device
DUMP SUMMARY:
DUMPER STATSTAPER
STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s
MMM:SS
KB/s
-- -
olympic /etc/ 0 35090 10956 31.2 0:22 507.0
0:052276.1
olympic /home 0 90793005319769 58.6 69:241277.4
69:251277.4
olympic -ba/company 0 FAILED
---
olympic -a/netlogon 0 10 1 10.0 0:00 0.0
0:13
0.1
olympic /var/log0 17730 2938 16.6 0:04 702.6
0:04
786.5
(brought to you by Amanda version 2.4.4p2)
Now, if I'm reading this right, it's saying that it's hit the end of
a 20Gb tape at around the 5Gb mark. Here's what I think are the
relevant parts of my amanda.conf:
tapetype HP-DDS-4
define tapetype HP-DDS-4 {
comment just produced by tapetype prog (hardware compression
on)
length 17021 mbytes
filemark 403 kbytes
speed 1578 kps
}
(Some of you may recognise this - provided by rnaydenov on the
Amanda site).
I'm wondering about a faulty tape drive or tapes?
Any help would be greatly appreciated,
Mark Lidstone
IT and Network Support Administrator
[snip legal disclaimer nobody pays any attention to anyway]
My first guess is that somewhere along the line, you've got some old
DDS2 tapes mixed into the stack somehow.
Go back to that exact tape (its not much good for a backup anyway) and
run an 'amtapetype -e 20GB -f /dev/whatever-it-is'. With hardware
compression on, you should get about what you have in your
amanda.conf.
Please note that the majority of us usually recommend the hardware
compression be turned off, in which case you'll get a bit less, the
lower of the two capcities the marketroids like to claim. But in
some instances you will get a lot more than 20GB of data stored
because gzip is more efficient than the hardware compressors. Last
night here, for instance:
Output Size (meg)7303.0 6632.4 670.6
Original Size (meg) 16943.615064.9 1878.7
Avg Compressed Size (%)36.1 36.2 35.0 (level:#disks)
This with a tapetype set for about 8GB. No problem. Expand that to a
10GB tapetype, and you can see that over 20GB would have fit after
gzip munched on it a while. Conversely, some other nights run may
have been most of my tar.gz's etc, and only 13GB would have fit. But
amanda would have been happy in either event.
We do this because amanda counts bytes sent down the cable, which if
using software compression, is after the compression, so it knows to
within a percent or so, exactly how
tapecycle and the doc
I had some questions regarding tapecycle, and after reading the man page and the doc (old and new), I think that they fall short on describing what tapecycle should be set to. The minimum value of tapecycle is well covered, but not the maximum value, and how tapecycle should relate to the number of tapes that have been labeled. From the man page: tapecycle int Default: 15 tapes. The number of tapes in the active tape cycle. This must be at least one larger than the number of Amanda runs done during a dump cycle (see the dumpcycle parameter) times the number of tapes used per run (see the runtapes parameter). For instance, if dumpcycle is set to 14 days, one Amanda run is done every day (Sunday through Satur- day), and runtapes is set to one, then tapecycle must be at least 15 (14 days * one run/day * one tape/run + one tape). In practice, there should be several extra tapes to allow for schedule adjustments or disaster recov- ery. So what is an active tape cycle? That is never defined anywhere. Although the last sentence is correct and it makes sense, it does not explain how tapecycle should relate to the actual number of labeled tapes. Here is my bad attempt at an improvement, please do not use it verbatim: You must have at least tapecycle tapes labeled, but you can have more. By labeling extra tapes, you can allow for schedule adjustments or disaster recovery. For example, lets say that your tapecycle is set to 20 and you have 20 labeled tapes. If you discover that tape #5 that you are about to put in the drive is bad, your only alternative is to immediately label a new replacement tape. If tapecycle was 20 and you had 25 labeled tapes, then you could put tape #6 in the drive and deal with the problem later. On the other hand, if the number of labeled tapes greatly exceeds tapecycle, then AMANDA (insert inefficiency issue here). -- Tom Schutter (mailto:[EMAIL PROTECTED]) Platte River Associates, Inc. (http://www.platte.com)
Re: 20Gb tape not full
On Monday 14 March 2005 10:14, Mark Lidstone wrote: Ooops. Answering my own question. I had a limit on the amount of space to use on the holding disk - Just increased it, so that should sort it. Righto, have turned off hardware compression (using mt -f /dev/nst0 compression 0), changed my tapetype (see below) and, as I said, increased the size of my holding disk. I will keep an eye on this tonight. You have one other problem with that. The state of the hardware compression is stored in a hidden header on the tape, and it will be turned on against your will during the tape drives tape recognition phase. To cancel it for real, one must rewind it dd the label block out to a scratch file rewind it set the compression off with mt (do both variations) dd the scratch file back to the tape, but this time use the rewinding device to do it so that the closing of the path at the end of the dd write will force a rewind, and that in turn will force the drive into a buffer flush since its now dirty, thereby resetting that hidden compression flag. rewind it again check with amcheck, should be ok. Or, you can dd about 10 megs from /dev/zero to the non-rewinding device after writing the label block back, which will eventually force a buffer flush/write, doing the same thing in terms of resetting the compression flag in the tape header. What I'd do I think, is write a script to do this, and run an amcheck to make sure the right tape is loaded before doing this, then have cron run this script about half an hour before the main amanda run. That way, you won't have destroyed any backups doing all that until the same day the tape is to be reused anyway. Once the tapecycle has been used up and all tapes are set to off, then kill the crontab entry as its just one more pass on the tapes leaders, and a DDS tape dies quick enough as it is. I hope this helps. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Re: signal 13 (PIPE) error.
On Mon, Mar 14, 2005 at 10:37:11PM +, Bruce S. Skinner wrote: My last dozen or so emails to amanda-users have gone into a black hole, I'll try this from another network under another subject. So let's try and walk (crawl?) before we run. I've set things up with only one small disk to be backed up, set dumpcycle 0 and removed the holding disk and tape changer from the config. It's still failing. There is a signal 13 (PIPE) error in sendbackup.debug. This will likely not assist you, just for information sake. Most amanda admins don't realize that when indexing is on there are actually two tars that run. One does the actual creation of the archive. The output of this command is duplicated (think of the unix tee command) with one copy going to the holding disk or tape drive as appropriate. The second copy of the newly created archive is send to another tar which reads through it and creates a table of contents which is the index. It has been my impression from the posted articles that about 90% of the tar pipe errors are from this second tar, the one creating the index from the archive, not the tar creating the archive itself. I'd be happy to be told I'm all wrong, but it seems to be a fragile part of amanda that manifests itself inconsistantly and in such a way as to not be analyzable (sp?). People who have the problem seem to fumble around making changes and it goes away without them being able to point to a specific reason for the repair. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: tapecycle and the doc
On Mon, Mar 14, 2005 at 09:14:43AM -0700, Tom Schutter wrote: I had some questions regarding tapecycle, and after reading the man page and the doc (old and new), I think that they fall short on describing what tapecycle should be set to. The minimum value of tapecycle is well covered, but not the maximum value, and how tapecycle should relate to the number of tapes that have been labeled. From the man page: tapecycle int Default: 15 tapes. The number of tapes in the Gee, I did not realize there was a default :) active tape cycle. This must be at least one larger than the number of Amanda runs done during a dump cycle (see the dumpcycle parameter) times the number of tapes used per run (see the runtapes parameter). For instance, if dumpcycle is set to 14 days, one Amanda run is done every day (Sunday through Satur- day), and runtapes is set to one, then tapecycle must be at least 15 (14 days * one run/day * one tape/run + one tape). In practice, there should be several extra tapes to allow for schedule adjustments or disaster recov- ery. So what is an active tape cycle? That is never defined anywhere. Bad wording. And it is seldom good practice to use a term (eg tapecycle) in the definition of the term. Although the last sentence is correct and it makes sense, it does not explain how tapecycle should relate to the actual number of labeled tapes. Here is my bad attempt at an improvement, please do not use it verbatim: You must have at least tapecycle tapes labeled, but you can have more. By labeling extra tapes, you can allow for schedule adjustments or disaster recovery. For example, lets say that your tapecycle is set to 20 and you have 20 labeled tapes. If you discover that tape #5 that you are about to put in the drive is bad, your only alternative is to immediately label a new replacement tape. If tapecycle was 20 and you had 25 labeled tapes, then you could put tape #6 in the drive and deal with the problem later. On the other hand, if the number of labeled tapes greatly exceeds tapecycle, then AMANDA (insert inefficiency issue here). Two things; I know of no inefficiency issues related to exceedingly large numbers of tapes in rotation. Or other problems, except cost, even in using fresh tapes every run. And as to your suggested revision, in writing man page documentation one must judge how much example, description, and definition should go into a document that is intended to be terse and quickly readable as reference, not how-to. Here is my attempt at a revision: tapecycle int Default: 15 tapes. Typically tapes are used by amanda in an ordered rotation. The tapecycle parameter defines the size of that rotation. The number of tapes in rotation must be larger than the number of tapes required for a complete dump cycle (see the dumpcycle parameter). This is calculated by multiplying the number of amdump runs per dump cycle (runspercycle parameter) times the number of tapes used per run (runtapes parameter). Typically two to four times this calculated number of tapes are in rotation. While amanda is always willing to use a new tape in its rotation, it refuses to reuse a tape until at least 'tapecycle' number of other tapes have been used. It is considered good administrative practice to set the tapecycle parameter slightly lower than the actual number of tapes in rotation. This allows the administrator to more easily cope with damaged or misplaced tapes or schedule adjustments that call for slight adjustments in the rotation order. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
