Ich habe sowohl FHEM als auch MariaDB auf meinem NUC6CAYH (Celeron J3455, 2GB RAM, 30GB SSD) installiert. Momentan sichere ich die komplette Festplatte auf eine meiner Synology DiskStations. Dazu stoppe ich sowohl FHEM als auch MariaDB vorher und starte beides danach wieder
#!/bin/bash
#
BACKUP_PATH="/mnt/DS216II/NUC6CAYH"
BACKUP_COUNT="5"
BACKUP_NAME="NUC6CAYH"
#
mount /mnt/DS216II
#
systemctl stop fhem
sleep 15
systemctl kill fhem
sleep 5
systemctl stop mysql
sleep 10
pkill --signal 9 perl
#
sync
dd if=/dev/sda of=${BACKUP_PATH}/${BACKUP_NAME}-$(date +%Y%m%d-%H%M%S).img bs=1MB
#
systemctl start mysql
systemctl start fhem
#
pushd ${BACKUP_PATH}; ls -tr ${BACKUP_PATH}/${BACKUP_NAME}* | head -n -${BACKUP_COUNT} | xargs rm; popd
MariaDB fährt problemlos herunter, aber ohne den pkill ist Port 8084 weiterhin belegt und verhindert den Neustart von FHEM.
Daher überlege ich anstelle der MariaDB auf dem NUC entweder MariaDB 5 oder 10 auf der Synology (DS216+II, Celeron N3060, 8GB RAM, 2x 2TB WD Red) zu verwenden, da die Tabellen hier automatisch mit HyperBackup gesichert werden. Dann könnte ich FHEM durchlaufen lassen und würde bei Konfigurationsänderungen das Verzeichnis manuell sichern.
Laut BENCHMARK() Funktion ist der NUC zwar um einiges schneller als die DS, aber fällt das im normalen Betrieb (ca. 8000 Events/Tag) überhaupt auf ?
Welche Alternativen hätte ich ansonsten ?
ZitatLaut BENCHMARK() Funktion ist der NUC zwar um einiges schneller als die DS, aber fällt das im normalen Betrieb (ca. 8000 Events/Tag) überhaupt auf ?
Ich benutze ebenfalls MariaDB5 / 10 als Datenbank für DbLog im test- und produktiven Betrieb auf meiner Synology. Nebenbei noch auf einem NUC, aber auch nur zum Test.
Die etwas langsamere Syno ist überhaupt kein Problem, insbesondere wenn man DbLog ohnehin im asynchronen Modus betreibt.
Die SQL-Zeiten beim Schreiben liegen bei mir so bei 0.04 - 0.08 Sekunden.
Ein bisschen unschön ist beim Hyperbackup, dass man im Restorefall nur alle auf der MariaDB definierten Datenbanken zurücksichern muss. Einzeln und einzelne Tabellen geht nicht.
Deshalb mache ich es so, dass ich ein mehrstufiges Sicherungsverfahren anwende:
1. Hyperbackup sichert mir regelmäßig die MariaDB's auf der Syno -> Standard
2. FHEM sichert mit DbRep-Devices die MariaDB's mit "set ... dumpMySQL serverSide" (bzw. auch clientSide) jede Nacht -> es entstehen komprimierte Sicherungsfiles auf einem Share der Diskstation
3. jede Nacht (nach den FHEM-Backups) sichert Hyperbackup die Filesysteme der DS auf externe USB-Devices (inkrementell)
Die Backups sind dadurch etwas redundant, aber das Verfahren hat für mich den Vorteil dass ich bei Bedarf die FHEM DB's bzw. die history Tabelle dieser DB's separat restoren kann.
EDIT: bei dem ganzen Verfahren ist es überhaupt nicht nötig FHEM zu stoppen sofern DbLog im asynchronen Modus läuft.
Grüße,
Heiko
Zitat von: DS_Starter am 15 November 2019, 14:30:48
EDIT: bei dem ganzen Verfahren ist es überhaupt nicht nötig FHEM zu stoppen sofern DbLog im asynchronen Modus läuft.
Bei meinem DbLog steht bei mode "synchronous" ... wo liegt der Unterschied und wie kann ich das umstellen ? Könnte ich mir das FHEM/PERL stoppen für den dd dann sparen, wenn ich die MariaDB der DS nutze ?
auf dem NUC läuft FHEM, NGinx (als Proxy für FHEM), NUT, MariaDB (nur für FHEM) und Grafana - als Dateidienst noch Samba
ZitatBei meinem DbLog steht bei mode "synchronous" ... wo liegt der Unterschied und wie kann ich das umstellen ?
Mit dem Attribut "asyncMode" kannst du DbLog umstellen. Geht im laufenden Betrieb. Der Unterschied der Modi ist in der Commandref zu diesem Attribut erläutert. Wenn dazu noch Fragen sind, einfach nochmal melden.
ZitatKönnte ich mir das FHEM/PERL stoppen für den dd dann sparen, wenn ich die MariaDB der DS nutze ?
Ja, könntest du.
Super - danke !! Ich hab' den timeout auf 600 (10 Minuten) gesetzt - 86400 (ein Tag) erschien mir etwas zu lang ...
Setze den timeout lieber etwas höher, vllt. 3 Stunden. Hintergrund: Wenn die Syno ein Backup der Maria mit Hyperbackup macht, bleibt der Hintergrundprozess "wartend" bis Hyperbackup fertig ist. Sollte in dieser Zeit dein timeout zuschlagen, wird der Hintergrundprozess beendet und die diesem Lauf übergebenen Daten sind weg.
ok, mach' ich