Wann wurde die Batterie das letzte Mal getauscht?
Deine APC meint, die Batterie sei vom 1.1.2001. Stolzes Datum.
Die Kiste selbst ist auch eher Kategorie Methusalem.
Es behauptet auch: LASTXFER : Low line voltage.
Vielleicht tatsächlich Schwankungen im Stromnetz?
Der Eimer kostet neu keine 100€. Ein Batteriewechsel wird kaum günstiger sein.
An dem Ding scheinen 410W zu zerren. Auch amtlich für eine etwas bessere Powerbank.

Die USV ist erst ca. ein halbes Jahr alt. Die Batterie ist völlig in Ordnung und es wird ja auch der Ladezustand angezeigt und richtig aktualisiert.
Es liegt 100 % -ig nicht an der USV!

Woher weiß ich das?
Es hat alles bist zum letzten bzw. vorletzten Update von Proxmox funktioniert.

Und!
ich habe die USV an einen Laptop mit Linux mint gehängt. Damit hat alles fehlerfrei funktioniert.

Reset der USV, Kabel, andere USB Buchse, alles schon probiert.
Ich werde jetzt noch mal gegenprüfen mit einer älteren Proxmox Installation.
Bin mir aber sicher, dass es keine neuen Ergebnisse bringt, hier müssen die Entwickler ran ;-)

EDIT: hier mal die Ausgaben am Laptop, selbe USV:

root@M6400:/# uname -a
Linux M6400 6.8.0-111-generic #111-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 11 23:16:02 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
root@M6400:/# apcupsd -V
apcupsd 3.14.14 (31 May 2016) debian
root@M6400:/# apcaccess status
APC      : 001,035,0852
DATE     : 2026-05-01 19:34:27 +0200 
HOSTNAME : M6400
VERSION  : 3.14.14 (31 May 2016) debian
UPSNAME  : M6400
CABLE    : USB Cable
DRIVER   : USB UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2026-05-01 19:32:43 +0200 
MODEL    : Back-UPS BX750MI
STATUS   : ONLINE
LINEV    : 234.0 Volts
LOADPCT  : 4.0 Percent
BCHARGE  : 100.0 Percent
TIMELEFT : 65.3 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
SENSE    : Low
LOTRANS  : 145.0 Volts
HITRANS  : 295.0 Volts
ALARMDEL : 30 Seconds
BATTV    : 13.6 Volts
LASTXFER : Low line voltage
NUMXFERS : 0
TONBATT  : 0 Seconds
CUMONBATT: 0 Seconds
XOFFBATT : N/A
SELFTEST : NG
STATFLAG : 0x05000008
SERIALNO : 9B2516A07157
BATTDATE : 2001-01-01
NOMINV   : 230 Volts
NOMBATTV : 12.0 Volts
NOMPOWER : 410 Watts
END APC  : 2026-05-01 19:34:27 +0200

Ich werde jetzt noch mal gegenprüfen mit einer älteren Proxmox Installation.

Das ist natürlich zum einkreisen genau richtig. Allerdings solltest du darauf achten, dieser Kontrollversion auch eine passende Last zu verpassen.
Wenn das Problem verschwindet, muss man tiefer graben. Bleibt es, dann hat man die APC-Kiste als Übeltäter identifiziert.

P.S.: Allerdings habe ich den Statusmails von APC noch nie richtig getraut. Erst wenn die Dinger höllisch piepsen, ruft jemand an bzw. wissen die Leute inzwischen, dass neue Akkus nötig sind. Das kann sogar jeder mittelbegabte Schimpanse ohne Unterbrechung.

Die Last ist ja geblieben. Ich habe nur das USB Kabel umgesteckt.

Bin auch gerade dabei mit einem älteren Proxmox Kernel zu testen. Es ist so wie ich es gesagt habe. Es liegt am Kernel.

Die 410 W sind die Nennleistung nicht die aktuelle Last.

Das ist aber alles nicht mein Problem.
Das goße Problem ist, dass die per Netzwerk verbundenen anderen Notes nicht mehr richtig funktionieren.
Auch das Herunterfahren bei Stromausfall zweifele ich gerade an, da eben die Komunikateion per USB nicht richtig mehr funktioniert.

EDIT:
Ich habe jetzt den Note an dem die USV per USB hängt mit einem älteren Kernel mittels "Grub Menü Erweitert" gestartet.
Was apcupsd angeht, scheint jetzt alles wieder zu laufen.
Das wäre erstmal eine temporäre Lösung, keine gute.

root@pve03:~# uname -a
Linux pve03 6.17.13-6-pve #1 SMP PREEMPT_DYNAMIC PMX 6.17.13-6 (2026-04-30T08:48Z) x86_64 GNU/Linux
root@pve03:~# apcaccess status
APC      : 001,035,0816
DATE     : 2026-05-01 20:48:34 +0200 
HOSTNAME : pve03
VERSION  : 3.14.14 (31 May 2016) debian
UPSNAME  : pve03
CABLE    : USB Cable
DRIVER   : USB UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2026-05-01 20:39:20 +0200 
MODEL    : Back-UPS BX750MI
STATUS   : ONLINE
LINEV    : 234.0 Volts
LOADPCT  : 4.0 Percent
BCHARGE  : 100.0 Percent
TIMELEFT : 65.3 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
SENSE    : Low
LOTRANS  : 145.0 Volts
HITRANS  : 295.0 Volts
ALARMDEL : 30 Seconds
BATTV    : 13.6 Volts
LASTXFER : Low line voltage
NUMXFERS : 0
TONBATT  : 0 Seconds
CUMONBATT: 0 Seconds
XOFFBATT : N/A
SELFTEST : NG
STATFLAG : 0x05000008
SERIALNO : 9B2516A07157
BATTDATE : 2001-01-01
NOMINV   : 230 Volts
NOMBATTV : 12.0 Volts
NOMPOWER : 410 Watts
END APC  : 2026-05-01 20:48:49 +0200

Wenn ich das richtig gegoogelt habe, ist apcupsd ein extra Paket.
Und wenn sourceforge noch stimmt wurde es seit Jahren nicht gepflegt.
Pakete hat Debian allerdings im Angebot.
Der 7er Kernel ist auch noch ganz frisch, da würde ich das verwenden eines 6er Kernels als unproblematisch ansehen.
Die Software vom Hersteller selber mal in Erwägung gezogen?

Der 7er Kernel ist auch noch ganz frisch, da würde ich das verwenden eines 6er Kernels als unproblematisch ansehen.

Deshalb halte ich es ja für wichtig, dass solche Fehler öffentlich diskutiert werden.
Ich bin guter Hoffnung, dass es irgendwann auch mit dem 7 -er Kernel funktioniert.

Event data for report 22 was too short (4 vs 2) weißt ja auf einen Fehler im USB Treiber hin und das wird auch andere Geräte treffen.

Die Software vom Hersteller selber mal in Erwägung gezogen?

Nein.
Ich weiß zwar, das es sehr lange nicht weiter entwickelt wurde aber wenn es fuktioniert und in Debian ist .....

Mit so Zusatzsoftware in Proxmox habe ich mir in der Vergangenheit immer nur Ärger eingehandelt (veeam)

Deshalb halte ich es ja für wichtig, dass solche Fehler öffentlich diskutiert werden.
Ich bin guter Hoffnung, dass es irgendwann auch mit dem 7 -er Kernel funktioniert.

Event data for report 22 was too short (4 vs 2) weißt ja auf einen Fehler im USB Treiber hin und das wird auch andere Geräte treffen.

Dann erstelle doch eine BUG Meldung : https://bugzilla.proxmox.com
Das wird dann eher nachverfolgt, als hier im Forum.
Wenn das ein Kernel Problem im neuen 7er ist, wäre Kernel.org auch die richtige Anlaufstelle für eine BUG Meldung.
Allerdings müsste der Code für die Software - trotz der langen Jahre nicht gepflegt - nicht die Quelle des Problems sein -> Entwickler informieren!

Wenn ich das richtig gegoogelt habe, ist apcupsd ein extra Paket.
Und wenn sourceforge noch stimmt wurde es seit Jahren nicht gepflegt.
Pakete hat Debian allerdings im Angebot.
Der 7er Kernel ist auch noch ganz frisch, da würde ich das verwenden eines 6er Kernels als unproblematisch ansehen.
Die Software vom Hersteller selber mal in Erwägung gezogen?

Der Versionswirrwarr ist schon erstaunlich. Meine Kiste(n) melden folgendes:

root@pve:~# apcupsd -V
apcupsd 3.14.14 (31 May 2016) debian
root@pve:~# apt list | grep apcupsd

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

apcupsd-cgi/stable,now 3.14.14-5 amd64  [installiert]
apcupsd-doc/stable,now 3.14.14-5 all  [Installiert,automatisch]
apcupsd/stable,now 3.14.14-5 amd64  [installiert]

Wenn man auf die Maintainerseite schaut, wird das Ding durchaus aktiv gepflegt/integriert. Siehe
https://tracker.debian.org/pkg/apcupsd
Da scheint mir auch die beste Anlaufstelle zu liegen

Jedenfalls meldet apcupsd selbst 3.14.14 vom 31.05.2016
apt meldet 3.14.14-5
und Thorsten Alteholz ist bei 3.14.14-7

Konsistenz geht anders.

Das ist ja deine Behauptung, ich würde es halt mal testen komme um einen stabilen Betrieb zu erhalten. Ich möchte ja dass meine Systeme funktionieren und nicht nur stundenlang oder wochenlang rum Doktoren. Der Aufwand ist ja recht gering auf einen kleinen Serverbetrieb umzustellen und wenn man schon so ein Raspberry Pi irgendeiner Art hat, dann geht das natürlich schnell zur Hand.

Es ist natürlich reine Notwehr bei einem alten Kernel zu bleiben und muss wie @jbeck66 schon erwähnte irgendwie ordentlich gefixt werden. Geht doch nicht an, dass der Berg dauerhaft zum Propheten kommt.

Die 3.14.14-7 ist im TESTING/UNSTABLE Zweig.
Insofern passt das dann schon ;-)

Ich wollte eher auf die 2016 Angabe hinaus, die fälschlicherweise totes Fleisch riechen lässt.
SW, die seit 2014 von Debian geliefert wird, ist ist debiantypisch nicht gerade brandneu.
Beim Umstieg von Kernel 6 auf 7 scheint es dringender zu werden 3.14.14-7 auszuliefern.
Dem Mann, der das Paket inzwischen betreut, kann man sowieso nur danken.
Wirr bleiben die Versionsangaben aber immer noch.

Ich habe das Paket grundsätzlich auf PVEs laufen und gucke womöglich in die Röhre.
Mein Antrieb, eine VM mit passendem Kernel zu betreiben und an diese dann ein USB-gerät durchzureichen, ist auch gering.
Nebenbei ist APC keine Garagenfirma und sollte sich über Maintainer freuen und entsprechend entlohnen.