SQLite czy MariaDB w Home Assistant? Recorder, InfluxDB i backup bez starych mitów
Kilka lat temu jedną z pierwszych porad po instalacji Home Assistanta była zmiana SQLite na MariaDB i ręczne ograniczenie Recordera. Gdybym stawiał system od początku w 2026 roku, nie zrobiłbym żadnej z tych rzeczy automatycznie. Najpierw sprawdziłbym, jak działa współczesny Recorder, co naprawdę zajmuje miejsce i które dane w ogóle warto przechowywać przez lata.
W części 1 o dobrych praktykach HAOS na Proxmoxie przygotowaliśmy fundament: CPU, RAM, VirtIO SCSI, Discard, QEMU Guest Agent, autostart i pierwszą warstwę backupu. Teraz schodzimy poziom niżej i zajmujemy się jednym z najbardziej mitologizowanych elementów Home Assistanta, czyli bazą danych.
Jeśli dopiero zaczynasz i potrzebujesz pełnej ścieżki od podstaw, a nie tylko decyzji administracyjnych, w kursie Home Assistant po polsku prowadzę całość krok po kroku. Ten artykuł skupia się na tym, co warto zrobić dobrze od początku i czego nie komplikować bez potrzeby.
Zacznę od mojej instalacji, bo wynik jest dość wymowny
Produkcyjny Home Assistant, na którym opieram tę serię, nie jest pustą instalacją przygotowaną tylko do zrobienia kilku screenów. Działa tam Zigbee2MQTT, MQTT, Node-RED, InfluxDB2, Grafana, ESPHome, Music Assistant, monitoring, komponenty głosowe i sporo innych usług. Automatyzacji mam około trzydziestu, a urządzeń i encji jest już na tyle dużo, że ręczne ich liczenie nie miałoby większego sensu.
Mimo tego Recorder nadal korzysta z SQLite.
| Recorder | SQLite |
| Wersja SQLite | 3.53.2 |
| Szacowany rozmiar Recordera | około 709 MiB |
| Dodatkowa baza danych | InfluxDB2 |
| Wizualizacja danych długoterminowych | Grafana |
Nie pokazuję tego po to, żeby udowodnić, że MariaDB jest niepotrzebna. Są instalacje, w których zewnętrzna baza ma bardzo dużo sensu.
Ten przykład pokazuje coś innego:
Recorder, SQLite i InfluxDB to trzy różne pojęcia
Zanim zaczniemy porównywać bazy, warto uporządkować nazwy. W dyskusjach bardzo często można przeczytać zdanie: „mam InfluxDB zamiast SQLite”. Technicznie najczęściej nie jest to prawda.
Recorder jest komponentem Home Assistanta odpowiedzialnym za zapisywanie historii encji do bazy danych. Jeśli chcesz przejść przez jego konfigurację i diagnostykę krok po kroku, mam osobną lekcję: Baza danych i Recorder: dlaczego Home Assistant zwalnia po kilku miesiącach.
SQLite jest domyślnym silnikiem bazy używanym przez Recorder.
MariaDB, MySQL i PostgreSQL są alternatywnymi silnikami, do których Recorder może zapisywać dane zamiast SQLite.
InfluxDB działa inaczej. Integracja Home Assistanta wysyła do niego wybrane zmiany stanów jako dodatkowy strumień danych. InfluxDB pracuje równolegle z bazą Recordera i jej nie zastępuje.
├── Recorder → SQLite → History / Logbook / dane HA
└── InfluxDB → dane czasowe → Grafana
I taki układ bardzo mi odpowiada. Home Assistant korzysta ze swojej zoptymalizowanej bazy do funkcji, które jej potrzebują, a dane, które chcę analizować przez długi czas, mogę równolegle wysłać do rozwiązania stworzonego właśnie do szeregów czasowych.
SQLite w 2026 roku nie jest tym samym problemem, który pamiętamy sprzed lat
Stare zalecenie zmiany bazy nie wzięło się znikąd. Przez lata bardzo dużo instalacji Home Assistanta działało na Raspberry Pi i kartach SD. Recorder wykonywał ciągłe zapisy, karta miała ograniczoną liczbę cykli zapisu, a duża baza potrafiła wpływać zarówno na wydajność, jak i żywotność nośnika.
Łatwo było więc zbudować prosty skrót myślowy:
MariaDB = profesjonalne i szybkie
Współczesny Home Assistant nie daje podstaw do tak prostego podziału. Oficjalna dokumentacja Recordera nazywa dziś SQLite nie tylko bazą domyślną, ale również rekomendowaną.
To dość mocne stwierdzenie. Gdyby pierwszą dobrą praktyką po instalacji miała być migracja do MariaDB, trudno byłoby jednocześnie nazywać SQLite rekomendowanym silnikiem.
Pod maską też zaszło sporo zmian
Jest jeszcze jeden aspekt, którego nie widać w interfejsie. Obecny schemat bazy Home Assistanta jest znacznie bardziej przemyślany pod kątem ograniczania duplikowanych danych.
Nazwa encji nie musi być powtarzana jako pełny tekst przy każdym kolejnym stanie. Home Assistant przechowuje identyfikatory encji w osobnej tabeli states_meta, a kolejne stany odwołują się do niej przez identyfikator.
Podobnie z atrybutami. Powtarzające się zestawy atrybutów są trzymane w tabeli state_attributes, zamiast kopiować ten sam duży JSON przy każdym rekordzie.
Sam event state_changed również nie jest obecnie dodatkowo duplikowany w tabeli events, bo informacje o zmianie stanu są już w tabeli states.
Porównywanie dzisiejszego Recordera do zachowania bazy sprzed kilku lat tylko na podstawie nazwy „SQLite” jest trochę jak porównywanie dwóch wersji Home Assistanta tylko dlatego, że obie mają niebieskie logo. Silnik bazy jest ten sam, ale sposób przechowywania i obsługi danych przez aplikację bardzo się zmienił.
Największy mit: purge po 10 dniach oznacza utratę danych po 10 dniach
To jest chyba najważniejsza rzecz do zrozumienia przed wpisaniem własnego purge_keep_days.
Domyślnie Home Assistant przechowuje szczegółowe stany przez 10 dni. Po tym czasie stare wpisy z tabeli states oraz krótkoterminowe statystyki są usuwane.
Nie oznacza to jednak, że po jedenastym dniu Home Assistant zapomina, jaka była temperatura, zużycie energii albo produkcja fotowoltaiki.
Short-term statistics
Dla obsługiwanych sensorów Home Assistant tworzy statystyki krótkoterminowe co 5 minut.
Long-term statistics
Z tych danych powstaje później agregacja godzinowa. Dla typowego sensora pomiarowego, na przykład temperatury, Home Assistant może przechować dla każdej godziny wartość minimalną, maksymalną i średnią.
Dla sensorów typu licznik przechowywane są informacje związane z narastającą wartością i sumą.
Jeśli interesuje Cię praktyczna strona długoterminowych statystyk w panelu Energia, w e-learningu pokazuję ją w lekcji Energy Dashboard krok po kroku. Na blogu możesz też zobaczyć konkretny przykład na urządzeniach w artykule Gniazdka IKEA w Home Assistant: TRETAKT, INSPELNING i Energy Dashboard.
I tutaj najważniejsze:
Home Assistant zapisuje tylko 24 agregowane rekordy na dobę dla danej statystyki, po jednym na godzinę. Dzięki temu można zachować wieloletni trend bez przechowywania każdego pojedynczego odczytu sensora.
Czyli nie ustawiać purge_keep_days na 365?
Nie mówię, że nigdy.
Mówię, że najpierw trzeba odpowiedzieć na pytanie: po co potrzebuję 365 dni historii w pełnej rozdzielczości?
Jeżeli chcę sprawdzić, jak zmieniała się temperatura w salonie przez ostatnie dwa lata, statystyka godzinowa jest zwykle więcej niż wystarczająca.
Jeśli analizuję produkcję PV, zużycie energii, temperaturę, wilgotność czy ciśnienie, również najczęściej nie potrzebuję informacji, że 14 lutego o 12:03:17 sensor pokazał 21,37°C, a kilkadziesiąt sekund później 21,31°C.
Są oczywiście dane, dla których szczegółowa historia przez dłuższy czas może mieć znaczenie. Wtedy zwiększenie retencji może być świadomą decyzją.
Ale nie robię tego globalnie „na wszelki wypadek”.
Domyślne 10 dni traktuję jako rozsądny punkt wyjścia. Jeżeli potrzebuję długiego trendu, sprawdzam najpierw, czy dana encja korzysta z long-term statistics. Dopiero później zwiększam szczegółową retencję całej bazy.
Recorder sam po sobie sprząta. I robi więcej, niż można przypuszczać
To kolejna rzecz, przez którą stare konfiguracje Recordera warto przeglądać bardzo krytycznie.
Domyślnie auto_purge jest włączone.
Home Assistant wykonuje purge każdej nocy około 04:12 czasu lokalnego.
To nie koniec. Domyślnie aktywne jest również auto_repack. Co drugą niedzielę po purge Home Assistant może przebudować bazę, aby odzyskać niewykorzystywaną fizycznie przestrzeń.
Usunięcie rekordów z bazy i fizyczne zmniejszenie pliku to dwie różne rzeczy. Po purge przestrzeń wewnątrz bazy może stać się ponownie dostępna do wykorzystania, ale sam plik nie musi natychmiast zmniejszyć rozmiaru. Od tego jest między innymi repack. Zanim więc po ręcznym purge uznamy, że „to nie działa”, warto wiedzieć, czego dokładnie oczekujemy.
Nie wyłączam auto_purge bez bardzo dobrego powodu
Jeżeli ktoś świadomie buduje własną politykę utrzymania bazy, może oczywiście wyłączyć mechanizmy automatyczne i zastąpić je własnymi procedurami.
Ale dla większości instalacji nie widzę w tym żadnej korzyści.
Wyłączenie purge i zapomnienie o nim to jeden z najprostszych sposobów na bazę rosnącą bez końca. Home Assistant bardzo wyraźnie ostrzega, że jeśli wyłączamy automatyczny purge, sami musimy zapewnić regularne uruchamianie odpowiedniej akcji czyszczącej.
Najpierw znajdź hałaśliwą encję. Dopiero potem używaj exclude
Drugim klasykiem starych poradników jest ogromna sekcja:
exclude:
domains:
– automation
– media_player
– …
entities:
– sensor.x
– sensor.y
– sensor.z
Filtrowanie Recordera jest bardzo przydatne. Sam mechanizm nie jest zły.
Nie podoba mi się natomiast podejście polegające na wycinaniu połowy systemu pierwszego dnia bez sprawdzenia, czy cokolwiek generuje problem.
Co właściwie oznacza „hałaśliwa encja”?
Nie musi to być sensor, którego główna wartość zmienia się co sekundę.
W Home Assistant stan encji składa się z wartości głównej i atrybutów. Encja może przez godzinę pozostawać w stanie playing, ale jej atrybuty zmieniają się przy każdej zmianie utworu, pozycji czy metadanych.
Każda taka aktualizacja może oznaczać kolejny wpis w historii.
To samo może dotyczyć źle zaprojektowanego sensora ESPHome, urządzenia raportującego moc z absurdalną częstotliwością, integracji aktualizującej duże atrybuty czy encji diagnostycznej, której historii nigdy nie będziemy oglądać.
2. Sprawdzam, czy rozmiar faktycznie szybko rośnie.
3. Szukam encji generujących najwięcej zapisów.
4. Oceniam, czy ich historia jest mi potrzebna.
5. Dopiero wtedy dodaję konkretny exclude.
Praktyczny sposób: znajdź największych „pisarzy” do bazy
Home Assistant ma oficjalną integrację SQL, która potrafi wykonać zapytanie tylko do odczytu. Jeśli nie podamy osobnego adresu bazy, integracja może korzystać z bazy Recordera.
Przy SQLite można wykorzystać zapytanie w tym stylu, aby zobaczyć encje mające najwięcej wpisów z ostatnich 24 godzin:
states_meta.entity_id,
COUNT(*) AS wpisy
FROM states
JOIN states_meta
ON states.metadata_id = states_meta.metadata_id
WHERE states.last_updated_ts > strftime(’%s’,’now’,’-1 day’)
GROUP BY states.metadata_id
ORDER BY wpisy DESC
LIMIT 20;
Nie używam takich zapytań do ręcznego usuwania czy poprawiania rekordów. Baza Recordera nie jest miejscem, w którym chcę własnoręcznie zmieniać schemat albo kasować wiersze.
Do diagnostyki odczyt jest bardzo przydatny. Do modyfikacji bazy korzystam z mechanizmów Home Assistanta. Jeśli problem nie jest oczywisty, przydaje się też standardowa ścieżka diagnostyczna z System Health, Repairs i logami Home Assistanta.
Kiedy exclude rzeczywiście ma sens?
Dobry kandydat to encja, która spełnia dwa warunki jednocześnie:
2. Jej historia nie daje mi praktycznej wartości.
Jeśli wykluczę sensor tylko dlatego, że „często się zmienia”, a za miesiąc będę chciał sprawdzić jego historię podczas awarii, optymalizacja właśnie zabrała mi dane diagnostyczne.
Dlatego nie zaczynam od dużej czarnej listy.
Zaczynam od obserwacji.
A co z commit_interval? Kolejny stary tuning, który trzeba rozumieć
Recorder domyślnie wykonuje commit do bazy co 5 sekund.
Zwiększenie tej wartości może ograniczyć liczbę operacji I/O. Home Assistant sam wskazuje, że może mieć to sens szczególnie przy nośnikach takich jak karta SD, gdzie ograniczenie ciągłych zapisów może poprawić żywotność.
Na HAOS działającym jako VM na SSD lub NVMe nie zmieniam jednak commit_interval automatycznie na 30 czy 60 sekund tylko dlatego, że znalazłem taką wartość w konfiguracji sprzed kilku lat.
SSD/NVMe + brak problemów z I/O = zostawiam domyślne 5 sekund. Zmieniam dopiero wtedy, kiedy wiem, jaki problem chcę rozwiązać.
Wolne miejsce na dysku: jedna reguła, o której łatwo zapomnieć
Baza może mieć 700 MB i wszystko wygląda świetnie. Problem zaczyna się wtedy, gdy cały dysk HAOS jest prawie pełny.
Dokumentacja Recordera podaje bardzo konkretną zasadę: zawsze powinniśmy mieć co najmniej tyle wolnej przestrzeni tymczasowej, ile zajmuje baza danych.
Jeżeli baza ma 2 GiB, na dysku musi być przynajmniej kolejne 2 GiB wolnego miejsca.
Dlaczego? Repack, naprawa albo migracja schematu podczas aktualizacji może wymagać utworzenia tymczasowej kopii części danych.
Wolne miejsce jest elementem bezpieczeństwa aktualizacji i utrzymania bazy, a nie tylko rezerwą na kolejne pliki.
Kiedy MariaDB naprawdę ma sens?
Po tym wszystkim można odnieść wrażenie, że jestem przeciwnikiem MariaDB.
Nie jestem.
Nie uważam tylko, że MariaDB jest obowiązkową poprawką do Home Assistanta.
Są scenariusze, w których sam rozważyłbym zmianę:
MariaDB dokłada też nowy punkt awarii
To jest druga strona medalu, o której w prostych poradnikach mówi się rzadziej.
Przy SQLite baza jest częścią instalacji Home Assistanta. HA uruchamia się, baza jest dostępna lokalnie i nie potrzebujemy dodatkowego hosta, sieci, danych logowania ani kolejnego procesu, który musi wystartować wcześniej.
Przy zewnętrznej MariaDB dochodzą:
• połączenie sieciowe,
• konto i hasło,
• wersja MariaDB,
• aktualizacje bazy,
• osobny backup,
• kolejność uruchamiania usług,
• dodatkowa diagnostyka przy problemach.
To wszystko da się zrobić bardzo dobrze.
Ale od tego momentu rozwiązanie jest bardziej złożone. I złożoność musi dawać nam coś w zamian.
MariaDB jako App czy osobny LXC na Proxmoxie?
Jeżeli ktoś chce MariaDB, ale nie ma konkretnego powodu do wydzielania jej z HAOS, instalacja jako Home Assistant App jest całkowicie rozsądnym rozwiązaniem. Supervisor pilnuje usługi, a administracja pozostaje prostsza.
Osobny LXC na Proxmoxie daje większą separację. Baza może działać niezależnie od restartu HAOS i można nią zarządzać jak osobnym elementem infrastruktury.
Tyle że wtedy trzeba pamiętać o kolejności startu. MariaDB musi być gotowa, zanim Recorder zacznie próbować się z nią łączyć.
Recorder ma wprawdzie mechanizmy ponawiania połączenia, domyślnie kilka prób z przerwami, ale nie traktuję tego jako zamiennika prawidłowej architektury.
Jeżeli w części 1 zdecydowaliśmy się wydzielić usługi, właśnie tutaj zaczyna mieć znaczenie Startup Order Proxmoxa.
Największa pułapka migracji: Home Assistant nie przeniesie Ci historii
To trzeba powiedzieć bardzo wyraźnie.
Oficjalnie migracja istniejącej historii Recordera pomiędzy silnikami baz danych nie jest wspierana. Zmiana db_url na MariaDB nie oznacza automatycznego przeniesienia dotychczasowej historii SQLite.
Po zmianie Home Assistant zacznie zapisywać historię do nowej bazy. Stary plik SQLite może nadal istnieć, ale nowy Recorder nie będzie z niego magicznie dobierał starszych danych.
Dlatego nie wykonuję migracji w piątek wieczorem tylko dlatego, że przeczytałem, że MariaDB „jest szybsza”.
Jeżeli już MariaDB, to aktualna i poprawnie skonfigurowana
Home Assistant wspiera MariaDB, ale dokumentacja nadal ostrzega przed określonymi starszymi wydaniami, które miały regresję wydajności powodującą duże obciążenie podczas zapytań historii lub purge.
Baza powinna również używać właściwego zestawu znaków utf8mb4.
Innymi słowy: przeniesienie Recordera do źle utrzymywanej MariaDB nie jest upgradem.
InfluxDB: u mnie ma inne zadanie niż Recorder
W mojej instalacji InfluxDB2 działa równolegle z SQLite. To świadoma decyzja i dokładnie tak opisuje tę integrację również dokumentacja Home Assistanta.
Recorder ma obsłużyć bieżącą historię Home Assistanta, Logbook oraz wewnętrzne funkcje systemu.
InfluxDB wykorzystuję tam, gdzie interesują mnie dłuższe szeregi czasowe i późniejsza analiza danych w Grafanie.
Nie wysyłam do InfluxDB wszystkiego dlatego, że mogę
To ten sam błąd co z Recorderem, tylko w drugą stronę.
InfluxDB może przyjąć zmiany praktycznie wszystkich typów encji. Nie oznacza to, że wieloletnia historia stanu przycisku, diagnostyki aktualizacji, RSSI każdego urządzenia i każdego odtwarzacza multimedialnego będzie kiedyś potrzebna.
Do długoterminowej analizy wybieram dane, które mają wartość:
• fotowoltaika,
• temperatura i wilgotność,
• parametry ogrzewania,
• woda i inne liczniki,
• dane techniczne, które rzeczywiście analizuję w czasie.
InfluxDB ma jeszcze jeden koszt: backup
Baza czasowa potrafi rosnąć znacznie większa niż sam Recorder. Jeżeli InfluxDB działa jako App wewnątrz HAOS, trzeba świadomie zdecydować, jak jego dane mają być backupowane.
Home Assistant sam zwraca uwagę, że duże Apps oraz ich dane mogą znacząco zwiększyć rozmiar kopii zapasowej. Większy backup to nie tylko więcej miejsca.
To również:
• dłuższy upload do chmury,
• dłuższy restore,
• większe wymagania dotyczące wolnego miejsca,
• większa szansa, że kopia przekroczy limit konkretnego storage.
Czy pięć lat danych z InfluxDB jest mi niezbędne do odtworzenia automatyki domu, czy jest to archiwum analityczne, które może mieć własną strategię backupu? Odpowiedź zależy od instalacji, ale warto podjąć tę decyzję świadomie zamiast przypadkiem dołączać ogromną bazę do każdej codziennej kopii HA.
Backup Home Assistanta w 2026 roku jest już zupełnie innym narzędziem
Jeżeli wracasz do Home Assistanta po kilku latach, ten element prawdopodobnie zaskoczy Cię bardziej niż sama baza.
Od 2025 roku Home Assistant ma rozbudowany system automatycznych backupów, harmonogram, retencję, kilka lokalizacji i szyfrowanie. Nie trzeba już budować całej podstawowej strategii backupowej z własnych skryptów.
Home Assistant rekomenduje codzienny backup i przechowywanie kopii poza urządzeniem, a najlepiej również poza domem. Pełną konfigurację pokazuję w lekcji Backup i restore: automatyczne kopie zapasowe bez których nie ruszasz dalej.
U mnie są dwie niezależne lokalizacje
W mojej instalacji backup nie kończy się na pliku leżącym obok działającego HAOS. Mam osobny fizyczny storage przeznaczony na kopie oraz dodatkową kopię wysyłaną do Google Drive.
Do tego dochodzi jeszcze warstwa Proxmoxa, czyli możliwość wykonania backupu całej maszyny wirtualnej.
Backup HA daje mi przenośność. Mogę postawić nowy HAOS i odtworzyć konfigurację.
Backup VM pozwala szybko przywrócić kompletną maszynę na Proxmoxie.
Kopia off-site ratuje mnie wtedy, kiedy awaria obejmie nie tylko jeden dysk, ale cały serwer albo całą lokalizację.
Ważna zmiana z 2026: nowe szyfrowanie backupów
Od wersji 2026.4 Home Assistant zaczął używać nowej generacji formatu szyfrowania backupów opartego na SecureTar v3. Projekt został dodatkowo poddany niezależnemu audytowi bezpieczeństwa.
Dla użytkownika najważniejsze jest to, że zmiana odbywa się automatycznie i stare backupy pozostają obsługiwane.
Nie zmieniła się natomiast jedna rzecz:
Zaszyfrowany backup, do którego straciliśmy klucz, może być perfekcyjnie zachowany i jednocześnie całkowicie bezużyteczny.
Backup przed aktualizacją: dziś nie trzeba o nim pamiętać ręcznie za każdym razem
W ustawieniach automatycznych backupów możemy określić, czy Home Assistant ma wykonywać kopię przed aktualizacją. Przy aktualizacjach OS i Core interfejs również potrafi zaproponować wykonanie świeżego backupu.
To nie znaczy, że klikam „Aktualizuj” bez zastanowienia tylko dlatego, że powstaje backup. O bezpiecznej kolejności, Core, Supervisorze, OS, Apps i sprawdzaniu zmian przed aktualizacją mam osobną lekcję: Aktualizacje: Core, Supervisor, OS i dodatki bez niespodzianek.
Jeden stary obowiązek administracyjny można dzisiaj bardzo dobrze zautomatyzować.
Backup, którego nigdy nie odtworzyłeś, nadal jest tylko obietnicą
To jedna z rzeczy, w której praktycznie cała społeczność jest zgodna.
Sukces komunikatu „Backup completed” nie daje stuprocentowej pewności, że w dniu awarii proces odzyskiwania przebiegnie tak, jak zakładaliśmy.
Proxmox daje mi tutaj świetne narzędzie, bo mam również oddzielną instancję Home Assistanta do testów. Mogę wykorzystać środowisko wirtualne do przećwiczenia restore bez rozbierania działającego systemu.
Oczywiście testowej kopii produkcji nie uruchamiam bezmyślnie w tej samej sieci z aktywnymi automatyzacjami próbującymi sterować prawdziwym domem. Test restore i klon produkcji to temat, przy którym izolacja ma bardzo duże znaczenie.
Co zrobiłbym dziś na całkowicie świeżej instalacji?
Gdybym jutro postawił nowy Home Assistant OS, konfiguracja bazy w pierwszym dniu byłaby zaskakująco krótka.
Tak. Niczego bym tam na początku nie dopisywał.
Zostawiłbym:
✓ 10 dni szczegółowej historii,
✓ auto_purge,
✓ auto_repack,
✓ domyślny commit_interval.
Następnie skonfigurowałbym backup i używał systemu.
Po kilku tygodniach sprawdziłbym rozmiar bazy oraz tempo jej wzrostu.
Jeśli wszystko wygląda normalnie, nie robiłbym nic.
A kiedy zaczynam optymalizować?
Gdzie sprawdzić swoją bazę bez terminala?
Home Assistant potrafi pokazać podstawowe informacje o Recorderze bez zaglądania do plików.
W sekcji Recorder znajdziemy między innymi typ silnika, wersję bazy i szacowany rozmiar. To właśnie z tego miejsca pochodzi mój wynik około 709 MiB.
Stare i nowe dobre praktyki w jednym miejscu
| Temat | Stare podejście | Moja praktyka dziś |
|---|---|---|
| Baza | Od razu MariaDB | Najpierw SQLite |
| Historia | 365 dni szczegółowych danych | 10 dni + long-term statistics |
| Recorder exclude | Duża lista pierwszego dnia | Najpierw znajduję realne źródło zapisów |
| Purge | Własne skrypty | Domyślny auto_purge |
| Repack | Ręczna obsługa | Domyślny auto_repack |
| InfluxDB | „Zamiast SQLite” | Równolegle, do wybranych analiz |
| Backup | Plik na tym samym urządzeniu | HA + VM + off-site |
| Optymalizacja | Zanim pojawi się problem | Po pomiarze |
Moja konfiguracja nie jest wzorcem. Jest testem rzeczywistości
To rozróżnienie chcę utrzymać przez całą serię.
U mnie działa SQLite, InfluxDB i Grafana. To nie znaczy, że każdy czytelnik powinien jutro instalować InfluxDB i Grafanę.
U mnie baza SQLite ma około 709 MiB. To nie znaczy, że baza mająca 3 GB jest automatycznie źle skonfigurowana.
U mnie nie ma obecnie powodu do przechodzenia na MariaDB. To nie znaczy, że w instalacji z kilkoma tysiącami bardzo aktywnych encji MariaDB nie może okazać się lepszym rozwiązaniem.
Realna instalacja daje nam punkt odniesienia. Dokumentacja i pomiary mówią, czy decyzja jest dobrą praktyką.
Zmieniam ją dopiero wtedy, kiedy potrafię wskazać ograniczenie SQLite, które w mojej instalacji rzeczywiście występuje. Do tego czasu korzystam z rozwiązania prostszego, wspieranego i rekomendowanego przez Home Assistanta.
Moja checklista bazy i backupu dla nowej instalacji
✓ Zostawiam domyślne 10 dni Recordera.
✓ Nie wyłączam auto_purge ani auto_repack.
✓ Nie zmieniam commit_interval bez powodu.
✓ Sprawdzam long-term statistics zanim zwiększę retencję.
✓ Exclude dodaję na podstawie pomiaru, nie gotowej listy z forum.
✓ Pilnuję wolnego miejsca na dysku.
✓ Konfiguruję automatyczny backup HA.
✓ Kopię trzymam również poza hostem.
✓ Zachowuję Emergency Kit poza HA.
✓ Jeśli używam Proxmoxa, mam dodatkowo backup VM.
✓ Okresowo sprawdzam restore.
Czego nie robię na starcie
✕ purge_keep_days = 365 „bo chcę historię”,
✕ wyłączenia auto_purge,
✕ gigantycznego recorder.exclude,
✕ commit_interval = 30 tylko dlatego, że tak było w starym poradniku,
✕ wysyłania wszystkich encji do InfluxDB,
✕ ręcznej modyfikacji tabel Recordera,
✕ backupu tylko na tym samym dysku,
✕ założenia, że plik backupu działa, jeśli nigdy nie wykonałem restore.
Co dalej w serii?
Mamy już poprawnie przygotowaną VM na Proxmoxie. Wiemy, kiedy zostawić SQLite, kiedy zainteresować się MariaDB i jak rozdzielić zadania Recordera oraz InfluxDB. Mamy również backup, który nie kończy się na tym samym SSD co działający Home Assistant.
W kolejnej części zajmiemy się warstwą, która bardzo często jest traktowana po macoszemu, dopóki pierwszy raz nie wydarzy się coś naprawdę nieprzyjemnego:
Management Proxmoxa, SSH, klucze, 2FA, firewall, aktualizacje, UPS, kontrolowany shutdown, monitoring SSD, powiadomienia, sieć zarządzająca i plan działania wtedy, kiedy host przestanie się uruchamiać.
Na koniec
Pytanie, od którego zaczęliśmy tę serię, brzmiało mniej więcej: czy po siedmiu latach nadal trzeba instalować MariaDB i poprawiać Recorder?
Moja odpowiedź brzmi:
SQLite jest dziś rekomendowanym punktem startowym. Recorder sam zarządza purge i repackiem. Long-term statistics rozwiązują dużą część problemu wieloletniej historii. InfluxDB można dołożyć wtedy, kiedy rzeczywiście chcemy bardziej zaawansowanej analizy danych. MariaDB pozostaje bardzo dobrym narzędziem, ale jest narzędziem do konkretnego zadania, a nie obowiązkowym elementem instalacji.
Najlepsza optymalizacja bazy to ta, której potrzebę najpierw potrafisz zmierzyć.
Część 1: Home Assistant na Proxmoxie, dobre praktyki dla HAOS VM
E-learning: Baza danych i Recorder
E-learning: bezpieczne aktualizacje Home Assistanta
Blog: praktyczny przykład Energy Dashboard i długoterminowych statystyk
