Backup

Kopia bezpieczeństwa InfluxDB

przez
Ostatnio, po przeniesieniu systemu na dysk SSD, dorzuciłem tam też instalację InfluxDB i Grafana. Niestety musiałem się pożegnać z historią, z powodu problemów z wykonaniem kopii bazy InfluxDB. Chciałbym tego uniknąć w przyszłości, dlatego do swoich backup’ów dorzuciłem InfluxDB. Jak wyglądał poprzedni plik opisywałem tutaj: https://cezarowy.blogspot.com/2017/11/kopia-bezpieczenstwa-bazy-folderu.html

Tym razem musiałem zrobić trochę inaczej, gdyż Influx zapisuje backup w kilku plikach. Chciałem mieć jeden, ładni ułożony w folderach, tak jak poprzednie – Domoticz, HABridge.

Założyłem więc dodatkowy folder, gdzie wykonuje się backup bazy, później kompresuję ją do innego folderu. Dodałem na końcu skryptu wykonującego kopię następujące linijki:

#Backup InfluxDB
sudo rm /media/Dysk/Influx/*.*
sudo influxd backup -portable -database domoticz /media/Dysk/Influx/
tar -zcvf /media/Dysk/Influx_backup/Influx_$TIMESTAMP.tar.gz /media/Dysk/Influx/
/usr/bin/find /media/Dysk/Influx_backup/ -name '*.tar.gz’ -mtime +31 -delete

Aaaaaa. Rozsypała mi się baza Domoticz! Co robić, co robić?

przez
A 'rozsypać’ się może z różnych powodów. Błąd zapisu na kartę, zanik napięcia, przejście w Domoticz z wersji stable na beta i z powrotem na stable.

Jaki jest objaw? W logach Domoticz widzimy informację

’…Database is malformed…’.

U mnie konkretnie był problem z LightingLog – odpowiada on za przetrzymywanie danych archiwalnych o czujnikach – błąd był przy nocnym czyszczeniu tej tabeli. A to skutkowało zwiększoną wielkością bazy danych. U Was może być różnie. Jest to w końcu baza plikowa, bez serwisu który dba o integralność danych, itp.

Najpierw
sudo apt-get install sqlite3

Trzeba też zatrzymać serwis Domoticz

sudo service domoticz stop

Następnie

cd domoticz
sqlite3 domoticz.db
pragma integrity_check;

Nie jest dobrze! Błędy, jak widać, są i to dość dużo. Spróbujemy poradzić sobie z nimi na razie najprostszą metodą – zrzucenie struktury bazy i danych do pliku ponowne załadowanie. W 99% przypadków powinno pomóc.

Skoro jest źle – trzeba działać!

Startujemy:

sqlite3 domoticz.db

.mode insert

.output dump.sql
.dump
.exit

Co zrobiliśmy? Poleciliśmy SQLite, aby wyeksportował całą naszą bazę (wraz ze strukturą) do pliku dump.sql

Teraz załadujemy ten plik już do nowej bazy. Jak to może nam pomóc? Ano wyeksportowana została poprawna struktura tabel oraz danych z bazy, także teraz tą dobrą wrzucimy do nowej. Wszystkie dane powinny zostać poprawne. W moim konkretnym przypadku tak było – mam nadzieję, że i u Was nie będzie to nic poważniejszego.

sqlite3 domoticz1.db < dump.sql

Załadowaliśmy nasze dane do bazy domoticz1.db.

Sprawdźmy, dla pewności, czy faktycznie nam to pomogło.

Wygląda dobrze, wystarczy zastąpić domoticz.db plikiem domoticz1.db i uruchomić domoticz.


sudo service domoticz start
Gotowe!

Kopia bezpieczeństwa bazy, folderu Domoticz oraz innych elementów

przez
Jak mówią, ludzie dzielą się na tych, którzy backupy robią i na takich, którzy będą robić.

Żeby za późno nie znaleźć się w tej drugiej grupie – szybki skrypt do tworzenia backupu (na przykład Domoticz i HABridge) na zewnętrzny dysk. W moim przypadku pendrive, z którego do dane czasem zgrywam na osobny dysk zewnętrzny. Jest co prawda mechanizm wbudowany w Domoticz, ale osobiście mi on nie odpowiadał – robi backup na tą samą kartę, na której jest Domoticz, więc sensu to nie ma…

Raz, dwa trzy, skrypt piszesz Ty. Nie ukrywam – jest to zmieniony pod moim kątem skrypt z Wiki Domoticz. Ale po to jest Wiki…

Zaczynamy więc od:

sudo nano /home/pi/domoticz/scripts/domoticz_backup.sh 

Wpisujemy (oczywiście zmieniając dane do Domoticz oraz foldery, na które chcecie kopiować). Ja, jak widać, dodatkowo robię sobie backup HABridge pod kątem Alexa.

DOMO_IP=”192.168.1.200″  # Domoticz IP 
DOMO_PORT=”80″        # Domoticz port 
TIMESTAMP=`/bin/date +%Y%m%d%H%M%S`
BACKUPFILE=”domoticzbackup_$TIMESTAMP.db” # backups will be named „domoticz_YYYYMMDDHHMMSS.db.gz”
BACKUPFILEGZ=”$BACKUPFILE”.gz

#Create backup and make tar archives
/usr/bin/curl -s http://$DOMO_IP:$DOMO_PORT/backupdatabase.php > /media/Dysk/Domoticz_backup/database/$BACKUPFILE
tar -zcvf /media/Dysk/Domoticz_backup/scripts/domoticz_scripts_$TIMESTAMP.tar.gz /home/pi/domoticz/scripts/
tar -zcvf /media/Dysk/Domoticz_backup/www/domoticz_wwwfolder_$TIMESTAMP.tar.gz /home/pi/domoticz/www/
tar -zcvf /media/Dysk/HABridge/HABridge_$TIMESTAMP.tar.gz /home/pi/habridge/data/

#Delete backups older than 31 days
/usr/bin/find /media/Dysk/Domoticz_backup/database/ -name '*.db’ -mtime +31 -delete
/usr/bin/find /media/Dysk/Domoticz_backup/scripts/ -name '*.tar.gz’ -mtime +31 -delete
/usr/bin/find /media/Dysk/Domoticz_backup/www/ -name '*.tar.gz’ -mtime +31 -delete
/usr/bin/find /media/Dysk/HABridge/ -name '*.tar.gz’ -mtime +31 -delete

Nadajemy uprawnienia do uruchamiania:
sudo chmod +x /home/pi/domoticz/scripts/domoticz_backup.sh
Efekt:


Ja ustawiłem sobie uruchamianie go na 1:30 w nocy w cron:
30 1 * * * sudo home/pi/domoticz/scripts/domoticz_backup.sh
Oby się Wam backup nigdy nie przydał… Ale niestety, podczas pracy z Raspberry Pi widzę, że nie jest to widzimisię, a konieczność! 
Oczywiście można go zmienić, aby backupy lądowały na zewnętrznym FTP, czy też dysku NAS. Dla mnie jednak ta forma jest wystarczająca.