UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[JLeg]

@homoran

  Allocated pool data    2.22%
  Allocated metadata     0.51%

:+1:

[Homoran]

auch Unifi läuft wieder, aber die Installation ist ein Graus :-(

Dann kann ich ja morgen früh weg

[crunchip]

@homoran gibt nen fertigen Lxc, aber ich weiss, du bastelst lieber selbst
Und wieder kostbare Gb verschwendet😀
Aber hast ja jetzt ne doppelt so große Platte, da kann man sich das leisten 😁

[Homoran]

@crunchip sagte in Proxmox spinnt - brauche Hilfe - auch mit Unifi:

aber ich weiss, du bastelst lieber selbst

eigentlich schon, da weiß ich (???) was ich mache.
Aber Mongo hatte ich nicht ans Laufen bekommen dann musste ich doch auf ein all-in-one Installationsscript aus der Ubiquity-Community zugreifen.

und Container mag ich gar nicht

DANKE euch beiden nochmal für die Unterstützung

auch Edit:
@crunchip sagte in Proxmox spinnt - brauche Hilfe - auch mit Unifi:

Aber hast ja jetzt ne doppelt so große Platte, da kann man sich das leisten

und dann noch eine m2 :angel:

EDIT2
Ich fürchte da muss @simatec noch mal bei Backitup nachsehen.
im History-Adapter stand jetzt kein Pfad mehr drin.
Der hat definitiv vorher drin gestanden.

[crunchip]

@homoran sagte in Proxmox spinnt - brauche Hilfe - auch mit Unifi:

Das habe ich so gelesen, als ob sie selber starten wird und man darauf warten soll.

Stimmt, besser wäre, nachdem man die VM gestartet hat.....

Wenigstens haste aufmerksam gelesen👍

[simatec]

@homoran sagte in Proxmox spinnt - brauche Hilfe - auch mit Unifi:

Ich fürchte da muss @simatec noch mal bei Backitup nachsehen.
im History-Adapter stand jetzt kein Pfad mehr drin.
Der hat definitiv vorher drin gestanden.

Was meinst du genau?

[Homoran]

@simatec sagte in Proxmox spinnt - brauche Hilfe - auch mit Unifi:

Was meinst du genau?

bei der wiederhergestellten History Instanz war kein Pfad für das History Verzeichnis eingetragen, was beim restore des History Backups wahrscheinlich zu dieser Fehlermeldung führte:

[DEBUG] [historyDB] - Something is wrong. No file found.
[DEBUG] [historyDB] - Extracting History Backupfile...

ich bin mir aber sicher, dass dort früher ein Pfad eingetragen war

[simatec]

@homoran Der Pfad im History Adapter sollte aber im Backup enthalten sein.
Da hat backitup keinen Einfluss drauf.

Wenn da keiner drin steht, dann wird er auch im Backup fehlen

[Homoran]

@simatec Kann ich leider nnicht mehr verifizieren..
Aber die letzten "Jahrhunderte" haben backup und Restore immer funktioniert, was ohne Pfadangabe doch nicht klappt, oder?

Jetzt steht jedenfalls einer drin

[crunchip]

@homoran ich kann mich nur daran erinnern... als ich damals beim erstellen der History Backups Probleme hatte,
denn da stand mal bzw hieß es, wenn nichts eingetragen, dann wird der Standard Pfad verwendet, aufgrund des backitup muss da aber ein Pfad hinterlegt werden, ich hatte nämlich vorher auch nie was angegeben und wusste da gar nicht wo die abgelegt werden

[Homoran]

@crunchip Ja, so kenne ich das auch.
Und bei mir waren sie immer schon im Standardpfad, was ja nur funkioniert haben soll, wenn man diesen in der Instanz eingetragen hat.

:thinking_face:

[simatec]

In der aktuellen Version von backitup wird bei fehlenden Pfad der Standardpfad gesetzt

[Homoran]

@jleg
@crunchip

so richtig glücklich bin ich mit der VM-Größe aber nicht:

pi@iobroker-VM03:~$ df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev            2,0G       0  2,0G    0% /dev
tmpfs           394M    468K  393M    1% /run
/dev/sda1        62G     49G   11G   83% /
tmpfs           2,0G       0  2,0G    0% /dev/shm
tmpfs           5,0M       0  5,0M    0% /run/lock
tmpfs           394M       0  394M    0% /run/user/1000

Wie befürchtet:

--- /opt/iobroker/iobroker-data ----------------------------------------------------------------------------------------------------------------------------
                         /..
   44,9 GiB [##########] /history
  257,9 MiB [          ] /files
   37,2 MiB [          ] /backup-objects
   13,5 MiB [          ]  objects.json.bak
   13,5 MiB [          ]  objects.json
   10,1 MiB [          ]  states.json.bak
   10,1 MiB [          ]  states.json
    2,5 MiB [          ]  objects.jsonl
  112,0 KiB [          ]  states.jsonl
   16,0 KiB [          ] /backitup
    8,0 KiB [          ]  iobroker.json.bak
e   4,0 KiB [          ] /sayit
    4,0 KiB [          ]  iobroker.json
    4,0 KiB [          ]  notifications.json

45GB History!!!
und alles nur wegen des Bugs, dass nicht nur Änderungen gespeichert werden :-(

im Ernst:
das wird zwar auch eine "Teilschuld" haben, aber wie kann man History Daten einfach ausmisten?

[JLeg]

@Homoran

45GB History!!!
und alles nur wegen des Bugs, dass nicht nur Änderungen gespeichert werden :-(

im Ernst:
das wird zwar auch eine "Teilschuld" haben, aber wie kann man History Daten einfach ausmisten?

History habe ich nie benutzt - ich tät nach SQL oder Influx konvertieren, und dann den Ballast aus der DB löschen…

Alternativ der VM nochmal 40Gb spendieren, und damit Zeit erkaufen… 🤓 (vergrössern geht ja einfach im laufenden Betrieb)

[crunchip]

@homoran naja, 45 GB is schon ne Hausnummer, vorhin war noch die Rede von 32.

Ich hatte zwar auch innerhalb von paar Monaten 30 GB zusammen, geschuldet war allerdings, das ich die kompletten Unifi Netzwerkdaten in die Datenbank schreibe.

@homoran sagte in Proxmox spinnt - brauche Hilfe - auch mit Unifi:

aber wie kann man History Daten einfach ausmisten

das ist ne gute und berechtigte Frage auf die ich keine Antwort habe

zumindest hast du aber noch ein paar GB Luft nach oben

[Homoran]

@jleg sagte in Proxmox spinnt - brauche Hilfe - auch mit Unifi:

Alternativ der VM nochmal 40Gb spendieren, und damit Zeit erkaufen…

Werde ich machen, da sind seit jetzt fast 2 Jahren teilweise hochauflösende loggings drin: im 6 Sekunden Takt meine Energie-Werte

Vor dem letzten Umzug habe ich immer monatlich die Log-Daten heruntergeladen und gelöscht
Danach wieder hinzugefügt.
reicht aber immer noch nicht wirklich

Mit Datenbanken kenne ich mich nur nicht aus :-(

@jleg sagte in Proxmox spinnt - brauche Hilfe - auch mit Unifi:

vergrössern geht ja einfach im laufenden Betrieb

Aber gParted nicht vergessen :-)

[crunchip]

@jleg sagte in Proxmox spinnt - brauche Hilfe - auch mit Unifi:

vergrössern geht ja einfach im laufenden Betrieb

da erheb ich aber Einspruch, das ist eine VM, kein LXC

Edit
hatte das früher hin und wieder mit ner live. iso gemacht
gerade gesehen, geht ja auch mit parted

[JLeg]

@crunchip sagte in Proxmox spinnt - brauche Hilfe - auch mit Unifi:

@jleg sagte in Proxmox spinnt - brauche Hilfe - auch mit Unifi:

vergrössern geht ja einfach im laufenden Betrieb

da erheb ich aber Einspruch, das ist eine VM, kein LXC

Hm? Zumindest hier laufen die VMs ja auch auf LVMs. Da sollte das sogar per Proxmox-GUI gehen; ok, je nach Blockdevice könnte das unterschiedlich sein, aber normalerweise - wenn wir von Linux in der VM reden - kriegt der Kernel das ‚live‘ mit, hier eine entsprechende dmesg Meldung:

[21435028.096569] vda: detected capacity change from 34359738368 to 35433480192

Gut, resizen in der VM muss man natürlich auch noch 😬 - geht bei ‚üblichen‘ FS aber auch online; komplizierter wird‘s wenn die VM selbst noch partitioniert ist…

[Homoran]

@jleg ich hab es damals bereits gemacht.
geht über die Proxmox gui

danach musste man aber über ein gparted iso booten und die Partition vergrößern.

ich weiß nicht, ob das noch so ist. Wenn ja, ist es zwar nicht schön, aber machbar.

[JLeg]

@homoran sagte in Proxmox spinnt - brauche Hilfe - auch mit Unifi:

@jleg ich hab es damals bereits gemacht.
geht über die Proxmox gui

danach musste man aber über ein gparted iso booten und die Partition vergrößern.

ich weiß nicht, ob das noch so ist. Wenn ja, ist es zwar nicht schön, aber machbar.

ist normalerweise nicht nötig, bri LVM reichen eigentlich pvresize und lvextend:
https://www.networkshinobi.com/proxmox-linux-vm-template/