[SOLVED] Tape as member of two pools simultaneously

[jamarsa]

Hi, I have a curious situation with a tape. It was a member of a pool of 10 tapes, but it gave me some error in the process of being written additional backups. So I formatted it to remove from the pool, and labelled as member of a second pool for the purpose of testing.


In the Inventory tab it shows as member of only the second pool.
But in the changer page, it is flipping as member of the old pool and member of the new one:


I have tried again to format and relabel it, to no avail. Also tried to change status, but when it's marked as full, it's not possible to mark it again as writable.
Is there any solution to this?

PS: I forgot to specify that the version of PBS is 2.4-2.

 

[dcsapak]

But in the changer page, it is flipping as member of the old pool and member of the new one:

did you press 'reload' after formatting and relabeling?

the second screenshot looks correct? 00..2L8 as writable in the pool 'Test-Cintas'

can you provide the output of the command:

proxmox-tape media list

?

 

[jamarsa]

Hello, thanks for your answer. Yes, I hit the reload button. Repeatedly... . Sort of a full inventory (that I'm hesitant to do as I think it involves a reading of all the tapes), I don't know what else to do, except maybe a proxmox-tape media destroy 000002L8.
This is the ouput of proxmox-tape media list (it shows twice the affected tape)

│ label-text │ pool │ media-set-name │ seq-nr │ status │ location │ catalog │ uuid │ media-set-uuid │
│ I00002L8 │ EXTERNAL_ALT │ Mon Dec 11 10:52:05 2023 │ 0 │ writable │ offline │ ok │ b907d079-36bf-4e20-a234-377bdffdb200 │ 069b3381-cff2-40e6-824b-4fb8c93166f5 │
│ I00003L8 │ IGARLE │ Sun Dec 3 21:39:36 2023 │ 0 │ writable │ offline │ ok │ 5a68c626-6078-4655-8457-f378d6c18fda │ 97a87f4f-d071-4222-95cd-7efac8cb2729 │
│ 100001L8 │ IGARLE │ Fri Aug 27 16:09:55 2021 │ 0 │ retired │ vault-REFORMATTED │ ok │ d8e91174-9c16-4368-a27f-ca8dd0b5cee7 │ c285e92a-cf43-4714-a01b-c043fc07cf46 │
│ I00001L8 │ IGARLE │ Wed Oct 6 17:59:40 2021 │ 0 │ damaged │ offline │ ok │ 1c38f56f-0c6b-4ee2-ac90-f0ca7f45de7b │ e845b86a-3b33-4cd7-9193-6b86fd316fb5 │
│ 000040L8 │ LTFS │ │ │ writable │ online-DE56400835_LL01 │ ok │ 3177e17c-38ec-404c-8a00-cbde2c82373a │ │ 000005L8 │ RACKIMATEL │ Fri Apr 1 08:16:44 2022 │ 0 │ full │ online-DE56400835_LL01 │ ok │ 1496b8bd-f967-4ff4-a3a4-f6c72cf7bb55 │ 0a9f1c2f-21b0-4514-8fc4-29ef21a62154 │
│ 000006L8 │ RACKIMATEL │ Fri Jul 1 10:09:49 2022 │ 0 │ full │ online-DE56400835_LL01 │ ok │ 99ee69a7-955d-4142-bd69-cfdcefaf857c │ 7f6477cb-7668-48a9-8c9b-11c6a3f75d13 │
│ 000007L8 │ RACKIMATEL │ Fri Jul 1 10:09:49 2022 │ 1 │ full │ online-DE56400835_LL01 │ ok │ b1e51150-73a6-4c3a-9617-1295bf9635c5 │ 7f6477cb-7668-48a9-8c9b-11c6a3f75d13 │
│ 000008L8 │ RACKIMATEL │ Fri Jul 1 10:09:49 2022 │ 2 │ full │ online-DE56400835_LL01 │ ok │ c63b0d42-fb60-4f37-9f36-9e3aba7c29c6 │ 7f6477cb-7668-48a9-8c9b-11c6a3f75d13 │
│ 000009L8 │ RACKIMATEL │ Fri Jul 1 10:09:49 2022 │ 3 │ full │ online-DE56400835_LL01 │ ok │ a211904f-ad7f-44fd-a14a-364c1add4a48 │ 7f6477cb-7668-48a9-8c9b-11c6a3f75d13 │
│ 000010L8 │ RACKIMATEL │ Fri Jul 1 10:09:49 2022 │ 4 │ full │ online-DE56400835_LL01 │ ok │ 8114fb53-c2bf-41ae-8748-875602044f70 │ 7f6477cb-7668-48a9-8c9b-11c6a3f75d13 │
│ 000003L8 │ RACKIMATEL │ Fri Jul 1 10:09:49 2022 │ 5 │ full │ online-DE56400835_LL01 │ ok │ 90c6399a-0974-429b-8d6f-0ee45de74d0b │ 7f6477cb-7668-48a9-8c9b-11c6a3f75d13 │
│ 000002L8 │ RACKIMATEL │ Fri Jul 1 10:09:49 2022 │ 6 │ full │ online-DE56400835_LL01 │ ok │ a43b73ef-664f-40b2-945a-bda9a8777420 │ 7f6477cb-7668-48a9-8c9b-11c6a3f75d13 │
│ 000001L8 │ RACKIMATEL │ Fri Jul 1 10:09:49 2022 │ 7 │ full │ online-DE56400835_LL01 │ ok │ 1806f960-eda8-49c0-9910-aeeb9f8abf12 │ 7f6477cb-7668-48a9-8c9b-11c6a3f75d13 │
│ 000004L8 │ RACKIMATEL │ Fri Jul 1 10:09:49 2022 │ 8 │ writable │ online-DE56400835_LL01 │ ok │ bef3e5bc-3eef-46c8-bc32-8efefda3ac1c │ 7f6477cb-7668-48a9-8c9b-11c6a3f75d13 │
│ 000040L8 │ RACKIMATEL │ Sat Aug 28 00:00:01 2021 │ 0 │ retired │ offline │ ok │ 86e7350a-7bcd-4501-aefa-0a8be00cc654 │ cdc4f45b-d454-4798-a089-339a10a7a291 │
│ 000002L8 │ Test-Cintas │ │ │ writable │ offline │ ok │ b9a41275-f9f7-43bf-8a27-f2c0867ed130 │ │

 

[dcsapak]

can you load it into a drive and use the 'catalog' function? this should reread the actual labels on the tape and update the inventory accordingly

also you could try to to

proxmox-tape media destroy

to remove it completely from the inventory and recatalog it

 

[jamarsa]

The catalog operation didn't improve the situation. The tape keeps alternating (now inside the drive) between the two pools.

Now going to try the proxmox-tape media destroy 000002L8 --force... (because it insists that it contains data).
And now the flipping seems over. It remains as member of the second pool (only first pool membership deleted).


I'm going to try to write some data in that tape to see if PBS accepts it as member of Test-Cintas.
Many thanks!

 

[jamarsa]

Okay, it seems to work correctly. Good speed also, well, as expected because I'm backing up from a NVMe storage.

Marking thread as solved. Thanks again