iobroker lxc Container Speicher vergrößert sich ständig
-
@jan_xx sagte in iobroker lxc Container Speicher vergrößert sich ständig:
anscheinend habe ich die Sicherung mal irgendwann eingeschaltet
dafür ist sie ja da!
@jan_xx sagte in iobroker lxc Container Speicher vergrößert sich ständig:
hier liegen sehr viele Backups,
wie ist backitup denn konfiguriert?
-
@jan_xx sagte in iobroker lxc Container Speicher vergrößert sich ständig:
Wie markiert man denn mehrere Dateien bei ncdu?
Ich verwende da immer
rm /pfad/zur/zuloeschenden/Dateiggfls. mit Wildcards.
-
@homoran
Täglich Backup, aber eigentlich steht da das nur die letzten 10 aufgehoben werden sollen, anscheinen hat das nicht funktioniert...?
gibt es nicht so was ähnliches wie nc4, da kann ich alle Dateien markieren und löschen...?:-) -
@thomas-braun
Ja aber nur eine Datei... -
Evtl auch mal noch an Redis denken, wenn du das einsetzt.
Redis daten sind nicht im iobroker Verzeichnis gespeichertOder Datenbanken wie MySQL?
-
@jan_xx sagte in iobroker lxc Container Speicher vergrößert sich ständig:
Ja aber nur eine Datei...
Mit Wildcard arbeiten...
-
@jan_xx sagte in iobroker lxc Container Speicher vergrößert sich ständig:
gibt es nicht so was ähnliches wie nc4, da kann ich alle Dateien markieren und löschen...?:-)
MidnightCommander (mc) gibt es glaube ich als Pendant zum Norton Commander, wenn du das mit nc4 meinen solltest.
In ncdu kann man aber mit Sicherheit auch mehrere Dateien in einem Rutsch löschen. Ich weiß aber nicht wie, weil ich das halt lieber immer direkt mache. -
Mein Iobroker Container
martin@iobroker-test-sicher:/opt/iobroker/log$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/pve-vm--101--disk--0 63G 27G 33G 45% / none 492K 4.0K 488K 1% /dev udev 3.8G 0 3.8G 0% /dev/tty tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 1.6G 92K 1.6G 1% /run tmpfs 5.0M 0 5.0M 0% /run/lock martin@iobroker-test-sicher:/opt/iobroker/log$12,6 GiB hat alleine Backups...
--- /opt/iobroker ---------------------------------------------------------------------------------------- 12.6 GiB [###############] /backups 901.4 MiB [# ] /node_modules 305.3 MiB [ ] /iobroker-data 1.1 MiB [ ] /restore 1.0 MiB [ ] package-lock.json 776.0 KiB [ ] /log 12.0 KiB [ ] /js2f 12.0 KiB [ ] compromised.sh 8.0 KiB [ ] /ssh 4.0 KiB [ ] iobroker 4.0 KiB [ ] package.json 4.0 KiB [ ] INSTALLER_INFO.txt 4.0 KiB [ ] .npmrc @ 0.0 B [ ] iob10 Stück werden aufgehoben, aber Influx läuft auch auf der gleichen Maschine, und Backitup sichert das auch...
Die größten Klopper sind die Influxdb-Backups....
martin@iobroker-test-sicher:/opt/iobroker/backups$ ls -l -h total 13G -rw-rwxr--+ 1 iobroker iobroker 4.8M Sep 15 2023 2023_09_15-07_01_10_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 1.3G Sep 30 02:53 influxDB_2025_09_30-02_40_28_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 1.3G Oct 1 02:54 influxDB_2025_10_01-02_40_28_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 1.3G Oct 2 02:53 influxDB_2025_10_02-02_40_27_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 1.3G Oct 3 02:54 influxDB_2025_10_03-02_40_28_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 1.3G Oct 4 02:54 influxDB_2025_10_04-02_40_28_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 1.3G Oct 5 02:54 influxDB_2025_10_05-02_40_28_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 1.3G Oct 6 02:55 influxDB_2025_10_06-02_40_29_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 1.3G Oct 7 02:54 influxDB_2025_10_07-02_40_30_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 1.3G Oct 8 02:54 influxDB_2025_10_08-02_40_28_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 1.3G Oct 9 02:53 influxDB_2025_10_09-02_40_32_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 7.4M Sep 30 02:40 iobroker_2025_09_30-02_40_10_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 7.4M Oct 1 02:40 iobroker_2025_10_01-02_40_10_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 7.4M Oct 2 02:40 iobroker_2025_10_02-02_40_10_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 7.5M Oct 3 02:40 iobroker_2025_10_03-02_40_10_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 7.5M Oct 4 02:40 iobroker_2025_10_04-02_40_10_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 7.5M Oct 5 02:40 iobroker_2025_10_05-02_40_10_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 7.5M Oct 6 02:40 iobroker_2025_10_06-02_40_10_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 7.5M Oct 7 02:40 iobroker_2025_10_07-02_40_10_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 7.5M Oct 8 02:40 iobroker_2025_10_08-02_40_10_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 7.5M Oct 9 02:40 iobroker_2025_10_09-02_40_10_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 73K Sep 30 02:54 javascripts_2025_09_30-02_54_00_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 73K Oct 1 02:54 javascripts_2025_10_01-02_54_16_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 73K Oct 2 02:53 javascripts_2025_10_02-02_53_34_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 73K Oct 3 02:54 javascripts_2025_10_03-02_54_51_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 73K Oct 4 02:54 javascripts_2025_10_04-02_54_25_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 73K Oct 5 02:54 javascripts_2025_10_05-02_54_50_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 73K Oct 6 02:55 javascripts_2025_10_06-02_55_16_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 73K Oct 7 02:55 javascripts_2025_10_07-02_55_01_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 73K Oct 8 02:54 javascripts_2025_10_08-02_54_06_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 73K Oct 9 02:53 javascripts_2025_10_09-02_53_51_backupiobroker.tar.gz martin@iobroker-test-sicher:/opt/iobroker/backups$"Langzeitsicherung" auf einer USB-Platte an einem SMB-Share auf einem anderen Container.
5 * * * sshpass -p "......." rsync -a /opt/iobroker/backups/* .......@192.168.2.203:/mnt/usbdrives/intenso1/backup/Martin/iobroker/ 3 5 * * * sshpass -p "......." rsync -a /opt/iobroker/log/*.log.gz ......@192.168.2.203:/mnt/usbdrives/intenso1/backup/Martin/iobroker/Logs/Auf der USB-Festplatte putzt regelmäßig dieses Script:
martin@fileserver ~/skripte$ cat trim_backups.sh find /mnt/usbdrives/intenso1/backup/Martin/iobroker -type f -mtime +50 -delete >/dev/null 2>&1 martin@fileserver ~/skripte$ -
@jan_xx sagte in iobroker lxc Container Speicher vergrößert sich ständig:
eigentlich steht da das nur die letzten 10 aufgehoben werden sollen, anscheinen hat das nicht funktioniert.
Wo sollen Deine Backups denn hin?
Wenn da was schiefgeht, bleiben die auf der lokalen Maschine stehen.
Dort machen sie aber keinen Sinn. Die gehören woanders hin. Auf ein externes Medium, ein NAS oder gleich in die Cloud.
Wenn Deine Hütte abfackelt, geht die Versicherungspolice im Wohnzimmerschrank ja auch in Rauch auf.Zeig' mal, wie Du das konfiguriert hast.
-
@all
habe es hin bekommen, muss jetzt aber nochmal einen Plan machen damit das nicht wieder passiert... -
@jan_xx Das, was gerade "passiert" ist, ist nur die halbe Katastrophe, die Dich ereilen könnte, wenn Du keine Backups auf separater Hardware machst ...
Mache ein Konzept für das Aufräumen der lokalen Backups (das sollte eigentlich gegeben sein, wenn die Einstellungen in Backitup passen)
Wie @Codierknecht schrieb: Aber überlege Dir auch, wie Du die lokalen Backups auf eine externe Festplatte / ein NAS kopierst, vor dem lokalen Aufräumen ...
-
@martinp
Ich habe es eigentlich so eingestellt das alle Backups auf googledrive landen, ich hatte das garnicht auf Lokal eingestellt, von daher verstehe ich nicht warum die ganzen Daten Lokal lagen....
-
@jan_xx sagte in iobroker lxc Container Speicher vergrößert sich ständig:
von daher verstehe ich nicht warum die ganzen Daten Lokal lagen.
@crunchip sagte in iobroker lxc Container Speicher vergrößert sich ständig:
backups(vorallem wenn sie fehlschlugen und eigentlich irgendwo extern gesichert werden sollten), denn dann landen sie local
-
@jan_xx sagte in iobroker lxc Container Speicher vergrößert sich ständig:
Täglich Backup,
bitte alles immer zeigen!
https://forum.iobroker.net/topic/51555/hinweise-für-gute-forenbeiträge/1
-
Ein Backup einfach nur zu machen, nützt oft garnix.
Es sollte auch- Regelmäßig geprüft werden, ob das wie gewünscht läuft
- Sichergestellt sein, dass ein erzeugtes Backup auch wiederhergestellt werden kann
-
@codierknecht Für den Punkt 2 wären sicher einige Tipps hilfreich ...
Wenn man nur einen PVE-Server hat: Zweiter LXC-Container mit iobroker - Installation, der man regelmäßig ein Backup der produktiven iobroker-Instanz zu Futtern gibt?
Vielleicht ein Template eines "frischen" vorbereiteten LXC-Containers bereit halten, den man dann für den Test frisch in einen Container ausrollt, und diesen Container dann nach den Tests wieder löscht, da nicht mehr frisch, sondern durch das Backup modifiziert?
Wie verhindert man, dass in solch einem Fall der Test-LXC-Container dem produktiven Container ins Gehege kommt, indem er z. B. konkurrierend Zugriff auf Peripherie nimmt usw.? Wahrscheinlich muss man während der Tests den produktiven Container stoppen?
Gerade jetzt ist der Test auf funktionierende Backups womöglich besonders interessant, wenn man Debian als Unterbau verwendet - der Update auf trixie steht in nächster Zeit an...
-
@martinp das sind allerdings alles Dinge, die man sich aneignen muss, wenn man auf Drittanbieter wie Proxmox, Unraid, etc. setzt.
Zum anderen muss man differenzieren- ein backup der gesamten Maschine LXC/VM
- ein backup des reinen iobroker durch backitup Adapter
und logischerweise sollte man entsprechend handeln, setzt die Logik ja voraus, das bei bestimmten IP bezogenen Adaptern nichts gleichzeitig laufen kann, bzw erst gar nicht läuft
auch ein vorgefertigtes template muss immer wieder auf den neusten Stand gebracht werden
-
@crunchip Die Probleme sind mir ja alle bewusst, aber an Lösungen bin ich interessiert ...
Meine Idee:
Wenn man in der Container-Denke bliebe, würde man einen dedizierten iobroker-Container bauen, der MÖGLICHST WENIG weiteres enthielte.
Wenn mal wieder ein Test ansteht, wird der produktive iobroker-Container gestoppt, der vorbereitete iobroker - Container gestartet und das möglichst Zeitnahe Backitup-Backup des gestoppten Produktiv-Containers eingespielt.
Dann wird die Funktion getestet, und der Produktiv-Container wird erst gar nicht wieder gestartet, und der neue Container wird zum Produktiv LXC-Container....
-
@martinp sagte in iobroker lxc Container Speicher vergrößert sich ständig:
Wie verhindert man, dass in solch einem Fall der Test-LXC-Container dem produktiven Container ins Gehege kommt, indem er z. B. konkurrierend Zugriff auf Peripherie nimmt usw.? Wahrscheinlich muss man während der Tests den produktiven Container stoppen?
Würde ich so machen.
Das muss man ja nicht nach jedem Backup so machen. Aber man sollte zumindest mal getestet haben, ob man ein Backup auch wiederherstellen kann. Sonst nützt nämlich auch das allerschönste Backup ... NIX!
-
@martinp sagte in iobroker lxc Container Speicher vergrößert sich ständig:
und der neue Container wird zum Produktiv LXC-Container
Wobei man die IP nicht ausser Acht lassen darf
@martinp sagte in iobroker lxc Container Speicher vergrößert sich ständig:
Wenn man in der Container-Denke bliebe, würde man einen dedizierten iobroker-Container bauen, der MÖGLICHST WENIG weiteres enthielte.
Du meinst Proxmox?
Dafür nutzte ich den Proxmox backup Server um incrementell zu sichernEin reines iobroker backup zusätzlich, wenn man mal ein frisches System aufsetzen möchte.
