Aus aktuellen Anlass schreibe ich hier mal 3-4 Punkte zusammen wie man sein tägliches FHEM Backup verschlüsselt auf GoogleDrive ablegen kann.
Ich übernehme keinerlei Haftung für gelöschte oder zerstörte FHEM Installationen. Die hier exemplarisch zur Verfügung gestellten Scripte funktionieren seit über 2 Jahren in meiner Umgebung. Bitte schaut sie Euch genau an und versucht zu verstehen.Nötige Vorarbeiten
- Man besorge sich GoogleDrive (https://drive.google.com/drive/my-drive). Ich bezahle für 100GB 2-3 Euro im Monat
- einrichten einer Sync Software für GoogleDrive und Linux. Ich verwende insync (https://www.insynchq.com/)
- ein tägliches Backup in FHEM einrichten (zeige ich nachher kurz)
- einrichten eines encfs Verzeichnisses (https://wiki.ubuntuusers.de/EncFS/)
- ein Backupscript welches das tägliche Backup aus /opt/fhem/backup/ ins verschlüsselte Verzeichnis kopiert(zeige ich nachher kurz)
Weiter gehts.
Google Drive und insync sollten eingerichtet sein, ebenso ein encfs Verzeichnis.
Nun richten wir als erstes ein FHEM Backup ein. Hierfür verwende ich das hauseigene backup von FHEM
Internals:
CFGFN
COMMAND backup
DEF *02:30:00 backup
NAME atFHEM_BackupTaeglich
NR 109
PERIODIC yes
RELATIVE no
REP -1
STATE Next: 02:30:00
TIMESPEC 02:30:00
TRIGGERTIME 1488245400
TRIGGERTIME_FMT 2017-02-28 02:30:00
TYPE at
Readings:
2017-02-27 02:37:35 state Next: 02:30:00
Attributes:
group Backup
room EDV
Erledigt. Täglich um 02:30 Uhr wird gesichert. Meines Wissens nach geschieht die Sicherung blockierend. Daher habe ich das ganze auf Nachts gelegt.
Diese Sicherung wird nun von einem bash Backupscript ins angelegte verschlüsselte Verzeichnis kopiert.
Script
#!/bin/sh
# config
SOURCEPATH="/opt/fhem/backup" # path to your backupsource, no symbolic links are allowed!
BACKUPPATH="/home/leon/Google_Drive_Secure/pi-fhem01_BACKUPS" # where do you save the backups?
DAILY_DATA_BACKUPS="6" # keep this amount backups
# no more config
### Clean up old FHEM backup parts
# configDB SQL dumps
find /opt/fhem/log/configDB_* -mtime +2 -exec rm -vrf {} \;
# dbLog SQL dumps
find /opt/fhem/log/logDB_* -mtime +0 -exec rm -vrf {} \;
# FHEM Backupverzeichnis
find /opt/fhem/backup/FHEM-* -mtime +4 -exec rm -vrf {} \;
# check encfs Laufwerk vorhanden?
encfs_check () {
if [ ! -d "${BACKUPPATH}" ]
then
echo "\n\n !!! ERROR !!!\n";
echo "$BACKUPPATH not found! check encfs mount?\n"
exit 1
fi
return 0
}
# creates $1, if not existant
checkDir()
{
if [ ! -d "${BACKUPPATH}/$1" ]
then
mkdir -p "${BACKUPPATH}/$1"
echo "Erstelle Backupverzeichnis ${BACKUPPATH}/$1"
fi
}
# 1 -> path
# 2 -> name
# 3 -> number of backups
rotateDir()
{
for i in `seq $(($3 - 1)) -1 1`
do
if [ -f "$1/$2.$i.tar.bz2" ]
then
mv "$1/$2.$i.tar.bz2" "$1/$2.$((i + 1)).tar.bz2"
echo "Räume Backupverzeichnis auf $i"
fi
done
find ${BACKUPPATH}/fhem_backups/archive/ -mtime +60 -exec rm -vrf {} \;
echo "Lösche alle Archive die älter als 60 Tage sind"
}
## make fhem DbLog Databasedump
mysqldump --user=fhem --password=XXXXXX -Q fhem > $SOURCEPATH/log/logDB_"`date +%d-%m-%Y`".sql
encfs_check
# make sure everything exists
checkDir "fhem_backups"
checkDir "fhem_backups/archive"
checkDir "fhem_backups/daily"
# first step: rotate daily.
rotateDir "${BACKUPPATH}/fhem_backups/daily" "fhem_backup" "$DAILY_DATA_BACKUPS"
# then create our backup
echo "Erstelle Backup"
tar -cvjf "/tmp/fhem_backup.1.tar.bz2" "${SOURCEPATH}/backup/FHEM-`date +%Y%m%d`"*".tar.gz"
# create an weekly archive backup?
if [ `date +%a` = "So" ]
then
cp "/tmp/fhem_backup.1.tar.bz2" "${BACKUPPATH}/fhem_backups/archive/fhem_backup-"`date +%d-%m-%Y`".tar.bz2"
echo "Erstelle wöchentliches Archiv Backup"
fi
# add them to daily.
echo "Verschiebe Tagesbackup ins Backupverzeichnis"
mv "/tmp/fhem_backup.1.tar.bz2" "${BACKUPPATH}/fhem_backups/daily"
Bitte schaut Euch das Script genau an. Es ist auf meine Umgebung zugeschnitten, daher möchte ich Euch bitten zu verstehen was da genau passiert so das Ihr es auf Eure Umgebung anpassen könnt. Ihr müsst eventuell noch benötigte Verzeichnisse anlegen.
Bei Fragen einfach fragen.
Sobald nun neue Dateien ins verschlüsselte Backupverzeichnis kopiert werden, startet automatisch insync die Synchronisation.
Als sqlite Anwender habe ich das ähnlich gelöst, sichere aber nur das, was als configDB Anwender notwendig ist.
1.
man lege sich einen S3-Bucket an, wer es verschlüsselt braucht, kann das direkt für den bucket konfigurieren
2.
man lege sich ein Backup-Skript an
#!/bin/sh
clear
cd /opt/fhem
echo "#"
echo "# waiting for logfile availability"
while [ -e sqldb/logDBprodfhem.db-wal ]
do
echo -n "."
sleep 1
done
echo "#"
echo "# vacuum logfile"
sqlite3 sqldb/logDBprodfhem.db vacuum;
echo "#"
echo "# copy logfile"
cp sqldb/logDBprodfhem.db sqldb/logDBprodfhem.db.bak
echo "#"
echo "# rsync to s3"
aws s3 sync /opt/fhem s3://<bucketName>/ \
--delete \
--exclude "*" \
--include "configDB.conf" \
--include "sqldb/configDB.db" \
--include "sqldb/logDBprodfhem.db.bak"\
--include "log/*.log"
echo "#"
echo "# done."
3.
man definiere ein at, das im 03:05 Uhr ein "set dbLogDevice reopen 60" ausführt
4.
man definiere einen cronjob, der um 03:05 Uhr das obige Skript startet.
- das Skript wartet nach dem Start solange, bis das Logfile von FHEM geschlossen wurde und kopiert dann die zuvor per vacuum aufgeräumte Logdatei.
- sollte die Zeit für das vacuum und das kopieren nicht ausreichen, kann die reopen-Zeit entsprechend angepasst werden.
- das rsync überträgt ohnehin schon verschlüsselt
- wer möchte, kann am Ende des Skripts die kopierte Datei wieder löschen. Das Kopieren findet statt, damit FHEM mit der Logdatei weiterarbeiten kann und während des sync zu S3 keine offenen Logfiledateien vorhanden sind.
Hallo Udo,
Vielen Dank für Deine Erweiterung/andere Sichtweise für ein tägliches FHEM Backup. Ich denke mal so eine Sammlung kann nicht schaden.
Grüße
Nachtrag. Darf ich das schon Workshop nennen?
Das ist doch kein Workshop, sondern nur ein Codeschnipsel 8)
Ok. Hast Recht. Dann lassen wir das so wie es ist. Hauptsache Hilfreich sag ich immer.
Wenn man das "Workshop" nennt, tauchen wieder User auf, die Support fordern...
Ach Udo. You make my Day. Aber Recht hast.
Wobei ich aber auch sagen möchte, wer Fragen hat darf gerne Fragen. Zu mindest was meinen Teil an geht. Nur bisschen Grundkenntnis erwarte ich schon.
Grüße
Es geht nicht darum, dass jemand nicht fragen darf oder soll. Aber immer mehr User verstehen nicht, dass das hier keine 24/7 Support-Plattform ist. Und wenn dann 30 Minuten nach einer im Forum gestellten Frage bereits zwei emails mit Hinweis auf den Forumeintrag in meinem Posteingang liegen, warum ich eine Frage noch nicht beantwortet habe, vergeht mir einfach manchmal der Spaß.
Dann habe ich da auch noch einen:
- Man hole sich einen box.com Account mit 5GB für lau.
- Mount des Accounts mittels WebDAV. Auszug aus der FSTAB: https://dav.box.com/dav /webdav/backup.box.com davfs noauto,user,rw,gid=davfs2,dir_mode=770 2 0 0
- dann mounte man mittels encfs das verschlüsselte FS auf das DavFS: Auszug aus der FSTAB /webdav/encfs/encfs.dokumente#/webdav/backup.box.com/dokumente.enc /webdav/encfs/dokumente fuse rw,user,noauto 0 0
- Danach kann man dan mit beliebigen Tools (rsync und mysqldump) seine Backups anlegen.
- Wenn die Backups fertig sind das ganze wieder rückwärts unmounten
Bei mir läuft das ganze mittels Cron in der Nacht.
Zitat von: betateilchen am 27 Februar 2017, 15:12:41
Es geht nicht darum, dass jemand nicht fragen darf oder soll. Aber immer mehr User verstehen nicht, dass das hier keine 24/7 Support-Plattform ist. Und wenn dann 30 Minuten nach einer im Forum gestellten Frage bereits zwei emails mit Hinweis auf den Forumeintrag in meinem Posteingang liegen, warum ich eine Frage noch nicht beantwortet habe, vergeht mir einfach manchmal der Spaß.
Ach Du Kacke. Echt jetzt. Ok da habe ich definitiv noch die netten User bei mir.
Aber gut zu wissen das es sowas auch gibt. Muss man sich wohl drauf einstellen. Sehr schade eigentlich.
Vielen Dank für Eure Backup-Methoden. Ich nutze dafür ein Shell-Script, dass mir täglich /opt/fhem sichert und auf einen NAS schiebt. Kürzlich hab ich das wirklich mal gebraucht, weil mir die Speicherkarte vom RPi abgeraucht ist, und ich war froh, dass ich es hatte 8)
Eine Erfahrung habe ich dabei gemacht:
Ein Backup zu besitzen ist das eine, aber das System wieder ans Laufen zu bekommen, etwas ganz anderes.
Ich hatte natürlich keine Probleme, den Raspi grundsätzlich wieder zum Laufen zu bringen, jedoch scheint es bei der Installation von FHEM einige Probleme mit der Rechtevergabe zu geben. Die wird nämlich (zumindest unter Raspbian Jessie) nicht korrekt durchgeführt. Das hat dann zur Folge, dass FHEM zwar installiert ist, sich jedoch nicht starten lässt. Nachdem ich das irgendwie hinbekommen habe, musste ja noch mein Backup eingespielt werden. Dann wieder die Sache mit den Rechten, was im zweiten Anlauf jedoch viel leichter von der Hand ging.
Letztlich mussten noch etliche Pakete neu installiert werden, um alle Funktionen wiederherzustellen. Hier half mir ein Blick ins Logfile das mich an fehlende Perl-Pakete erinnerte.
Was ich damit sagen will: man sollte sich nicht nur auf das Backup ansich verlassen, sondern auch mal versuchen, ein System neu aufzusetzen, solange alles noch funktioniert. Sonst kann es im Fall der Fälle ganz schön stressig werden ;)
wobei Du in diesem Falle doppelt-gemoppelt hast.
1. FHEM installiert
2. FHEM durch restore installiert
Denn eine Installation ist, mit wenigen ausnahmen, praktisch ein generieren von /opf/fhem
+ User anlegen
+ Start-Script erstellen ...
Zitat von: Standarduser am 07 März 2017, 15:36:37
Was ich damit sagen will: man sollte sich nicht nur auf das Backup ansich verlassen, sondern auch mal versuchen, ein System neu aufzusetzen, solange alles noch funktioniert. Sonst kann es im Fall der Fälle ganz schön stressig werden ;)
5 Minuten...
1. FHEM neu aufsetzen aus https://debian.fhem.de -> nightly build = benötigte perl Pakete werden automatisch mit installiert, Benutzer und Startskript werden automatisch generiert.
2. configDB aus der Sicherung zurückkopieren, sie enthält auch alle externen Dateien wie .gplot, .holiday, 99_myUtils usw., die FHEM braucht
Einmal FHEM neu starten - fertig.
Dropbox!
FHEM samt allen dynamischen Dateien wie Statefile und Logs in einen Ordner konfiguriert, den in die Dropbox gelinkt und fertig ist die ultimative Backup-Lösung.
Ich hab damit nicht nur ein tägliches Backup sondern kann 30 Tage lang für jede Datei zu jedem beliebigen Zustand zurück wechseln.
Für Entwickler: Modul Dateien kann ich auf jedem anderen Rechner mit meinem Dropbox Account direkt lokal editieren und nach einer Sekunde Wartezeit per reload auf dem Server aktualisieren.
Zitat von: Wernieman am 07 März 2017, 19:52:58
wobei Du in diesem Falle doppelt-gemoppelt hast.
1. FHEM installiert
2. FHEM durch restore installiert
Denn eine Installation ist, mit wenigen ausnahmen, praktisch ein generieren von /opf/fhem
+ User anlegen
+ Start-Script erstellen ...
Ja, ich wusste nicht, was da alles im Hintergrund passiert - User/Gruppe/Startscript/usw... Vielleicht noch mehr?
meine Backup Strategie:
- jede NAcht ein automatisches Backup auf Fileserver. liegt dort im RAID5 und wird dort auch nochmal gesichert.
- ca monatlich ein volles SD Karten Image.
bisher war noch nie nen Restore notwendig für FHEM, aber wenn dan bin ich vorbereitet. :-)
in eine Cloud gehen meine Daten nicht. meine Daten = meine 4 Wände.
Grüße
Ich
Hat allerdings auch den Nachteil:
Ein Brand und alles ....
Deshalb lagrn auch Wichtige Daten (und Bilder) bei den Schwiegereltern ...
Nach einem Brand hätte ich aber auch andere Sorgen als mein FHEM wieder ans laufen zu bringen. Zumal die meisten Aktoren mit in Rauch aufgegangen worden sein.
Backups bei Installationen werden sowieso auf einen USB Stick gesichert. Und diese wandern dann auf mein NAS. Komplettsicherung des SD-Karte mache ich nicht regelmäßig.
Grüße
Zitat von: majorshark am 07 März 2017, 21:50:27
Backups bei Installationen werden sowieso auf einen USB Stick gesichert
ich schmeiss mich weg... 8)
Zitat von: majorshark am 07 März 2017, 21:50:27
Backups bei Installationen werden sowieso auf einen USB Stick gesichert.
Einigen wir uns darauf das wir es Sicherheitskopie nennen. Backuplösungen sind dann doch bisschen was anderes. ;D
Grüße
So ist es auch gemeint.
Danke für die interessanten Beispiele!
Ich musste zwar beim ersten Beispiel einige Prüfungen noch einbauen ob das Verz/File vorhanden ist, aber der Rest läuft sauber durch.
Ich möchte nun auf Dropbox sichern, habe aber das Problem das ich den Token nicht eingeben kann! Isync funktioniert, möchte aber für die Sync. Software nicht bezahlen.
Auszug aus dem Fhem Log:
Loesche alle Archive die aelter als 10 Tage sind
Erstelle Backup
tar: Removing leading `/' from member names
/opt/fhem/backup/FHEM-20170309_023000.tar.gz
Verschiebe Tagesbackup ins Backupverzeichnis
This is the first time you run this script, please follow the instructions:
1) Open the following URL in your Browser, and log in using your account: https://www.dropbox.com/developers/apps
2) Click on "Create App", then select "Dropbox API app"
3) Now go on with the configuration, choosing the app permissions and access restrictions to your DropBox folder
4) Enter the "App Name" that you prefer (e.g. MyUploader231102429717664)
Now, click on the "Create App" button.
When your new App is successfully created, please click on the Generate button
under the 'Generated access token' section, then copy and paste the new access token here:
# Access token:
> The access token is . Looks ok? [y/N]:
hier die Meldung wenn ich das Script über Fhem aufrufe. Wenn ich das Script händisch am Raspi als User Pi mit ./... starte, läuft es fehlerfrei durch, verlangt keinen Token weil ich den schon einmal eingegeben habe und sichert in die Cloud. Weiß jemand wie ich das Script zwingen kann, dass ich in der Konsole nun den Token eingeben kann? Irgendwie scheint es am User zu liegen der das Script ausführt, oder kann man den Token wo hinterlegen?
Ich habe bis jetzt in den Dokus nichts relevantes gefunden.
LG
Wenn der Token als User Pi angelegt wurde dann kannst Du das ganze als FHEM nicht machen. Du kannst versuchen die Dropbox config vom User Pi nach User fhem zu kopieren und die rechte an zu passen.
Oder du schaltest den User FHEM frei, und loggst dich mit dem einmal ein, startest dein Script und gibst den Token ein.
Danke für die Tipps, aber ich habe es jetzt noch einfacher gelöst.
Da ich ohnehin einen WHS-Server im Netzwerk habe holt sich dieser die Backups über eine Sambafreigabe vom Raspi selber via Robocopy ( Parameter MIR = Spiegel ) ab.
Geht rasend schnell und ich kann immer noch vom Windowserver auf Dropbox etc. verlinken wenn ich will.
Somit mach ich auch keine weiteren Sicherheitslöcher am Raspi auf wenn ich in die Fhem User Rechte eingreife.
LG
Zitat von: Reinhart am 09 März 2017, 17:06:04Ich möchte nun auf Dropbox sichern, habe aber das Problem das ich den Token nicht eingeben kann! Isync funktioniert, möchte aber für die Sync. Software nicht bezahlen.
Hmm...
Ohne die original Dropbox App hast du eigentlich keine großen Vorteile. Vor allem wenn du doch wieder alles selbst per Script erledigen musst.
Gibt es auf deinem System keine Software für einen kontinuierlichen Sync?