NEWS
Test Adapter ioBroker.backitup v3.1.x
-
Ab sofort steht auf Github und in kürze auch im latest die Version 2.4.3 zur Verfügung.
Changelog
2.4.3 (2022-03-29)
- (simatec) Bugfixes Dropbox
- (simatec) try/catch options added
- (simatec) code verifier check for Dropbox oAuth
-
Muss das mit sentry so?
backitup.0 11204 2022-03-30 08:03:04.496 info [iobroker] backup was activated at 02:00 every 1 day(s) backitup.0 11204 2022-03-30 08:03:04.237 debug Backitup has recognized a win32 system backitup.0 11204 2022-03-30 08:03:04.215 info starting. Version 2.4.2 in C:/iobroker/GLT/node_modules/iobroker.backitup, node: v14.16.0, js-controller: 4.0.21 backitup.0 11204 2022-03-30 08:03:03.857 debug Plugin sentry destroyed because not initialized correctly backitup.0 11204 2022-03-30 08:03:03.848 debug Plugin sentry Do not initialize Plugin (enabled=false) backitup.0 11204 2022-03-30 08:03:03.429 debug States connected to redis: 127.0.0.1:9000 backitup.0 11204 2022-03-30 08:03:03.340 debug States create User PubSub Client backitup.0 11204 2022-03-30 08:03:03.339 debug States create System PubSub Client backitup.0 11204 2022-03-30 08:03:03.310 debug Redis States: Use Redis connection: 127.0.0.1:9000 backitup.0 11204 2022-03-30 08:03:03.270 debug Objects connected to redis: 127.0.0.1:9001 backitup.0 11204 2022-03-30 08:03:03.264 debug Objects client initialize lua scripts backitup.0 11204 2022-03-30 08:03:03.158 debug Objects create User PubSub Client backitup.0 11204 2022-03-30 08:03:03.157 debug Objects create System PubSub Client backitup.0 11204 2022-03-30 08:03:03.156 debug Objects client ready ... initialize now backitup.0 11204 2022-03-30 08:03:03.110 debug Redis Objects: Use Redis connection: 127.0.0.1:9001ioBroker auf Intel Core i3-5005U NUC und Windwos10 Pro
-
Muss das mit sentry so?
backitup.0 11204 2022-03-30 08:03:04.496 info [iobroker] backup was activated at 02:00 every 1 day(s) backitup.0 11204 2022-03-30 08:03:04.237 debug Backitup has recognized a win32 system backitup.0 11204 2022-03-30 08:03:04.215 info starting. Version 2.4.2 in C:/iobroker/GLT/node_modules/iobroker.backitup, node: v14.16.0, js-controller: 4.0.21 backitup.0 11204 2022-03-30 08:03:03.857 debug Plugin sentry destroyed because not initialized correctly backitup.0 11204 2022-03-30 08:03:03.848 debug Plugin sentry Do not initialize Plugin (enabled=false) backitup.0 11204 2022-03-30 08:03:03.429 debug States connected to redis: 127.0.0.1:9000 backitup.0 11204 2022-03-30 08:03:03.340 debug States create User PubSub Client backitup.0 11204 2022-03-30 08:03:03.339 debug States create System PubSub Client backitup.0 11204 2022-03-30 08:03:03.310 debug Redis States: Use Redis connection: 127.0.0.1:9000 backitup.0 11204 2022-03-30 08:03:03.270 debug Objects connected to redis: 127.0.0.1:9001 backitup.0 11204 2022-03-30 08:03:03.264 debug Objects client initialize lua scripts backitup.0 11204 2022-03-30 08:03:03.158 debug Objects create User PubSub Client backitup.0 11204 2022-03-30 08:03:03.157 debug Objects create System PubSub Client backitup.0 11204 2022-03-30 08:03:03.156 debug Objects client ready ... initialize now backitup.0 11204 2022-03-30 08:03:03.110 debug Redis Objects: Use Redis connection: 127.0.0.1:9001@jb_sullivan Dann hast du sentry sicher für Backitup deaktiviert
-
@jb_sullivan Dann hast du sentry sicher für Backitup deaktiviert
Die Erfahrungen, die ich mit den Entwicklungen im ZigBee-Adapter gemacht habe, lassen mich aufschrecken. Ich frage mich, wie kann ich mein System so sichern, dass ich es exakt wiederherstellen kann?
Sehe ich das richtig, dass Backitup den Programmcode gar nicht sichert, sondern nur dessen Wiederherstellung, indem die benötigten Teile aus dem GitHub geladen werden? Jedenfalls erscheinen mir die erzeugten Backups viel zu klein.
Wenn, wie im ZigBee-Adapter geschehen, alte, noch funktionierende Versionen gar nicht mehr verfügbar sind, so sollte Backitup doch wohl beim Wiederherstellen scheitern.
Somit bliebe dann wohl nur, eine Software à la Apple Pi Baker zu verwenden, die ein eins-zu-eins Abbild des Speichermediums (SD, SSD) erstellt.
Schiebe ich unberechtigt Panik oder ist dem wirklich so, wie hier von mir vermutet?
Nach über vier Jahren Leidenszeit unter Qivicon/MSH vor den Telekomikern zu ioBroker geflüchtet.
Raspberry Pi 4 mit 8GB + ArgonOneM.2 + 120GB SSD + Coordinator CC26X2R1 + ioBroker + piVCCU3 -
Die Erfahrungen, die ich mit den Entwicklungen im ZigBee-Adapter gemacht habe, lassen mich aufschrecken. Ich frage mich, wie kann ich mein System so sichern, dass ich es exakt wiederherstellen kann?
Sehe ich das richtig, dass Backitup den Programmcode gar nicht sichert, sondern nur dessen Wiederherstellung, indem die benötigten Teile aus dem GitHub geladen werden? Jedenfalls erscheinen mir die erzeugten Backups viel zu klein.
Wenn, wie im ZigBee-Adapter geschehen, alte, noch funktionierende Versionen gar nicht mehr verfügbar sind, so sollte Backitup doch wohl beim Wiederherstellen scheitern.
Somit bliebe dann wohl nur, eine Software à la Apple Pi Baker zu verwenden, die ein eins-zu-eins Abbild des Speichermediums (SD, SSD) erstellt.
Schiebe ich unberechtigt Panik oder ist dem wirklich so, wie hier von mir vermutet?
@legro sagte in Test Adapter Backitup v2.4.x:
Jedenfalls erscheinen mir die erzeugten Backups viel zu klein.
Es wird (mehr oder weniger) der Bauplan gesichert, nicht das komplette Haus.
Das reicht auch eigentlich aus, gibt also keinen Grund irgendeine 'Panik' zu schieben. -
Die Erfahrungen, die ich mit den Entwicklungen im ZigBee-Adapter gemacht habe, lassen mich aufschrecken. Ich frage mich, wie kann ich mein System so sichern, dass ich es exakt wiederherstellen kann?
Sehe ich das richtig, dass Backitup den Programmcode gar nicht sichert, sondern nur dessen Wiederherstellung, indem die benötigten Teile aus dem GitHub geladen werden? Jedenfalls erscheinen mir die erzeugten Backups viel zu klein.
Wenn, wie im ZigBee-Adapter geschehen, alte, noch funktionierende Versionen gar nicht mehr verfügbar sind, so sollte Backitup doch wohl beim Wiederherstellen scheitern.
Somit bliebe dann wohl nur, eine Software à la Apple Pi Baker zu verwenden, die ein eins-zu-eins Abbild des Speichermediums (SD, SSD) erstellt.
Schiebe ich unberechtigt Panik oder ist dem wirklich so, wie hier von mir vermutet?
-
@legro sagte in Test Adapter Backitup v2.4.x:
Jedenfalls erscheinen mir die erzeugten Backups viel zu klein.
Es wird (mehr oder weniger) der Bauplan gesichert, nicht das komplette Haus.
Das reicht auch eigentlich aus, gibt also keinen Grund irgendeine 'Panik' zu schieben.Vielen Dank für eure Hinweise. Leider beruhigen sie mich nicht so sehr, wie ich es mir wünschen würde.
Wenn der Code der Adapter nicht im Backup gesichert wird, von wo wird dieser dann wiederhergestellt?
In dem oben verlinkten Beispiel zum ZigBee-Adapter für BITRON Sirenen war die letzte für meine Geräte noch funktionierende Version die 1.6.0. Nicht einmal die Entwickler hatten diese Version noch zur Hand. Woher nimmt BackItUp denn in diesem Fall den Programmcode?
Mittlerweile hat @Asgothian eine Testversion in seinem Fork auf GitHub bereitgestellt, mit der ich mein Alarmsystem aus BITRON Geräten wieder zum Laufen bekomme.
Nach über vier Jahren Leidenszeit unter Qivicon/MSH vor den Telekomikern zu ioBroker geflüchtet.
Raspberry Pi 4 mit 8GB + ArgonOneM.2 + 120GB SSD + Coordinator CC26X2R1 + ioBroker + piVCCU3 -
Vielen Dank für eure Hinweise. Leider beruhigen sie mich nicht so sehr, wie ich es mir wünschen würde.
Wenn der Code der Adapter nicht im Backup gesichert wird, von wo wird dieser dann wiederhergestellt?
In dem oben verlinkten Beispiel zum ZigBee-Adapter für BITRON Sirenen war die letzte für meine Geräte noch funktionierende Version die 1.6.0. Nicht einmal die Entwickler hatten diese Version noch zur Hand. Woher nimmt BackItUp denn in diesem Fall den Programmcode?
Mittlerweile hat @Asgothian eine Testversion in seinem Fork auf GitHub bereitgestellt, mit der ich mein Alarmsystem aus BITRON Geräten wieder zum Laufen bekomme.
@legro sagte in Test Adapter Backitup v2.4.x:
Wenn der Code der Adapter nicht im Backup gesichert wird, von wo wird dieser dann wiederhergestellt?
Aus den Repositories.
-
Vielen Dank für eure Hinweise. Leider beruhigen sie mich nicht so sehr, wie ich es mir wünschen würde.
Wenn der Code der Adapter nicht im Backup gesichert wird, von wo wird dieser dann wiederhergestellt?
In dem oben verlinkten Beispiel zum ZigBee-Adapter für BITRON Sirenen war die letzte für meine Geräte noch funktionierende Version die 1.6.0. Nicht einmal die Entwickler hatten diese Version noch zur Hand. Woher nimmt BackItUp denn in diesem Fall den Programmcode?
Mittlerweile hat @Asgothian eine Testversion in seinem Fork auf GitHub bereitgestellt, mit der ich mein Alarmsystem aus BITRON Geräten wieder zum Laufen bekomme.
@legro Deine Aussage kann ich nicht nachvollziehen.
Alle Versionen liegen auf npm und du kannst diese jederzeit installieren -
@legro Deine Aussage kann ich nicht nachvollziehen.
Alle Versionen liegen auf npm und du kannst diese jederzeit installierenIrgendwie habe ich das Gefühl, dass wir aneinander vorbei argumentieren.
Das von mir ins Spiel gebrachte Beispiel hätte die Wiederstellung des ZigBee Adapters zurück auf die Version 1.6.0 erfordert. Aber diese ist anscheinend nicht mehr verfügbar zu sein.
Für mich sieht das noch immer so aus, dass man die Wahl zwischen zwei Optionen hat, wobei jede ihre ureigenen Vor- und Nachteile zu haben scheint. Verwende ich etwa Apple Pi Baker, so wird auch der Programmcode eingefroren und bei der Wiederherstellung gehen mir dafür alle zwischenzeitlich angefallenen Daten, Einstellungen und Konfigurationen verloren. Hingegen bleiben mir bei BackItUp alle Daten, Konfigurationen und Einstellungen erhalten, dafür geht jedoch alte Programmcode verloren.
Oder sehe ich bloß noch immer keinen Weg, wie ich die hier von mir befürchteten Nachteile vermeiden kann? Derzeit fahre ich daher zweigleisig: Ich verwende BackItUp und ApplePiBaker.
Um bei meinem Dilemma zu bleiben: Leider habe ich kein Backup mit ZigBee 1.6.0 aufbewahrt )weder von BackItUp noch von ApplePiBaker), sodass ich das hätte ausprobieren können.
Nach über vier Jahren Leidenszeit unter Qivicon/MSH vor den Telekomikern zu ioBroker geflüchtet.
Raspberry Pi 4 mit 8GB + ArgonOneM.2 + 120GB SSD + Coordinator CC26X2R1 + ioBroker + piVCCU3 -
Irgendwie habe ich das Gefühl, dass wir aneinander vorbei argumentieren.
Das von mir ins Spiel gebrachte Beispiel hätte die Wiederstellung des ZigBee Adapters zurück auf die Version 1.6.0 erfordert. Aber diese ist anscheinend nicht mehr verfügbar zu sein.
Für mich sieht das noch immer so aus, dass man die Wahl zwischen zwei Optionen hat, wobei jede ihre ureigenen Vor- und Nachteile zu haben scheint. Verwende ich etwa Apple Pi Baker, so wird auch der Programmcode eingefroren und bei der Wiederherstellung gehen mir dafür alle zwischenzeitlich angefallenen Daten, Einstellungen und Konfigurationen verloren. Hingegen bleiben mir bei BackItUp alle Daten, Konfigurationen und Einstellungen erhalten, dafür geht jedoch alte Programmcode verloren.
Oder sehe ich bloß noch immer keinen Weg, wie ich die hier von mir befürchteten Nachteile vermeiden kann? Derzeit fahre ich daher zweigleisig: Ich verwende BackItUp und ApplePiBaker.
Um bei meinem Dilemma zu bleiben: Leider habe ich kein Backup mit ZigBee 1.6.0 aufbewahrt )weder von BackItUp noch von ApplePiBaker), sodass ich das hätte ausprobieren können.
iobroker upgrade adaptername@versionsnummerschaufelt dir eine genaue Version auf das System.
-
Irgendwie habe ich das Gefühl, dass wir aneinander vorbei argumentieren.
Das von mir ins Spiel gebrachte Beispiel hätte die Wiederstellung des ZigBee Adapters zurück auf die Version 1.6.0 erfordert. Aber diese ist anscheinend nicht mehr verfügbar zu sein.
Für mich sieht das noch immer so aus, dass man die Wahl zwischen zwei Optionen hat, wobei jede ihre ureigenen Vor- und Nachteile zu haben scheint. Verwende ich etwa Apple Pi Baker, so wird auch der Programmcode eingefroren und bei der Wiederherstellung gehen mir dafür alle zwischenzeitlich angefallenen Daten, Einstellungen und Konfigurationen verloren. Hingegen bleiben mir bei BackItUp alle Daten, Konfigurationen und Einstellungen erhalten, dafür geht jedoch alte Programmcode verloren.
Oder sehe ich bloß noch immer keinen Weg, wie ich die hier von mir befürchteten Nachteile vermeiden kann? Derzeit fahre ich daher zweigleisig: Ich verwende BackItUp und ApplePiBaker.
Um bei meinem Dilemma zu bleiben: Leider habe ich kein Backup mit ZigBee 1.6.0 aufbewahrt )weder von BackItUp noch von ApplePiBaker), sodass ich das hätte ausprobieren können.
@legro Zur Info es gibt immer die Commits zum Projekt, auch von v1.6.0:
Welches man nutzen muss, um die v1.6.0 zurückzusichern, muss man probieren. Sie ist auf jeden Fall da.
Stimmt:npm show iobroker.zigbee versions [ '0.5.0', '0.5.2', '0.5.3', '0.5.4', '0.5.5', '0.5.6', '0.5.7', '0.5.8', '0.6.0', '0.7.0', '0.7.1', '0.7.3', '0.7.5', '0.7.6', '0.7.7', '0.8.0', '0.9.0', '0.9.1', '0.9.2', '0.10.0', '0.10.1', '0.10.2', '0.10.3', '0.11.0', '0.11.1', '0.11.2', '0.11.3', '0.11.5', '1.0.0', '1.0.1', '1.0.2', '1.0.3', '1.0.4', '1.1.0', '1.1.1', '1.2.0', '1.2.1', '1.3.0', '1.3.1', '1.4.0', '1.4.1', '1.4.2', '1.4.4', '1.5.0', '1.5.1', '1.5.2', '1.5.3', '1.5.5', '1.5.6', '1.6.0', '1.6.3', '1.6.6', '1.6.8', '1.6.12', '1.6.14', '1.6.15', '1.6.16' -
Irgendwie habe ich das Gefühl, dass wir aneinander vorbei argumentieren.
Das von mir ins Spiel gebrachte Beispiel hätte die Wiederstellung des ZigBee Adapters zurück auf die Version 1.6.0 erfordert. Aber diese ist anscheinend nicht mehr verfügbar zu sein.
Für mich sieht das noch immer so aus, dass man die Wahl zwischen zwei Optionen hat, wobei jede ihre ureigenen Vor- und Nachteile zu haben scheint. Verwende ich etwa Apple Pi Baker, so wird auch der Programmcode eingefroren und bei der Wiederherstellung gehen mir dafür alle zwischenzeitlich angefallenen Daten, Einstellungen und Konfigurationen verloren. Hingegen bleiben mir bei BackItUp alle Daten, Konfigurationen und Einstellungen erhalten, dafür geht jedoch alte Programmcode verloren.
Oder sehe ich bloß noch immer keinen Weg, wie ich die hier von mir befürchteten Nachteile vermeiden kann? Derzeit fahre ich daher zweigleisig: Ich verwende BackItUp und ApplePiBaker.
Um bei meinem Dilemma zu bleiben: Leider habe ich kein Backup mit ZigBee 1.6.0 aufbewahrt )weder von BackItUp noch von ApplePiBaker), sodass ich das hätte ausprobieren können.
-
iobroker upgrade adaptername@versionsnummerschaufelt dir eine genaue Version auf das System.
@thomas-braun said in Test Adapter Backitup v2.4.x:
iobroker upgrade adaptername@versionsnummerschaufelt dir eine genaue Version auf das System.
Vielen Dank für deinen Hinweis. Genau dies hatte ich jedoch ohne Erfolg versucht und dachte daher, dass die Version 1.6.0 tatsächlich nicht mehr verfügbar ist - zumal sogar Artec und Asgothian meinten, dass diese Versionen nicht mehr verfügbar seien.:confused:
Das System scheint so seine Tücken zu haben. Die von @Asgothian in seinem Fork auf GitHub zu Verfügung gestellte Beta (1.6.17) ließ sich auch zunächst nicht installieren; erst der dritte Versuch führte zum Erfolg.
Zur Sicherheit habe ich nun meine npm Version von 6.14.15 auf 8.6.0 aktualisiert.
Nach über vier Jahren Leidenszeit unter Qivicon/MSH vor den Telekomikern zu ioBroker geflüchtet.
Raspberry Pi 4 mit 8GB + ArgonOneM.2 + 120GB SSD + Coordinator CC26X2R1 + ioBroker + piVCCU3 -
@thomas-braun said in Test Adapter Backitup v2.4.x:
iobroker upgrade adaptername@versionsnummerschaufelt dir eine genaue Version auf das System.
Vielen Dank für deinen Hinweis. Genau dies hatte ich jedoch ohne Erfolg versucht und dachte daher, dass die Version 1.6.0 tatsächlich nicht mehr verfügbar ist - zumal sogar Artec und Asgothian meinten, dass diese Versionen nicht mehr verfügbar seien.:confused:
Das System scheint so seine Tücken zu haben. Die von @Asgothian in seinem Fork auf GitHub zu Verfügung gestellte Beta (1.6.17) ließ sich auch zunächst nicht installieren; erst der dritte Versuch führte zum Erfolg.
Zur Sicherheit habe ich nun meine npm Version von 6.14.15 auf 8.6.0 aktualisiert.
@legro sagte in Test Adapter Backitup v2.4.x:
Zur Sicherheit habe ich nun meine npm Version von 6.14.15 auf 8.6.0 aktualisiert.
Das ist nicht die beste Idee.
Am besten die Version von npm verwenden, die auch für die nodeJS-Version vorgesehen ist und auch mit im Paket von nodesource liegt. -
@legro Zur Info es gibt immer die Commits zum Projekt, auch von v1.6.0:
Welches man nutzen muss, um die v1.6.0 zurückzusichern, muss man probieren. Sie ist auf jeden Fall da.
Stimmt:npm show iobroker.zigbee versions [ '0.5.0', '0.5.2', '0.5.3', '0.5.4', '0.5.5', '0.5.6', '0.5.7', '0.5.8', '0.6.0', '0.7.0', '0.7.1', '0.7.3', '0.7.5', '0.7.6', '0.7.7', '0.8.0', '0.9.0', '0.9.1', '0.9.2', '0.10.0', '0.10.1', '0.10.2', '0.10.3', '0.11.0', '0.11.1', '0.11.2', '0.11.3', '0.11.5', '1.0.0', '1.0.1', '1.0.2', '1.0.3', '1.0.4', '1.1.0', '1.1.1', '1.2.0', '1.2.1', '1.3.0', '1.3.1', '1.4.0', '1.4.1', '1.4.2', '1.4.4', '1.5.0', '1.5.1', '1.5.2', '1.5.3', '1.5.5', '1.5.6', '1.6.0', '1.6.3', '1.6.6', '1.6.8', '1.6.12', '1.6.14', '1.6.15', '1.6.16'@mcu said in Test Adapter Backitup v2.4.x:
@legro Zur Info es gibt immer die Commits zum Projekt, auch von v1.6.0:
Wo finde ich diese?
Welches man nutzen muss, um die v1.6.0 zurückzusichern, muss man probieren. Sie ist auf jeden Fall da.
Bei meinem aktuellen Problem war's wohl so, dass im zigbee-herdsman-converters: 14.0.422 als auch zigbee-herdsman: 0.14.16 Veränderungen vorgenommen wurden, die dazu führten, dass meine BITRON Rauchmelder und Sirenen nicht mehr funktionierten. Da kam dann bei mir Panik auf, ganz ohne Alarmsystem wollte ich dann doch nicht sein.
npm show iobroker.zigbee versions
Dank deines Tipps kann ich in Zukunft solche Dinge beruhigter angehen.:+1:
Nach über vier Jahren Leidenszeit unter Qivicon/MSH vor den Telekomikern zu ioBroker geflüchtet.
Raspberry Pi 4 mit 8GB + ArgonOneM.2 + 120GB SSD + Coordinator CC26X2R1 + ioBroker + piVCCU3 -
@mcu said in Test Adapter Backitup v2.4.x:
@legro Zur Info es gibt immer die Commits zum Projekt, auch von v1.6.0:
Wo finde ich diese?
Welches man nutzen muss, um die v1.6.0 zurückzusichern, muss man probieren. Sie ist auf jeden Fall da.
Bei meinem aktuellen Problem war's wohl so, dass im zigbee-herdsman-converters: 14.0.422 als auch zigbee-herdsman: 0.14.16 Veränderungen vorgenommen wurden, die dazu führten, dass meine BITRON Rauchmelder und Sirenen nicht mehr funktionierten. Da kam dann bei mir Panik auf, ganz ohne Alarmsystem wollte ich dann doch nicht sein.
npm show iobroker.zigbee versions
Dank deines Tipps kann ich in Zukunft solche Dinge beruhigter angehen.:+1:
-
@diwoma Kannst du mir mal zeigen, was du für einen Fehlerlog bei Start der Slave Instanz bekommst.
Ich bin gerade mit den Entwicklern der dropbox Api am schreiben.Hier wurde etwas umgestellt, was irgendwie murks ist. Der Token ist bei neuen Apps nur noch "short_live".
Das bedeutet aktuell hat der Token nur noch 4 Stunden Gültigkeit.Ich bin auf Lösungssuche ... aber das dauert noch.
Wenn du aber erstmal schnell die Lösung benötigst, dann sichere dir mal aus deinem Master die Einstellungen (Pfeile oben Links in der Konfiguration)
Danach kannst du die json lokal öffnen und findest dort den API-Token deines Masters.Den kannst du dann im Slave eintragen und nutzt damit die gleiche APP mit dem Token
@simatec
Sorry für die so späte Antwort. Ich habe das Forum nicht mehr beobachtet und anscheinend habe ich kein Mail bekommen oder es übersehen und gelöscht.
Das mit dem Token des Masters werde ich probieren. Ich habe gesehen, dass Du schon an der API gearbeitet hast und sie bald ins latest kommen wird. Brauchst Du das Slave-Log noch?-- diwoma
ioBroker in LX-Container in Proxmox
Zigbee-Coordinator: CC2652P2-TCP FW: 20230507 -
@simatec
Sorry für die so späte Antwort. Ich habe das Forum nicht mehr beobachtet und anscheinend habe ich kein Mail bekommen oder es übersehen und gelöscht.
Das mit dem Token des Masters werde ich probieren. Ich habe gesehen, dass Du schon an der API gearbeitet hast und sie bald ins latest kommen wird. Brauchst Du das Slave-Log noch?
Support us
895
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge