Sicherung smarthome und smartVisu

[kingolli]

Hallo!

Da ich nun langsam vom Parallelbetrieb (CometVisu und SmartVisu) zur ausschließlichen Benutzung von sh.py/SV wechseln möchte, würde ich gerne ein Sicherungsszenario aufbauen.

Im Moment habe ich einen initialien Full-Backup und sichere täglich folgende Pfade/Dateien:

/var/www/smartvisu/pages/home (meine SV Pages)
/usr/local/smarthome/etc
/usr/local/smarthome/items
/usr/local/smarthome/logics
/usr/local/smarthome/var/db/smarthome.db

Fehlt da noch was Wichtiges?

Danke und Grüße
David

[callidomus]

Hi,

wie sieht es mit SV.conf aus?

Ich würde auch noch das scenes Verzeichnis sichern.

Bis bald

Marcus

[2ndsky]

Was spricht dagegen, den sh.py Ordner komplett zu sichern? So groß ist der nun auch wieder nicht. Eventuell kann man die Logs ja noch weglassen.

[Dragonos2000]

Evtl. noch das Config File für den NTP und das LAN/WLAN Interface

Gruss
Jochen

[Sandman60]

Das Sichern der smarthome.db bringt m.E. nach nix da die DB ja up and running ist. Ich schreibe da vorher einen Dump weg mit sh.sql.dump('/usr/smarthome/var/db/smarthomedb.dump'), der dann in die Sicherung miteingeht. Getriggert wird der Dump aus SH.py via UZSU.

Ansonsten sichere ich die gleichen Verzeichnisse aber zus. für SV die config.php noch mit (analog dem PI-Image-Backup).

Cheers,
Oliver

[2ndsky]

Das Sichern der smarthome.db bringt m.E. nach nix da die DB ja up and running ist.

Das Problem hast du ja generell immer bei laufenden Prozessen. Ich verwende LVM und mache mir ein Snapshot, den ich dann wegsichern kann.

[Sandman60]

Das Problem hast du ja generell immer bei laufenden Prozessen. Ich verwende LVM und mache mir ein Snapshot, den ich dann wegsichern kann.

Scho klar, aber auf dem PI?
1000 Wege führen nach Rom, wollte nur vermeiden das jemand einfach wegkopiert und sich dann bei einem Restore wundert warum die DB korrupt ist..

[2ndsky]

Scho klar, aber auf dem PI?

Vom Pi stand bisher nichts in dem Thread

[Sandman60]

Vom Pi stand bisher nichts in dem Thread

Auch wieder wahr, jeder projeziert halt sein Env. in die Threads.
Also dann mal zusammengefasst für die weniger IT-Affinen (muß ja nicht der TE sein):
Die Datenbank ist AFAIK die einzige Nutzdatendatei unter den bislang genannten Pfaden, welche sich während des Backups im permanenten Zugriff befindet, sprich ein einfacher Copy wird beim Restore sehr wahrscheinlich zu einer korrupten Datei führen. Sichern daher über Snapshottechnologie oder aber per sh.sql.dump bei Verwendung des PI-Image.