Re: debian 11, vtapes not found correctly anymore
Am 21.04.22 um 09:12 schrieb Stefan G. Weichinger: Am 21.04.22 um 09:03 schrieb Kees Meijs | Nefos: Hi, Anything in /var/log/kern.log and the like about the "amcheck-device: new Amanda::Changer::Error: type='failed', reason='notfound', message='No removable disk mounted on '/mnt/externaldisk01'' maybe? Maybe there's a clear error about the drive not being mounted and the root cause if outside of AMANDA. It gets mounted. lines in kern.log like: Apr 21 08:52:15 server kernel: [5431442.882110] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) Apr 21 08:53:53 server kernel: [5431540.968731] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) Something else: when I run "amadmin vtape tape" it tells me it looks for a tape on the non-attached usb disk. Or a new tape. This explains why it accepts a relabeled tape (it's new then). So something with the rotation and/or number of tapes seems wrong, right? There are 15 slots on the currently attached disk. "num_slot" = 14 When I reduce tapecycle to 14 tapes, the vtape is recognized OK! I had tapecycle = 28 tapes before: 2 changers with 14 tapes each. That has worked so far, I wonder why. I adjust to 14 now and monitor the next runs.
Re: debian 11, vtapes not found correctly anymore
Am 21.04.22 um 09:03 schrieb Kees Meijs | Nefos: Hi, Anything in /var/log/kern.log and the like about the "amcheck-device: new Amanda::Changer::Error: type='failed', reason='notfound', message='No removable disk mounted on '/mnt/externaldisk01'' maybe? Maybe there's a clear error about the drive not being mounted and the root cause if outside of AMANDA. It gets mounted. lines in kern.log like: Apr 21 08:52:15 server kernel: [5431442.882110] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) Apr 21 08:53:53 server kernel: [5431540.968731] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) no errors there thanks
Re: debian 11, vtapes not found correctly anymore
Hi, Anything in /var/log/kern.log and the like about the "amcheck-device: new Amanda::Changer::Error: type='failed', reason='notfound', message='No removable disk mounted on '/mnt/externaldisk01'' maybe? Maybe there's a clear error about the drive not being mounted and the root cause if outside of AMANDA. K. On 21-04-2022 08:59, Stefan G. Weichinger wrote: Am 14.04.22 um 07:28 schrieb Stefan G. Weichinger: Am 13.04.22 um 15:29 schrieb Jose M Calhariz: My setup is more simple I have several RAID6, each one is always mounted, on /vTapes1, /vTapes2, ... and there is a /vLibrary where there is all slots directories that are symbolic links into /vTapes* Have you look inside /mnt/externaldisk* to check if everything seams OK? Sure. Thanks for describing your more basic setup. Things I am not sure of: * taperscan: back then JLM told me to use "lexical" because otherwise it didn't work (years ago, I think it was related to this "chg-aggregate combines multiple chg-disk changers") * labels: autolabel, metalabel ... maybe I have that wrong * and why did it break? It worked ok in these 2 sites for years. Both Debian, so maybe some perl-library changed or something like that? So I am basically relabeling a tape or two every day on these 2 amanda servers to keep the backups working. Still not solved. See debug file: cat amcheck-device.20220421085207.debug Thu Apr 21 08:52:07.730038795 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: pid 26173 ruid 34 euid 34 version 3.5.1: start at Thu Apr 21 08:52:07 2022 Thu Apr 21 08:52:07.730194892 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: reading config file /etc/amanda/vtape_usb/amanda.conf Thu Apr 21 08:52:07.747494862 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: pid 26173 ruid 34 euid 34 version 3.5.1: rename at Thu Apr 21 08:52:07 2022 Thu Apr 21 08:52:07.756287648 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: chg-disk: Dir /mnt/externaldisk01 Thu Apr 21 08:52:07.756300940 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: chg-disk: Using statefile '/mnt/externaldisk01/state' Thu Apr 21 08:52:15.465003748 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: new Amanda::Changer::Error: type='failed', reason='notfound', message='No removable disk mounted on '/mnt/externaldisk01'' Thu Apr 21 08:52:15.465126422 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: Changer 'disk01' not quit Thu Apr 21 08:52:15.466118198 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: chg-disk: Dir /mnt/externaldisk02 Thu Apr 21 08:52:15.466139627 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: chg-disk: Using statefile '/mnt/externaldisk02/state' Thu Apr 21 08:52:15.664007096 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: chg-aggragte: Using statefile '/etc/amanda/vtape_usb/aggregate.stats' Thu Apr 21 08:52:16.499061286 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: new Amanda::Changer::Error: type='failed', reason='notfound', message='No acceptable volumes found' Thu Apr 21 08:52:16.654700142 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_utime : 0 Thu Apr 21 08:52:16.654750749 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_stime : 0 Thu Apr 21 08:52:16.654764307 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_maxrss : 39176 Thu Apr 21 08:52:16.654778894 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_ixrss : 0 Thu Apr 21 08:52:16.654789168 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_idrss : 0 Thu Apr 21 08:52:16.654798856 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_isrss : 0 Thu Apr 21 08:52:16.654808877 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_minflt : 8815 Thu Apr 21 08:52:16.654818861 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_majflt : 0 Thu Apr 21 08:52:16.654828484 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_nswap : 0 Thu Apr 21 08:52:16.654838003 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_inblock : 1168 Thu Apr 21 08:52:16.654847930 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_oublock : 32 Thu Apr 21 08:52:16.654857650 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_msgsnd : 0 Thu Apr 21 08:52:16.654867158 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_msgrcv : 0 Thu Apr 21 08:52:16.654876613 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_nsignals: 0 Thu Apr 21 08:52:16.654886249 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_nvcsw : 54 Thu Apr 21 08:52:16.654895860 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_nivcsw : 50 Thu Apr 21 08:52:16.655278285 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: pid 26173 finish time Thu Apr 21 08:52:16 2022 "amadmin vtape_usb inventory" shows all the vtapes correctly.
Re: debian 11, vtapes not found correctly anymore
Am 14.04.22 um 07:28 schrieb Stefan G. Weichinger: Am 13.04.22 um 15:29 schrieb Jose M Calhariz: My setup is more simple I have several RAID6, each one is always mounted, on /vTapes1, /vTapes2, ... and there is a /vLibrary where there is all slots directories that are symbolic links into /vTapes* Have you look inside /mnt/externaldisk* to check if everything seams OK? Sure. Thanks for describing your more basic setup. Things I am not sure of: * taperscan: back then JLM told me to use "lexical" because otherwise it didn't work (years ago, I think it was related to this "chg-aggregate combines multiple chg-disk changers") * labels: autolabel, metalabel ... maybe I have that wrong * and why did it break? It worked ok in these 2 sites for years. Both Debian, so maybe some perl-library changed or something like that? So I am basically relabeling a tape or two every day on these 2 amanda servers to keep the backups working. Still not solved. See debug file: cat amcheck-device.20220421085207.debug Thu Apr 21 08:52:07.730038795 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: pid 26173 ruid 34 euid 34 version 3.5.1: start at Thu Apr 21 08:52:07 2022 Thu Apr 21 08:52:07.730194892 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: reading config file /etc/amanda/vtape_usb/amanda.conf Thu Apr 21 08:52:07.747494862 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: pid 26173 ruid 34 euid 34 version 3.5.1: rename at Thu Apr 21 08:52:07 2022 Thu Apr 21 08:52:07.756287648 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: chg-disk: Dir /mnt/externaldisk01 Thu Apr 21 08:52:07.756300940 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: chg-disk: Using statefile '/mnt/externaldisk01/state' Thu Apr 21 08:52:15.465003748 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: new Amanda::Changer::Error: type='failed', reason='notfound', message='No removable disk mounted on '/mnt/externaldisk01'' Thu Apr 21 08:52:15.465126422 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: Changer 'disk01' not quit Thu Apr 21 08:52:15.466118198 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: chg-disk: Dir /mnt/externaldisk02 Thu Apr 21 08:52:15.466139627 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: chg-disk: Using statefile '/mnt/externaldisk02/state' Thu Apr 21 08:52:15.664007096 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: chg-aggragte: Using statefile '/etc/amanda/vtape_usb/aggregate.stats' Thu Apr 21 08:52:16.499061286 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: new Amanda::Changer::Error: type='failed', reason='notfound', message='No acceptable volumes found' Thu Apr 21 08:52:16.654700142 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_utime : 0 Thu Apr 21 08:52:16.654750749 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_stime : 0 Thu Apr 21 08:52:16.654764307 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_maxrss : 39176 Thu Apr 21 08:52:16.654778894 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_ixrss : 0 Thu Apr 21 08:52:16.654789168 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_idrss : 0 Thu Apr 21 08:52:16.654798856 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_isrss : 0 Thu Apr 21 08:52:16.654808877 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_minflt : 8815 Thu Apr 21 08:52:16.654818861 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_majflt : 0 Thu Apr 21 08:52:16.654828484 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_nswap : 0 Thu Apr 21 08:52:16.654838003 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_inblock : 1168 Thu Apr 21 08:52:16.654847930 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_oublock : 32 Thu Apr 21 08:52:16.654857650 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_msgsnd : 0 Thu Apr 21 08:52:16.654867158 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_msgrcv : 0 Thu Apr 21 08:52:16.654876613 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_nsignals: 0 Thu Apr 21 08:52:16.654886249 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_nvcsw : 54 Thu Apr 21 08:52:16.654895860 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: ru_nivcsw : 50 Thu Apr 21 08:52:16.655278285 2022: pid 26173: thd-0x55f8b31aac00: amcheck-device: pid 26173 finish time Thu Apr 21 08:52:16 2022 "amadmin vtape_usb inventory" shows all the vtapes correctly.
Re: debian 11, vtapes not found correctly anymore
Am 13.04.22 um 15:29 schrieb Jose M Calhariz: My setup is more simple I have several RAID6, each one is always mounted, on /vTapes1, /vTapes2, ... and there is a /vLibrary where there is all slots directories that are symbolic links into /vTapes* Have you look inside /mnt/externaldisk* to check if everything seams OK? Sure. Thanks for describing your more basic setup. Things I am not sure of: * taperscan: back then JLM told me to use "lexical" because otherwise it didn't work (years ago, I think it was related to this "chg-aggregate combines multiple chg-disk changers") * labels: autolabel, metalabel ... maybe I have that wrong * and why did it break? It worked ok in these 2 sites for years. Both Debian, so maybe some perl-library changed or something like that? So I am basically relabeling a tape or two every day on these 2 amanda servers to keep the backups working.
Re: debian 11, vtapes not found correctly anymore
On Wed, Apr 13, 2022 at 10:37:48AM +0200, Stefan G. Weichinger wrote:
> Am 13.04.22 um 09:56 schrieb Stefan G. Weichinger:
> >
> > Am 12.04.22 um 17:57 schrieb Jose M Calhariz:
> > > Hi,
> > >
> > > To tell that I have 1 instalation of amanda in Debian 11 with vtapes
> > > working flawless. Can we share the setup?
> >
> > Sure, I'd appreciate that.
> >
> > I have several vtape-installations working OK, it seems that the special
> > config with aggregating 2 or more chg-disk-changers is the problem here.
> >
> > I will post such a config in the next hour.
>
> OK, showing.
>
> I won't post the whole amanda.conf as it is long and maybe irrelevant for
> this topic.
>
> Just the parts around the changers, and some scheduling parameters.
>
> See "amadmin vtape config" here:
>
> https://gist.github.com/stefangweichinger/693eeb2c0c02d03abb31b53073352dd1
>
> (yes, way too many old dumptypes in there etc)
>
> -
>
> I take the setup from a site where we have 7 external USB drives with vtapes
> on them.
>
> So 7 changer devices like this:
>
> define changer disk1 {
> tpchanger "chg-disk:/mnt/externaldisk1"
> property "num_slot" "20"
> property "auto-create-slot" "yes"
> property "removable" "yes"
> property "MOUNT" "yes"
> property "UMOUNT" "yes"
> property "UMOUNT-LOCKFILE"
> "/etc/amanda/vtape/externaldisk1.lock"
> property "UMOUNT-DELAY" "1"
> }
>
> define changer disk2 {
> tpchanger "chg-disk:/mnt/externaldisk2"
> property "num_slot" "20"
> property "auto-create-slot" "yes"
> property "removable" "yes"
> property "MOUNT" "yes"
> property "UMOUNT" "yes"
> property "UMOUNT-LOCKFILE"
> "/etc/amanda/vtape/externaldisk2.lock"
> property "UMOUNT-DELAY" "1"
> }
>
> ... up to changer disk3. all the disks are listed in /etc/fstab
>
> UUID=5a5a9927-995f-4f0f-98ff-d222561f84ff /mnt/externaldisk1 ext4
> relatime,noauto,user 0 2
>
> and are (un-)mounted by the backup-user at amanda runtime.
>
> -
>
> The 7 chg-disk changers are aggregated into one "tpchanger" via
> chg-aggregate:
>
> define changer aggregate {
> tpchanger "chg-aggregate:{disk1,disk2,disk3,disk4,disk5,disk6,disk7}"
> property "state_filename" "/etc/amanda/vtape/aggregate.stats"
> property "allow-missing-changer" "yes"
> }
>
> And that one is used via:
>
> tpchanger "aggregate"
>
> - The "design goal" here was:
>
> an employee should swap the usb-disk every week.
>
> Amanda should rotate vtapes on one disk if they forget to change the disk.
>
> Amanda should use vtapes on each external disk, regardless which disk is
> attached.
>
> That works OK.
>
> Right now it's only that issue around "why aren't existing vtapes recognized
> and used?".
>
My setup is more simple
I have several RAID6, each one is always mounted, on /vTapes1,
/vTapes2, ... and there is a /vLibrary where there is all slots
directories that are symbolic links into /vTapes*
Have you look inside /mnt/externaldisk* to check if everything seams
OK?
Kind regards
Jose M Calhariz
--
--
Conheci no Brasil a miséria rica. Hoje, conheço a riqueza miserável
--Adolpho Bloch
signature.asc
Description: PGP signature
Re: debian 11, vtapes not found correctly anymore
Am 13.04.22 um 10:37 schrieb Stefan G. Weichinger: ... up to changer disk3. all the disks are listed in /etc/fstab correction: up to changer disk7, sure
Re: debian 11, vtapes not found correctly anymore
Am 13.04.22 um 09:56 schrieb Stefan G. Weichinger:
Am 12.04.22 um 17:57 schrieb Jose M Calhariz:
Hi,
To tell that I have 1 instalation of amanda in Debian 11 with vtapes
working flawless. Can we share the setup?
Sure, I'd appreciate that.
I have several vtape-installations working OK, it seems that the special
config with aggregating 2 or more chg-disk-changers is the problem here.
I will post such a config in the next hour.
OK, showing.
I won't post the whole amanda.conf as it is long and maybe irrelevant
for this topic.
Just the parts around the changers, and some scheduling parameters.
See "amadmin vtape config" here:
https://gist.github.com/stefangweichinger/693eeb2c0c02d03abb31b53073352dd1
(yes, way too many old dumptypes in there etc)
-
I take the setup from a site where we have 7 external USB drives with
vtapes on them.
So 7 changer devices like this:
define changer disk1 {
tpchanger "chg-disk:/mnt/externaldisk1"
property "num_slot" "20"
property "auto-create-slot" "yes"
property "removable" "yes"
property "MOUNT" "yes"
property "UMOUNT" "yes"
property "UMOUNT-LOCKFILE"
"/etc/amanda/vtape/externaldisk1.lock"
property "UMOUNT-DELAY" "1"
}
define changer disk2 {
tpchanger "chg-disk:/mnt/externaldisk2"
property "num_slot" "20"
property "auto-create-slot" "yes"
property "removable" "yes"
property "MOUNT" "yes"
property "UMOUNT" "yes"
property "UMOUNT-LOCKFILE"
"/etc/amanda/vtape/externaldisk2.lock"
property "UMOUNT-DELAY" "1"
}
... up to changer disk3. all the disks are listed in /etc/fstab
UUID=5a5a9927-995f-4f0f-98ff-d222561f84ff /mnt/externaldisk1 ext4
relatime,noauto,user 0 2
and are (un-)mounted by the backup-user at amanda runtime.
-
The 7 chg-disk changers are aggregated into one "tpchanger" via
chg-aggregate:
define changer aggregate {
tpchanger "chg-aggregate:{disk1,disk2,disk3,disk4,disk5,disk6,disk7}"
property "state_filename" "/etc/amanda/vtape/aggregate.stats"
property "allow-missing-changer" "yes"
}
And that one is used via:
tpchanger "aggregate"
- The "design goal" here was:
an employee should swap the usb-disk every week.
Amanda should rotate vtapes on one disk if they forget to change the disk.
Amanda should use vtapes on each external disk, regardless which disk is
attached.
That works OK.
Right now it's only that issue around "why aren't existing vtapes
recognized and used?".
--
I also have this:
define taperscan "lexi" {
plugin "lexical"
#plugin "traditional"
}
DEFINE STORAGE vtape {
TPCHANGER "aggregate"
LABELSTR"vtape-[0-9]*-[0-9]*"
TAPEPOOL"vtape"
RUNTAPES2
TAPERSCAN "lexi"
TAPETYPE"vtape"
TAPERALGO FIRSTFIT
storage "vtape"
Maybe redundant, I don't know.
-
The tapetype used:
define tapetype vtape {
comment "Dump onto hard disk"
length 160 GB
part-size 1 GB
part-cache-type memory
}
Re: debian 11, vtapes not found correctly anymore
Am 12.04.22 um 17:57 schrieb Jose M Calhariz: Hi, To tell that I have 1 instalation of amanda in Debian 11 with vtapes working flawless. Can we share the setup? Sure, I'd appreciate that. I have several vtape-installations working OK, it seems that the special config with aggregating 2 or more chg-disk-changers is the problem here. I will post such a config in the next hour.
Re: debian 11, vtapes not found correctly anymore
Hi, To tell that I have 1 instalation of amanda in Debian 11 with vtapes working flawless. Can we share the setup? Kind regards Jose M Calhariz On Tue, Apr 12, 2022 at 10:22:38AM +0200, Stefan G. Weichinger wrote: > Am 05.04.22 um 14:39 schrieb Stefan G. Weichinger: > > > > At two amanda-installations on Debian11 I see this lately: > > > > both setups use an aggregate setup of multiple external usb disks with > > vtapes on them. > > > > That worked well for years. > > > > Now I get errors because amanda does not find valid tapes on one or more > > external disks. > > > > "amtape config inventory" shows the vtapes, but "amcheck -t config" > > tells me "No acceptable volumes found". > > > > If I relabel a tape "amlabel -f vtape_usb vtape_usb-002-004 slot 1:4" > > it gets detected again: > > > > $ amcheck -t vtape_usb > > Amanda Tape Server Host Check > > - > > mount: /mnt/externaldisk01: can't find > > UUID=98cb03d6-e95e-462d-a823-6011b37c9f42. > > slot 1:4: volume 'vtape_usb-002-004' > > Will write to volume 'vtape_usb-002-004' in slot 1:4. > > NOTE: skipping tape-writable test > > Server check took 6.673 seconds > > (brought to you by Amanda 3.5.1) > > > > > > (externaldisk01 is absent: OK, externaldisk02 is connected) > > > > I assume I should grep through some debug logs. What and where to look for? > > Still seeing these issues. I have to relabel every day, that is not the way > a backup setup should work like. > > See this tapelist, I wonder about that META column. > > /etc/amanda/vtape_usb/tapelist > 20220412084458 vtape_usb-002-006 reuse META:vtape_usb-003 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220411123301 vtape_usb-002-017 reuse META:vtape_usb-003 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220408224501 vtape_usb-002-016 reuse META:vtape_usb-003 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220408224501 vtape_usb-002-015 reuse META:vtape_usb-003 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220407224501 vtape_usb-002-014 reuse META:vtape_usb-003 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220407073600 vtape_usb-002-013 reuse META:vtape_usb-003 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220405224501 vtape_usb-002-005 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220405224501 vtape_usb-002-004 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220405132318 vtape_usb-002-003 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220405120227 vtape_usb-002-001 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220321224501 vtape_usb-002-012 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220320224501 vtape_usb-002-011 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220320224501 vtape_usb-002-010 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220319224501 vtape_usb-002-009 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220319224501 vtape_usb-002-008 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220318224501 vtape_usb-002-007 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > > > what about that meta label? > > Is it a problem that it is duplicate? > > > > > -- -- Conheci no Brasil a miséria rica. Hoje, conheço a riqueza miserável --Adolpho Bloch signature.asc Description: PGP signature
Re: debian 11, vtapes not found correctly anymore
Am 05.04.22 um 14:39 schrieb Stefan G. Weichinger: At two amanda-installations on Debian11 I see this lately: both setups use an aggregate setup of multiple external usb disks with vtapes on them. That worked well for years. Now I get errors because amanda does not find valid tapes on one or more external disks. "amtape config inventory" shows the vtapes, but "amcheck -t config" tells me "No acceptable volumes found". If I relabel a tape "amlabel -f vtape_usb vtape_usb-002-004 slot 1:4" it gets detected again: $ amcheck -t vtape_usb Amanda Tape Server Host Check - mount: /mnt/externaldisk01: can't find UUID=98cb03d6-e95e-462d-a823-6011b37c9f42. slot 1:4: volume 'vtape_usb-002-004' Will write to volume 'vtape_usb-002-004' in slot 1:4. NOTE: skipping tape-writable test Server check took 6.673 seconds (brought to you by Amanda 3.5.1) (externaldisk01 is absent: OK, externaldisk02 is connected) I assume I should grep through some debug logs. What and where to look for? Still seeing these issues. I have to relabel every day, that is not the way a backup setup should work like. See this tapelist, I wonder about that META column. /etc/amanda/vtape_usb/tapelist 20220412084458 vtape_usb-002-006 reuse META:vtape_usb-003 BLOCKSIZE:32 POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb 20220411123301 vtape_usb-002-017 reuse META:vtape_usb-003 BLOCKSIZE:32 POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb 20220408224501 vtape_usb-002-016 reuse META:vtape_usb-003 BLOCKSIZE:32 POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb 20220408224501 vtape_usb-002-015 reuse META:vtape_usb-003 BLOCKSIZE:32 POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb 20220407224501 vtape_usb-002-014 reuse META:vtape_usb-003 BLOCKSIZE:32 POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb 20220407073600 vtape_usb-002-013 reuse META:vtape_usb-003 BLOCKSIZE:32 POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb 20220405224501 vtape_usb-002-005 reuse META:vtape_usb-002 BLOCKSIZE:32 POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb 20220405224501 vtape_usb-002-004 reuse META:vtape_usb-002 BLOCKSIZE:32 POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb 20220405132318 vtape_usb-002-003 reuse META:vtape_usb-002 BLOCKSIZE:32 POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb 20220405120227 vtape_usb-002-001 reuse META:vtape_usb-002 BLOCKSIZE:32 POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb 20220321224501 vtape_usb-002-012 reuse META:vtape_usb-002 BLOCKSIZE:32 POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb 20220320224501 vtape_usb-002-011 reuse META:vtape_usb-002 BLOCKSIZE:32 POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb 20220320224501 vtape_usb-002-010 reuse META:vtape_usb-002 BLOCKSIZE:32 POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb 20220319224501 vtape_usb-002-009 reuse META:vtape_usb-002 BLOCKSIZE:32 POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb 20220319224501 vtape_usb-002-008 reuse META:vtape_usb-002 BLOCKSIZE:32 POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb 20220318224501 vtape_usb-002-007 reuse META:vtape_usb-002 BLOCKSIZE:32 POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb what about that meta label? Is it a problem that it is duplicate?
