Mir sind die Dateien am Wochenende aufgefallen, nachdem ein Backuptask zum zweitenmal mit "unable to aquire lock" hängenblieb.
Durch Recherche bin ich auf diesen Thread gestoßen:
https://forum.proxmox.com/threads/tape-backup-unable-to-acquire-lock-on-tape.112564/
Dann schaute ich bei meiner Maschine nach dem Ordner und fand 196 lockfiles (s.u.)
Ich habe ein Script auf der Maschine laufen, dass der API-Calls mehrere Dinge tut:
- Backuptasks beendet, sofern sie zu lange laufen (passiert eigentlich nicht, nur als absoluter fallback)
- Jeden ersten Freitag im Monat die Tapes in einem Pool retiren (siehe nächster Schritt)
- Freitags ein neues Tape im Pool daily_5_friday labeln, sofern alle anderen retired sind. (für Monatsbackup)
Das Script basiert auf einer PHP-library für PVE, welche eigentlich nur die dokumentierten Apicalls zur Verfügung stellt. Dieses habe ich für PBS angepaßt, da der Login dort leicht anders zu laufen scheint. Am Ende rufe ich aber auch nur die API-Calls auf, die in der offiziellen Doku stehen, die Dinge habe ich aber mittels Firefoxdebugger auch mit den GUI-Funktionen abgeglichen.
Kurzum: Die lck-Files scheinen schon eine ganze Weile dort zu liegen, ich würde sie normalerweise einfach löschen.
Die Frage, die mich nun umtreibt ist: Haben die irgendetwas mit der Retire/Expire-Funktionalität zu tun? D.h. würde ich mit dem Löschen der Lockfiles diese Infos zerstören? Oder sind die einfach nur dazu da, ein Medium während der Bearbeitung zu sperren und sollten eigentlich schon längst wieder gelöscht sein?
Falls Letzteres bliebe nur noch die Frage, wie die dorthin kommen. Diese kann ich letztlich nur beantworten, wenn ich den Ordner aufräume und dann schaue, wann wieder neue erstellt werden.
Code:
➜ tape la -al .*.lck
-rw-rw---- 1 backup backup 0 Mar 19 2022 .inventory.lck
-rw-rw---- 1 backup backup 0 Oct 10 10:49 .media-set-00000000-0000-0000-0000-000000000000.lck
-rw-rw---- 1 backup backup 0 Apr 25 2022 .media-set-0283c64c-01ee-44ca-9553-4d22579bf616.lck
-rw-rw---- 1 backup backup 0 Jun 23 17:49 .media-set-02d099ce-7d30-42f1-961b-980c7817bf32.lck
-rw-rw---- 1 backup backup 0 Aug 23 17:49 .media-set-02fd6139-7673-4a9c-ba77-58ed28b24232.lck
-rw-rw---- 1 backup backup 0 Jun 9 09:15 .media-set-03b5902e-18b1-4d6d-bc1f-976ecefde239.lck
[...]
-rw-rw---- 1 backup backup 0 Jun 22 17:50 .media-set-f8b64ec9-25bd-41b2-8612-65da4b482a3c.lck
-rw-rw---- 1 backup backup 0 Jun 13 17:49 .media-set-f9d256d3-d6fc-4d81-a9e7-cc510ccfe53c.lck
-rw-rw---- 1 backup backup 0 Jun 24 17:49 .media-set-fad0cee1-b60f-4137-92d8-1bd2e924ccf7.lck
-rw-rw---- 1 backup backup 0 Aug 8 17:49 .media-set-fc7e8384-1c6a-4b2c-ab28-ee083c1b3020.lck
-rw-rw---- 1 backup backup 0 Jul 29 17:50 .media-set-fd083a25-5ebe-41f5-bd1d-f410c0f01eb5.lck
-rw-rw---- 1 backup backup 0 Sep 15 17:49 .media-set-feba3935-0147-4e4a-a006-71cce2880871.lck
-rw-rw---- 1 backup backup 0 Jul 18 11:38 .media-set-ff89d4bf-72bf-4ee2-9af6-1d5360058d91.lck
-rw-rw---- 1 backup backup 0 Aug 3 17:50 .media-set-ffc13dfa-8cda-414f-9ff8-99aea870b551.lck
-rw-rw---- 1 backup backup 0 Jun 13 17:49 .pool-daily_1_monday.lck
-rw-rw---- 1 backup backup 0 Jun 14 17:49 .pool-daily_2_tuesday.lck
-rw-rw---- 1 backup backup 0 Jun 15 17:49 .pool-daily_3_wednesday.lck
-rw-rw---- 1 backup backup 0 Jun 16 17:50 .pool-daily_4_thursday.lck
-rw-rw---- 1 backup backup 0 Jun 17 17:50 .pool-daily_5_friday.lck
-rw-rw---- 1 backup backup 0 May 13 21:59 .pool-Daily_last.lck
-rw-rw---- 1 backup backup 0 Apr 22 2022 .pool-Daily.lck
-rw-rw---- 1 backup backup 0 Mar 19 2022 .pool-Full.lck
-rw-rw---- 1 backup backup 0 Mar 19 2022 .pool-__UNASSIGNED__.lck
➜