looking for tapes too long
fellow amanda-users,
at a customer we saw the following happen:
amanda-3.3.5 (we went back as 3.3.9 isn't yet working fine in gentoo
linux), an 8-slot tape library.
As long as the next tape(s) are in the library: everything great
If the admin forgets to change tapes every week and the next tape to use
is NOT in the library, amanda goes wild and doesn't stop scanning for
the next tape ... it goes through the 8 slots over and over again and
even spawns processes over and over until we have to kill the amdump etc
It should simply dump DLEs to holding disk if it doesn't find the next
tape within the library, right?
-
Maybe I got some mistake in my thinking (=config):
dumpcycle 1 weeks
runspercycle 5
tapecycle 28 tapes # the admin has 28 on site
runtapes 3
define changer robot {
tpchanger "chg-robot:/dev/sg1"
property "tape-device" "0=tape:/dev/nst0"
property "eject-before-unload" "no"
property "use-slots" "1-8"
device_property "LEOM" "TRUE"
}
tapedev "robot"
reserve 40
(anything else relevant here?)
-
If it helps I could ask the admin for debug-logs ... or we re-trigger
that behavior by unloading the tapes.
thanks for any pointers, Stefan
Re: looking for tapes too long
Am 2016-06-21 um 10:38 schrieb Stefan G. Weichinger: > If the admin forgets to change tapes every week and the next tape to use > is NOT in the library, amanda goes wild and doesn't stop scanning for > the next tape ... it goes through the 8 slots over and over again and > even spawns processes over and over until we have to kill the amdump etc [..] > thanks for any pointers, Stefan I had expected some discussion ... nobody?
Re: looking for tapes too long
> On Jun 27, 2016, at 4:07 AM, Stefan G. Weichinger wrote: > > Am 2016-06-21 um 10:38 schrieb Stefan G. Weichinger: > >> If the admin forgets to change tapes every week and the next tape to use >> is NOT in the library, amanda goes wild and doesn't stop scanning for >> the next tape ... it goes through the 8 slots over and over again and >> even spawns processes over and over until we have to kill the amdump etc > > [..] > >> thanks for any pointers, Stefan > > I had expected some discussion ... > nobody? > > (I’ve been on vacation …) But I HAVE had occurrences when the correct tape isn’t in the library. Amanda will search through my whole library, but only once. The parameters you quoted seemed reasonable to me.FWIW, I’m running on Linux, and we recompile what we run, since we want different parameters. So ours isn’t any packaged executable. Anybody else? Deb Baddorf Fermilab
Re: looking for tapes too long
Am 2016-06-27 um 21:19 schrieb Debra S Baddorf: (I’ve been on vacation …) But I HAVE had occurrences when the correct tape isn’t in the library. Amanda will search through my whole library, but only once. The parameters you quoted seemed reasonable to me.FWIW, I’m running on Linux, and we recompile what we run, since we want different parameters. So ours isn’t any packaged executable. thanks, Debra, for your statement.
Re: looking for tapes too long
Am 2016-06-27 um 11:07 schrieb Stefan G. Weichinger: Am 2016-06-21 um 10:38 schrieb Stefan G. Weichinger: If the admin forgets to change tapes every week and the next tape to use is NOT in the library, amanda goes wild and doesn't stop scanning for the next tape ... it goes through the 8 slots over and over again and even spawns processes over and over until we have to kill the amdump etc [..] thanks for any pointers, Stefan @JLM: should I provide any debug logs or so? I wonder if that behavior is bug-related and should be analysed. thanks, Stefan
Re: looking for tapes too long
> "SGW" == Stefan G Weichinger writes:
SGW> If the admin forgets to change tapes every week and the next tape
SGW> to use is NOT in the library, amanda goes wild and doesn't stop
SGW> scanning for the next tape
You don't actually say what kind of library you have so you aren't going
to get any responses like "I have the same one and it works OK for me;
here's my config."
I will say that I used to have the problem where amanda wouldn't trust
the barcode reader and would instead scan all 24 tapes in my library the
hard way when all of the tapes had been used. There's a brief
discussion about that on this list, and the solution was to change to
chg-robot. But you're already using that, so I've no idea.
The only relevant thing that's missing from your setup that I have is a
changerfile definition:
define changer magnum {
tpchanger "chg-robot:/dev/sg8"
property "tape-device" "0=tape:/dev/nst0"
device-property "LEOM" "TRUE"
device-property "BLOCK_SIZE" "512k"
changerfile "/var/lib/amanda/chg-robot-dev-sg8"
}
So you might want to find where the changer program is storing its state
and post that file. (And make sure that it's actually storing some
state.)
- J<
Re: looking for tapes too long
Am 2016-06-30 um 17:28 schrieb Jason L Tibbitts III:
You don't actually say what kind of library you have so you aren't going
to get any responses like "I have the same one and it works OK for me;
here's my config."
Yes, you are right. For now I can only look at /proc/scsi/ :
Vendor: HP Model: 1x8 G2 AUTOLDR Rev: 4.30
For detailled model info I have to ask the admin who is at home already,
I assume (evening time here)
I will say that I used to have the problem where amanda wouldn't trust
the barcode reader and would instead scan all 24 tapes in my library the
hard way when all of the tapes had been used. There's a brief
discussion about that on this list, and the solution was to change to
chg-robot. But you're already using that, so I've no idea.
The only relevant thing that's missing from your setup that I have is a
changerfile definition:
define changer magnum {
tpchanger "chg-robot:/dev/sg8"
property "tape-device" "0=tape:/dev/nst0"
device-property "LEOM" "TRUE"
device-property "BLOCK_SIZE" "512k"
changerfile "/var/lib/amanda/chg-robot-dev-sg8"
}/var/amanda/chg-robot-dev-sg0.
So you might want to find where the changer program is storing its state
and post that file. (And make sure that it's actually storing some
state.)
I looked at the manpage, it told me the default is
/var/amanda/chg-robot-dev-sg0 which does not exist on the server.
So now I configured it according to your example:
changerfile "/var/lib/amanda/$myconf/chg-robot-dev-sg1"
After amcheck it contains something, I attach it.
I assume the missing labels will be scanned step by step when the tapes
are used and rotated? Or do we miss some step?
Thanks to Jason, greets, Stefan
$STATE = {
'last_status' => 1467314912,
'drive_lru' => [
'0'
],
'drives' => {
'0' => {
'barcode' => 'CMR921L6',
'label' => 'CMR921',
'state' => 1,
'orig_slot' => 1
}
},
'slots' => {
'1' => {
'label' => 'CMR921',
'barcode' => 'CMR921L6',
'state' => 1,
'loaded_in' => '0',
'device_error' => undef,
'f_type' => bless( {
'value' => [
1
],
'sign' => '+'
}, 'Math::BigInt' ),
'device_status' => bless( {
'sign' => '+',
'value' => [
0
]
}, 'Math::BigInt' )
},
'7' => {
'device_status' => undef,
'loaded_in' => undef,
'f_type' => undef,
'device_error' => undef,
'state' => 1,
'barcode' => 'CMR919L6',
'ie' => 0,
'label' => undef
},
'6' => {
'f_type' => undef,
'device_error' => undef,
'state' => 1,
'barcode' => 'CMR917L6',
'ie' => 0,
'label' => undef,
'device_status' => undef,
'loaded_in' => undef
},
'5' => {
'loaded_in' => undef,
'device_status' => undef,
'state' => 1,
'ie' => 0,
'label' => undef,
'barcode' => 'CMR918L6',
'device_error' => undef,
'f_type' => undef
},
'4' => {
'device_status' => undef,
Re: looking for tapes too long
> "SGW" == Stefan G Weichinger writes: SGW> I assume the missing labels will be scanned step by step when the SGW> tapes are used and rotated? Or do we miss some step? It's been long enough since I've added new tapes that I've forgotten how it works. I think I simply manually created my tapelist with the corresponding barcodes, but amlabel will also do it (when given the --assign --barcode). I do not know if amanda will otherwise acquire the barcodes and store them in the tapelist when it sees the label on the tape. - J<
Re: looking for tapes too long
> On Jun 30, 2016, at 8:05 PM, Jason L Tibbitts III wrote: > >> "SGW" == Stefan G Weichinger writes: > > SGW> I assume the missing labels will be scanned step by step when the > SGW> tapes are used and rotated? Or do we miss some step? > > It's been long enough since I've added new tapes that I've forgotten how > it works. I think I simply manually created my tapelist with the > corresponding barcodes, but amlabel will also do it (when given the > --assign --barcode). > > I do not know if amanda will otherwise acquire the barcodes and store > them in the tapelist when it sees the label on the tape. > > - J<
Re: looking for tapes too long
> On Jun 30, 2016, at 8:05 PM, Jason L Tibbitts III wrote: > >> "SGW" == Stefan G Weichinger writes: > > SGW> I assume the missing labels will be scanned step by step when the > SGW> tapes are used and rotated? Or do we miss some step? > > It's been long enough since I've added new tapes that I've forgotten how > it works. I think I simply manually created my tapelist with the > corresponding barcodes, but amlabel will also do it (when given the > --assign --barcode). > > I do not know if amanda will otherwise acquire the barcodes and store > them in the tapelist when it sees the label on the tape. > > - J< I’m pretty sure I’ve deleted the robot contents file* and it refilled itself whenever it next read each tape. After that, the barcode reader cues it to which one is in which particular slot. *I deleted the file more than once, I think, when I was using the same file for two configs. It worked OK this way for a while, then got confused; then I deleted the contents file and it re-created. I later decided I should use two different files, even though the configs were sharing the same robot slots (not both run at the same time). Deb Baddorf Fermilab
Re: looking for tapes too long
Am 2016-07-01 um 18:42 schrieb Debra S Baddorf: I’m pretty sure I’ve deleted the robot contents file* and it refilled itself whenever it next read each tape. After that, the barcode reader cues it to which one is in which particular slot. *I deleted the file more than once, I think, when I was using the same file for two configs. It worked OK this way for a while, then got confused; then I deleted the contents file and it re-created. I later decided I should use two different files, even though the configs were sharing the same robot slots (not both run at the same time). I set that file, it was created and filled. The admin there will test if the behaviour changes when he doesn't provide the next tapes. In general I would like to know what makes amanda search over and over again. Is it possible that the missing changerfile lead to this? As in "amanda can't remember it has looked into these slots already" ?
Re: looking for tapes too long
Am 2016-07-03 um 21:12 schrieb Stefan G. Weichinger: > In general I would like to know what makes amanda search over and over > again. Is it possible that the missing changerfile lead to this? As in > "amanda can't remember it has looked into these slots already" ? We re-tested with correct changerfile and again that behavior. Could it be related to these lines in the latest amdump-log: DUMP samba.my.tld 9efefbff3f smb-etc 20160705143501 0 1 2016:7:4:21:50:2 1192 122 3 34 "Skipping: strategy NOINC can't be dumped in degraded mode" Interesting: I don't have any strategy noinc in that config $ amadmin myconf config | grep -i noinc $ hmm
Re: looking for tapes too long
Am 2016-07-05 um 16:25 schrieb Stefan G. Weichinger:
> Interesting: I don't have any strategy noinc in that config
>
> $ amadmin myconf config | grep -i noinc
> $
I see where that comes from:
JLM once pointed me at doing this:
define dumptype dle_exclude {
pigz-tar
}
# crontab
50 23 * * 1-4 /usr/sbin/amdump noras -oDUMPTYPE:dle_exclude:strategy=skip
So I could set dumptype dle_exclude for several DLEs I only want to be
dumped on specific weekdays.
I have no idea if this logic relates to amanda rotating through tapes
over and over.
Re: looking for tapes too long
Am 2016-07-05 um 17:21 schrieb Jean-Louis Martineau: > On 30/06/16 03:06 AM, Stefan G. Weichinger wrote: >> Am 2016-06-27 um 11:07 schrieb Stefan G. Weichinger: >>> Am 2016-06-21 um 10:38 schrieb Stefan G. Weichinger: >>> If the admin forgets to change tapes every week and the next tape to use is NOT in the library, amanda goes wild and doesn't stop scanning for the next tape ... it goes through the 8 slots over and over again and even spawns processes over and over until we have to kill the amdump etc >>> >>> [..] >>> thanks for any pointers, Stefan >> >> @JLM: should I provide any debug logs or so? > > run amdump with '-odebug_taper=9' and post the taper debug file. Did that. amdump stops immediately and requests a specific tape inserted (the one which we removed from the library to trigger that search behavior): amanda@samba ~ $ amdump myconf -odebug_taper=9 & [1] 24124 amanda@samba ~ $ No acceptable volumes found Insert volume labeled 'CMR920' in robot and press enter, or ^D to abort. [1]+ Stopped amdump myconf -odebug_taper=9 - $ amadmin myconf tape The next Amanda run should go onto tape CMR920 or a new tape. tape CMR925 or a new tape. tape CMR926 or a new tape. - $ cat taper.20160706103915.debug Wed Jul 6 10:39:15 2016: thd-0x55cb190d9800: taper: pid 24307 ruid 87 euid 87 version 3.3.5: start at Wed Jul 6 10:39:15 2016 Wed Jul 6 10:39:15 2016: thd-0x55cb190d9800: taper: Arguments: myconf -odebug_taper=9 Wed Jul 6 10:39:15 2016: thd-0x55cb190d9800: taper: config_overrides: debug_taper 9 Wed Jul 6 10:39:15 2016: thd-0x55cb190d9800: taper: pid 24307 ruid 87 euid 87 version 3.3.5: rename at Wed Jul 6 10:39:15 2016 Wed Jul 6 10:39:15 2016: thd-0x55cb190d9800: taper: chg-robot: using statefile '/var/lib/amanda/myconf/chg-robot-dev-sg1' Wed Jul 6 10:39:15 2016: thd-0x55cb190d9800: taper: taper/driver << START-TAPER worker0 20160706103915 Wed Jul 6 10:39:15 2016: thd-0x55cb190d9800: taper: Amanda::Taper::Scribe: starting Wed Jul 6 10:39:15 2016: thd-0x55cb190d9800: taper: invoking /usr/sbin/mtx -f /dev/sg1 status Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage Changer /dev/sg1:1 Drives, 8 Slots ( 0 Import/Export ) Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Data Transfer Element 0:Full (Storage Element 8 Loaded):VolumeTag = CMR919L6 Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage Element 1:Full :VolumeTag=CMR921L6 Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage Element 2:Full :VolumeTag=CMR922L6 Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage Element 3:Full :VolumeTag=CMR923L6 Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage Element 4:Full :VolumeTag=CMR924L6 Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage Element 5:Full :VolumeTag=CMR918L6 Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage Element 6:Full :VolumeTag=CMR917L6 Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage Element 7:Empty Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage Element 8:Empty Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: robot: updating state Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: new Amanda::Changer::Error: type='failed', reason='notfound', message='No acceptable volumes found' --- but it should simply skip the fact that there is no valid next tape in the library and dump to the holdingdisk. And not wait for an operator to do something ;-)
Re: looking for tapes too long
> On Jul 6, 2016, at 3:55 AM, Stefan G. Weichinger wrote: > > Am 2016-07-05 um 17:21 schrieb Jean-Louis Martineau: >> On 30/06/16 03:06 AM, Stefan G. Weichinger wrote: >>> Am 2016-06-27 um 11:07 schrieb Stefan G. Weichinger: Am 2016-06-21 um 10:38 schrieb Stefan G. Weichinger: > If the admin forgets to change tapes every week and the next tape to > use > is NOT in the library, amanda goes wild and doesn't stop scanning for > the next tape ... it goes through the 8 slots over and over again and > even spawns processes over and over until we have to kill the amdump > etc [..] > thanks for any pointers, Stefan >>> >>> @JLM: should I provide any debug logs or so? >> >> run amdump with '-odebug_taper=9' and post the taper debug file. > > Did that. > > amdump stops immediately and requests a specific tape inserted (the one > which we removed from the library to trigger that search behavior): > > > amanda@samba ~ $ amdump myconf -odebug_taper=9 & > [1] 24124 > amanda@samba ~ $ No acceptable volumes found > > Insert volume labeled 'CMR920' in robot > and press enter, or ^D to abort. > > [1]+ Stopped amdump myconf -odebug_taper=9 > > - > > $ amadmin myconf tape > The next Amanda run should go onto tape CMR920 or a new tape. > tape CMR925 or a new tape. > tape CMR926 or a new tape. > > - > > $ cat taper.20160706103915.debug > Wed Jul 6 10:39:15 2016: thd-0x55cb190d9800: taper: pid 24307 ruid 87 > euid 87 version 3.3.5: start at Wed Jul 6 10:39:15 2016 > Wed Jul 6 10:39:15 2016: thd-0x55cb190d9800: taper: Arguments: myconf > -odebug_taper=9 > Wed Jul 6 10:39:15 2016: thd-0x55cb190d9800: taper: config_overrides: > debug_taper 9 > Wed Jul 6 10:39:15 2016: thd-0x55cb190d9800: taper: pid 24307 ruid 87 > euid 87 version 3.3.5: rename at Wed Jul 6 10:39:15 2016 > Wed Jul 6 10:39:15 2016: thd-0x55cb190d9800: taper: chg-robot: using > statefile '/var/lib/amanda/myconf/chg-robot-dev-sg1' > Wed Jul 6 10:39:15 2016: thd-0x55cb190d9800: taper: taper/driver << > START-TAPER worker0 20160706103915 > Wed Jul 6 10:39:15 2016: thd-0x55cb190d9800: taper: > Amanda::Taper::Scribe: starting > Wed Jul 6 10:39:15 2016: thd-0x55cb190d9800: taper: invoking > /usr/sbin/mtx -f /dev/sg1 status > Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage > Changer /dev/sg1:1 Drives, 8 Slots ( 0 Import/Export ) > Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Data Transfer > Element 0:Full (Storage Element 8 Loaded):VolumeTag = CMR919L6 > > Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage > Element 1:Full :VolumeTag=CMR921L6 > Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage > Element 2:Full :VolumeTag=CMR922L6 > Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage > Element 3:Full :VolumeTag=CMR923L6 > Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage > Element 4:Full :VolumeTag=CMR924L6 > Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage > Element 5:Full :VolumeTag=CMR918L6 > Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage > Element 6:Full :VolumeTag=CMR917L6 > Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage > Element 7:Empty > Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: mtx: Storage > Element 8:Empty > Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: robot: updating state > Wed Jul 6 10:39:16 2016: thd-0x55cb190d9800: taper: new > Amanda::Changer::Error: type='failed', reason='notfound', message='No > acceptable volumes found' > > --- but it should simply skip the fact that there is no valid next tape > in the library and dump to the holdingdisk. And not wait for an operator > to do something ;-) Is there room on your holding disk? I noticed earlier that you said the holding disk "reserve” was at 40. Since I have nothing but amanda stuff on my holding disk, I set mine to 02 percent reserved for incremental type backups. However, if you have space for at least one of your DLEs, it probably should be writing something to the holding disk. Deb Baddorf Fermilab
Re: looking for tapes too long
Am 2016-07-06 um 19:13 schrieb Jean-Louis Martineau:
It wait for an operator because you set an interactivity. And that's why
it continue to scan the changer, to detect change in it.
I didn't set an interactivity intentionally.
But the config has grown and that setting might come from the admin there.
define interactivity inter_tty_email {
plugin "tty_email"
property "mailto" "admin1" "admin2"
property "resend-delay" "10"
property "check-file" "/tmp/email_input"
property "check-file-delay" "10"
}
interactivity "inter_tty_email"
--- I commented the last line to un-set it, ok?
Currently the correct tape is in the library, so I have to wait for the
admin on site to test things when the tape is not in there.
Anyway, amanda should use the holdingdisk if it is allowed! What is the
holdingdisk setting in the dumptype?
holdingdisk hd1 {
comment "main holding disk"
directory "/mnt/backup/amhold/myconf"
use -50 Gb
chunksize 5Gb
}
reserve 40
flush-threshold-dumped 40
flush-threshold-scheduled 40
Re: looking for tapes too long
Am 2016-07-06 um 18:51 schrieb Debra S Baddorf: Is there room on your holding disk? I noticed earlier that you said the holding disk "reserve” was at 40. Since I have nothing but amanda stuff on my holding disk, I set mine to 02 percent reserved for incremental type backups. However, if you have space for at least one of your DLEs, it probably should be writing something to the holding disk. More than 6.2 TB free there ... I think that this "interactivity" setting mentioned by Jean-Louis is the reason for the issues. As mentioned I wait for the on-site-admin to test things.
Re: looking for tapes too long
Am 2016-07-06 um 20:12 schrieb Jean-Louis Martineau: In the dumptype? disklist? run: amadmin CONF disklist | grep -i holdingdisk $ amadmin myconf disklist | grep -i holdingdisk HOLDINGDISK AUTO HOLDINGDISK AUTO HOLDINGDISK AUTO HOLDINGDISK AUTO HOLDINGDISK AUTO HOLDINGDISK AUTO HOLDINGDISK AUTO HOLDINGDISK AUTO HOLDINGDISK AUTO HOLDINGDISK AUTO HOLDINGDISK AUTO HOLDINGDISK AUTO HOLDINGDISK NEVER HOLDINGDISK NEVER HOLDINGDISK NEVER We have three DLEs with "NEVER" because their data is on the same storage as the holding disk area. I want to avoid cp-ing that data within the same RAID ...
Re: looking for tapes too long
Am 2016-07-06 um 20:33 schrieb Jean-Louis Martineau: The dles with 'AUTO' holdingdisk should be dumped to holding disk. Can you post the amdump log file? I will do as soon we tested an amdump with the tape removed. Might take a day, it's evening here in europe and the admin is at home already, as far as I know ;-) Thanks so far, Stefan
Re: looking for tapes too long
Am 2016-07-06 um 20:41 schrieb Stefan G. Weichinger: Am 2016-07-06 um 20:33 schrieb Jean-Louis Martineau: The dles with 'AUTO' holdingdisk should be dumped to holding disk. Can you post the amdump log file? I will do as soon we tested an amdump with the tape removed. Might take a day, it's evening here in europe and the admin is at home already, as far as I know ;-) That test has to wait until monday. Asked in general: is it recommended or necessary to run "amtape $myconf update" every time the admin loads the library's magazines with fresh tapes?
Re: looking for tapes too long
> On Jul 9, 2016, at 2:58 AM, Stefan G. Weichinger wrote: > > Am 2016-07-06 um 20:41 schrieb Stefan G. Weichinger: >> Am 2016-07-06 um 20:33 schrieb Jean-Louis Martineau: >>> The dles with 'AUTO' holdingdisk should be dumped to holding disk. >>> >>> Can you post the amdump log file? >> >> I will do as soon we tested an amdump with the tape removed. >> Might take a day, it's evening here in europe and the admin is at home >> already, as far as I know ;-) > > > That test has to wait until monday. > > Asked in general: > > is it recommended or necessary to run "amtape $myconf update" every time the > admin loads the library's magazines with fresh tapes? > I’ve found it not necessary. As long as the machine has SEEN those tapes before (and it must have, since you had to load them to put a label on them) AND as long as you have a barcode reader, it’ll recognize them. Actually, even without the barcode reader, it’ll recognize them when it loads them, but it might have to mount each one when you’ve asked for a restore & a particular tape is required. With a barcode reader, it should already know which slot that barcode is in, and will have stored info about “BARCODE XYZZY means tape DAILY-XYZZY” (or however your barcodes correspond to your actual tape labels. Deb
Re: looking for tapes too long
Am 2016-07-11 um 18:29 schrieb Debra S Baddorf: >> Asked in general: >> >> is it recommended or necessary to run "amtape $myconf update" every >> time the admin loads the library's magazines with fresh tapes? >> > > I’ve found it not necessary. As long as the machine has SEEN those > tapes before (and it must have, since you had to load them to put a > label on them) AND as long as you have a barcode reader, it’ll > recognize them. Actually, even without the barcode reader, it’ll > recognize them when it loads them, but it might have to mount each > one when you’ve asked for a restore & a particular tape is required. > With a barcode reader, it should already know which slot that barcode > is in, and will have stored info about “BARCODE XYZZY means tape > DAILY-XYZZY” (or however your barcodes correspond to your actual > tape labels. We had the case that it didn't write to one tape last week for some reason. Currently it looks good and the admin tests removing the $nexttape this evening. Thanks.
Re: looking for tapes too long
> On Jul 13, 2016, at 3:52 AM, Stefan G. Weichinger wrote: > > Am 2016-07-11 um 18:29 schrieb Debra S Baddorf: > >>> Asked in general: >>> >>> is it recommended or necessary to run "amtape $myconf update" every >>> time the admin loads the library's magazines with fresh tapes? >>> >> >> I’ve found it not necessary. As long as the machine has SEEN those >> tapes before (and it must have, since you had to load them to put a >> label on them) AND as long as you have a barcode reader, it’ll >> recognize them. Actually, even without the barcode reader, it’ll >> recognize them when it loads them, but it might have to mount each >> one when you’ve asked for a restore & a particular tape is required. >> With a barcode reader, it should already know which slot that barcode >> is in, and will have stored info about “BARCODE XYZZY means tape >> DAILY-XYZZY” (or however your barcodes correspond to your actual >> tape labels. > > We had the case that it didn't write to one tape last week for some > reason. Currently it looks good and the admin tests removing the > $nexttape this evening. > > Thanks. > I’ve had that too. Sometimes, one tape has gotten into the wrong place in the TAPELIST file, which seems to be where the “ordering” comes from. I’ve manually moved tapes in that list, and faked their date, to put them back into the numerical order that I want. [ I only do that a day or two before they expire, though, because I’m guessing that when I alter the date in TAPELIST, that a recover would have trouble with it. ] Sometimes it just gets skipped anyway. But rarely. Deb
