Wie kann ich das Backup vom Datenmüll befreien?

[Winglet]

Hallo...
meine Backup-Datei (skb) ist inzwischen auf >4GB "gewachsen" und läßt sich nicht mehr zurückspielen (Vers.: 3.45.5.20190330). Das Backup wurde manuell über WEBUI erzeugt. Die Größe begründet sich nicht allein damit, dass die Historian-DB beinhaltet ist. Es scheint so, dass alte Backupstände öfters in das neue Backup mit übernommen wurden (???). Das Entpacken der skb-Datei zeigt eine komplexe redundante Ordnerstruktur, die auch ineinander mehrmals gepackt ist. Keine Ahnung wie das passiert ist.
Ansonsten läuft das System ohne Störungen (es gab auch nie einen Hinweis darauf, dass bei der Backup-Erzeugung etwas schief gelaufen ist).

kurz ....
Auf dem Raspi läuft gleichzeitig Historian (ich werde das in Zukunft ändern!!).
Den "händischen" Versuch - durch ein einfaches löschen ein "schlankes" Backup zu erhalten habe ich nach vielen Versuchen aufgegeben (auf die Historian Dateien könnte ich verzichten). Problem: Aus den mir zur Verfügung stehenden Backups kann nicht sicher ableiten, welche Dateien wirklich benötigt werden, wie die Ordnerstruktur auszusehen hat und wie in welcher Reihenfolge etwas zu packen ist.
Die SD Karte ist inzwischen kopiert - läuft - und steht somit für den Notfall zur Verfügung.

Meine Frage:
Wie kann man ein (lauffähiges) Backup erzeugen? Ich habe bisher keine Dokumentation über die g e n a u e Struktur gefunden.
Gibt es eine Möglichkeit im RASPI ein Backup manuell auszulösen - ohne dass die alten Daten wieder mitgesichert werden?

[trevyn]

Schau mal hier:
viewtopic.php?f=65&t=50398

insbesondere:
viewtopic.php?p=505672#p505672

bzw hier hast du das auch schonmal angesprochen:
viewtopic.php?f=65&t=50302&p=504726#p504726

Edit:
Gerade gesehen, dass das ja auch von Dir kommt. Hätte man evtl. im alten Thread weiter bearbeiten können ...

Meine Frage:
Wie kann man ein (lauffähiges) Backup erzeugen? Ich habe bisher keine Dokumentation über die g e n a u e Struktur gefunden.

Wurde in den verlinkten Threads eigentl. beantwortet.

Es scheint so, dass alte Backupstände öfters in das neue Backup mit übernommen wurden (???). Das Entpacken der skb-Datei zeigt eine komplexe redundante Ordnerstruktur, die auch ineinander mehrmals gepackt ist. Keine Ahnung wie das passiert ist.

Aus welchen Indizien schließt du das? Das würde bedeuten, dass die Backup-Datei so abgelegt wurde, dass sie mitgesichert wird.
Bitte via SSH folgendes Command:
# find /usr/local -name "*.sbk"


Hier sollte eigentlich keine Ausgabe kommen - falls doch, würde das bedeuten, dass in /usr/local irgendwelche Backups liegen.
Du kannst das auch mal im Rootverzeichnis (find / -name "*.sbk") machen - da sollten Backups angezeigt werden, die dann aber auf /media/usb1/backup/ liegen sollten (und das wird nicht gesichert via regulärem Backup).

Die Größe begründet sich nicht allein damit, dass die Historian-DB beinhaltet ist.
...
Auf dem Raspi läuft gleichzeitig Historian (ich werde das in Zukunft ändern!!).

Erstmal Historian runter - dann sehen, wie sich die Datenmenge entwickelt.
Oder alternativ den Speicherort für die Historian-DB umlegen, Rückstände beseitigen (aus dem 1. verlinkten Thread ist eigentl. gut rauszulesen, wo der Krams liegen dürfte) und dann ein manuelles Backup anstoßen (siehe Verlinkungen, bzw. dann sollte es ja auch über die WebUI wieder gehen).

lt. Handbuch Historian:
3.2 Sicherungskopie der Datenbank erstellen
Das komplette Archiv, also alle Zeitreihen und die nötigen Verwaltungsinformationen, werden in einer Datei abgelegt. Der Dateiname wird durch die Konfigurationsoptionen database.dir(Standardeinstellung ./data) und database.name(Standardeinstellung history) vorgegeben. Die Dateiendung ist immer .h2.db. Daraus resultiert dann der vollständige Dateipfad <Installationsverzeichnis vom CCU-Historian>/data/history.h2.db. Mit einer einfachen Dateikopie kann das komplette Archiv an anderer Stelle gesichert werden. Der CCU-Historian darf während des Kopierens nicht gestartet sein.

Du könntest also die Historian-Daten auf einen Stick verschieben und dann in der Config entsprechende Anpassungen zum neuen Pfad vornehmen.

Grundsätzlich sieht die Struktur des Backups wie folgt aus:
Backupdatei.sbk
|- usr_local.tar.gz
|-- usr_local.tar
|--- usr
|---- local
|----- addons
|------ [whatever addons you have]
|------ [whatever addons you have]
|----- crontabs
|------ root
|----- etc
|------ config
|------- [viele config files und directories]
|------ ssh
|------- [evtl. ssh krams]
|------ monit.id
|------ ssh_host_....
|------ ssh_host_....
|------ ...
|----- sdcard
|------ [bei mir nur ein measurement_bak, was aber schon lange nicht mehr angefasst wurde]
|----- setparam.tcl
|----- setparam_virtdev.tlc
|- signature
|- key_index
|-firmware_version

Für eine erste Idee:
Geh mal bitte via ssh auf die Raspimatic und dort nach /usr/local/addons.
Da bitte einmal du -sh ausführen und mal sehen, welche Datenmengen überhaupt vorliegen.
Dann du -h um zu sehen, wie sich das auf die einzelnen Verzeichnisse aufteilt (davon ausgehend, dass eben das addon-Verzeichnis das Problem ist).

Zusätzlich kannst du auch mal in /usr/local du -sh machen um zu sehen, mit welcher Datenmenge man überhaupt konfrontiert wird.

[Winglet]

Vielen Dank für Deine sehr ausführliche und detailierte Antwort ...

Ich hab jetzt erst einmal jede Menge Input, so dass ich die nächsten Tage daran werkeln kann.

Es fällt mir noch ein wenig schwer ....
bisher hatte ich mich fast ausschließlich mit der Programmierung in der WEBUI (u.A. auch mit eigenen Scripten zur Heizungsregelung/Steuerung) beschäftigt. Alles funktioniert inzwischen sehr schön - aber zum ganzen "Drumherum" wie Linux, SSH, etc. bisher fast jeden Kontakt vermeiden können :=) Habe damals SD-Karte für den RASPI incl. Historian nach Anleitung aufgesetzt (funktionierte und fertig) und daher bei dieser Thematik sehr wenig Erfahrung ...

[Winglet]

Ich bin den Weg via SSH mit direktem Zugriff auf den RASPI nachgegangen und habe nicht die sbk-Datei händisch "modifiziert"...

Im Verzeichnis "eQ-3-Backup" mit dem Unterverzeichnis "restore" hatte sich u.A. sich die Historian-DB mit 5,4 GB eingenistet und noch einmal unter
"sdcard" / "ccu-historian" mit gleicher Größe ....

Habe das Verzeichnis "restore" mit Unterverzeichnissen komplett gelöscht genauso wie die Historian-DB unter "sdcard" / "ccu-historian".

Alles neu gestartet - neues Backup erstellt (von 4,6 GB auf jetzt 38 MB was ok sein dürfte) und zurückgespielt - Neustart - alles ok

Danke an alle Beteiligten.....

[trevyn]

Beobachte das aber bitte mal, wie sich das weiter entwickelt - nicht, dass da noch irgendwas schlummert und dann Ärger macht.

Backupgröße: Ich kommte aktuell so auf 5-10MB
Da sind natürlich nicht die diagrammdaten dabei, da die ja dank jens eh schon auf dem Stick schlummern.