Koko tämä sarja on nojannut yhteen oletukseen, jota ei ollut kertaakaan koeteltu: että jos EnergyHub hajoaa, sen saa palautettua. Varmuuskopioita on otettu joka yö, ne on kopioitu pilveen, ja niiden koko ja tarkistussumma on tarkistettu. Silti mikään näistä ei todista sitä ainoaa asiaa, joka lopulta merkitsee — että tyhjästä koneesta saa rakennettua toimivan järjestelmän. Tämä osa kertoo siitä illasta, jona se oletus vihdoin testattiin: puhdas Debian tyhjälle levylle, yksi palautuspaketti, ja kysymys, johon ei ollut aiempaa vastausta.
Lyhyt vastaus: se toimi. Pitkä vastaus on kiinnostavampi, koska matkalla löytyi kaksi vakavaa mutta rajattua vikaa palautusautomaatiossa — ja koska palautuksen jälkeen syntyi jotain, joka on yhtä paljon turvallisuusongelma kuin varajärjestelmä.
Miksi tämä piti tehdä ollenkaan
Aiemmassa osassa datalaadusta kirjoitin, että hiljainen data-aukko on vaarallisempi kuin näkyvä virhe. Varmuuskopioilla on tismalleen sama ongelma. Backup, joka ei koskaan palaudu, näyttää joka päivä onnistuneelta: arkisto syntyy, tarkistussumma täsmää, pilvikopio menee läpi. Kaikki vihreää. Ja silti se voi olla täysin hyödytön — puuttuva salaisuustiedosto, väärä hakemistorakenne, tai vain se, ettei kukaan ole koskaan kokeillut. Ainoa tapa tietää on rakentaa järjestelmä uudelleen tyhjästä ja katsoa, käynnistyykö se.
Julkaistuissa osissa on aiemmin kuvattu varmuuskopiointi rclonella ja pilvitallennukseen. Se kuvasi todellisuutta silloin. Myöhemmässä auditoinnissa selvisi, että pelkkä yöarkisto ei yksin riitä puhtaan koneen palauttamiseen — se on palautuksen tärkein dataosa, mutta sen ympärille tarvitaan vielä erikseen salaisuudet, projektin juuri, tarkat Docker-imaget ja itse palautusautomaatio. Näistä koottiin erillinen, täydellinen palautuspaketti, ja juuri se laitettiin tässä kokeessa tulikokeeseen.
Koeasetelma
Palautuskoneeksi otettiin vanha läppäri, jossa on 500 gigatavun mekaaninen kiintolevy — tarkoituksella vaatimaton, koska varakoneen ei kuulu olla parempi kuin mitä hätätilanteessa oikeasti on käsillä. Sille asennettiin puhdas Debian tyhjälle levylle, ilman työpöytäympäristöä, pelkkä SSH ja perustyökalut. Palautuspaketti — kooltaan noin puolitoista gigatavua — siirrettiin tuotantokoneelta USB-tikulla, ja sen eheys tarkistettiin joka siirtovaiheessa: Windowsin puolella, USB-tikulta ja vielä kiintolevylle purettuna. Sama periaate kuin telemetriatyössä: tarkistussumma varmistetaan joka rajan yli, ei vain kerran.
Aikajana oli tiukka ja siksi vakuuttava. Tuore varmuuskopio käynnistyi illalla, palautuspaketti valmistui reilussa minuutissa, ja itse palautus tyhjälle koneelle vei kaikkineen noin kymmenen minuuttia. Sen jälkeen kaikki viisi palvelua — tietokanta, viestivälittäjä, visualisointi, Home Assistant ja Node-RED — olivat pystyssä. Ratkaisevin yksittäinen mittari oli tietokannan historiadata: palautuiko sinne oikeasti se lämpöpumpun raakatelemetria, jota edellinen osa käsitteli, vai pelkkä tyhjä tietokantarakenne. Se palautui, aikaleimoineen ja mittausarvoineen. Kone, jota ei tuntia aiemmin ollut olemassa, tunsi talon lämmityshistorian.
Palautuksen tärkein testi tehtiin vasta uudelleenkäynnistyksessä
Kun palvelut olivat pystyssä ja status vihreä, olisi ollut houkuttelevaa julistaa koe onnistuneeksi. Mutta järjestelmä, joka toimii kerran käsin käynnistettynä, ei vielä ole palautunut — se on vasta koottu. Oikea kysymys on, selviääkö se uudelleenkäynnistyksestä ilman käsiä.
Kone käynnistettiin uudelleen. Wi-Fi liittyi itsestään takaisin, SSH palasi, Docker käynnisti kaikki viisi konttia ilman yhtäkään käsikomentoa, ja noin kahdessa minuutissa kaikki HTTP-palvelut vastasivat. Node-RED saavutti terveen tilan, ja paikallinen viestintätesti meni läpi. Vasta tämä teki kokeesta uskottavan. Sama periaate on kulkenut koko tämän sarjan läpi lämpöpumpun ja sähköauton final gate -siirroissa: mikään ei ole valmista ennen kuin se on todennettu restartin yli. Palautuskin todistetaan vasta silloin, kun kone osaa nousta itse.
Kaksi vikaa, jotka eivät estäneet palautusta mutta paljastivat automaation heikkoudet
Itse data ja palvelut palautuivat, mutta palautusautomaatiosta löytyi kaksi vakavaa toteutusvirhettä. Kumpikin on juuri sitä luokkaa, joka ei näy ennen kuin joku oikeasti ajaa palautuksen läpi — mikä on koko harjoituksen paras perustelu.
Ensimmäinen koski hakemisto-oikeuksia. Salaisuudet oli pakattu arkistoon tavalla, joka palautettaessa muutti kotihakemiston oikeudet niin, ettei koneelle enää päässyt kirjautumaan normaalisti — komentotulkki ja pääkäyttäjäoikeuksien nosto alkoivat kumpikin vastata ”käyttö estetty”. Palautunut järjestelmä oli teknisesti pystyssä mutta käytännössä lukossa. Korjaus tehtiin koneen paikalliselta konsolilta palauttamalla hakemisto-oikeudet oikeiksi. Juurisyy on tuttu koko sarjasta: arkisto oli tallentanut mukaansa myös ylätason hakemistojen oikeudet, ja purku juureen levitti ne koko polkuun. Korjauslistan ykkösasia on pakata salaisuudet niin, että ne purkautuvat vain omaan hakemistoonsa eivätkä kajoa juuripolun oikeuksiin.
Toinen vika oli petollisempi, koska se valehteli väärään suuntaan. Palautuksen automaattinen verifiointi ilmoitti, ettei tietokannan historiadataa löytynyt — vaikka data oli todellisuudessa täysin tallessa. Vika oli itse tarkistuskyselyssä: se yhdisti eri tietotyyppisiä kenttiä tavalla, joka tuotti virheen tietokannan sisällön sijaan. Toisin sanoen verifiointi hylkäsi terveen palautuksen. Tämä on vaarallisempi kuin miltä kuulostaa. Väärä epäonnistuminen palautustilanteessa voi saada hätääntyneen ylläpitäjän hylkäämään täysin toimivan palautuksen ja aloittamaan alusta — juuri silloin kun aikaa ja hermoja on vähiten. Korjaus vaihtaa tarkistuksen kyselyyn, joka hakee yhden tunnetun mittauksen ilman tyyppien yhdistämistä, ja erottaa selkeästi kaksi eri tilaa: ”data palautui” ja ”verifiointi epäonnistui”. Nämä eivät saa näyttää samalta.
Kolmas, lievempi havainto oli, että automaattinen verifiointi ei malttanut odottaa. Se tarkisti Home Assistantin vain viisitoista sekuntia käynnistyksen jälkeen, sai vastaukseksi tyhjän — ja noin kahden minuutin kuluttua palvelu vastasi normaalisti. Kiinteä odotusaika oli yksinkertaisesti liian lyhyt. Korjaus on ehtopohjainen odotus, joka kysyy toistuvasti viiden minuutin ajan sen sijaan että luottaisi yhteen kiinteään sekuntimäärään. Sama opetus kuin Voimapirtin puolella: älä oleta valmistumista, todenna se.
Palautettu kone on ladattu ase
Tässä on koko kokeen tärkein oivallus, ja se on turvallisuuskysymys ennen kuin se on varajärjestelmäkysymys. Palautettu läppäri ei ole viaton varakone, jonka voi huoletta kytkeä nurkkaan odottamaan. Se sisältää tuotannon asetukset, laiteosoitteet ja ohjauslogiikan — ja jos se kytketään talon verkkoon, se voi tavoittaa oikeat laitteet välittömästi.
Docker käynnistää kaikki kontit automaattisesti bootissa. Palautetut viestit ja tilat voivat aktivoida päätöksenteon heti. Ja jos sekä alkuperäinen tuotantokone että palautettu kone olisivat yhtä aikaa verkossa, syntyisi tilanne, jota kannattaa pysähtyä miettimään: kaksi täysin toimivaa EnergyHubia, jotka molemmat luulevat omistavansa samat releet, samat MQTT-aiheet ja samat laitteet. Ne voisivat lähettää ristiriitaisia komentoja samalle sähköauton latausreleelle tai samalle lämpöpumpulle. Automaatiossa tätä kutsutaan split-brain-tilanteeksi, ja se on pahempi kuin ei varakonetta lainkaan — koska kaksi ohjainta, jotka kamppailevat samasta laitteesta, tuottaa arvaamatonta käytöstä juuri siihen fyysiseen järjestelmään, jonka piti olla hallinnassa.
Siksi palautunut kone on tässä vaiheessa nimenomaan kylmä varakone: sammutettuna, verkosta irti, odottamassa. Se on todistetusti toimiva, mutta sitä ei saa vain liittää verkkoon. Turvallinen käyttöönotto vaatii hallitun vaihtomenettelyn, jonka ehdoton ensimmäinen askel on varmistaa, että vanha kone on varmasti pois käytöstä ennen kuin uusi päästetään verkkoon. Yksi ohjain kerrallaan, ei koskaan kahta.
Palautuksessa itsessään sama periaate toteutettiin verkkoeristyksellä: koko koe ajettiin erillisessä verkossa, ei talon tuotantoverkossa, juuri siksi että palautetut asetukset voisivat muuten tavoittaa oikeat laitteet heti kun verkko sen sallii. Palautusta ei ajeta tuotanto-osoitteistossa. Se on yksi niistä säännöistä, jotka tuntuvat ylivarovaisilta kunnes tajuaa, että palautettu järjestelmä ei tiedä olevansa koe — se luulee olevansa tuotanto ja käyttäytyy sen mukaan.
Mitä koe ei vielä todistanut
Rehellisyyden nimissä on sanottava selkeästi, mitä tämä koe ei osoittanut. Oikeiden laitteiden — sähköauton, lämpöpumpun, aurinkoinvertterin, energiamittarien — yhteyksiä ei testattu, koska koe ajettiin tarkoituksella eristetyssä verkossa ilman pääsyä niihin. Hallittua tuotantoon vaihtoa vanhalta koneelta uudelle ei tehty; se on edelleen suunnitelma, ei todennettu menettely. Etähallintaidentiteettiä ja pilvivarmennuksen asetuksia ei aktivoitu. Ja mikä tärkeintä: käytetty palautuspaketti oli yhden illan jäädytetty tilannekuva. Se ei päivity myöhemmillä öillä automaattisesti. Jos tuotantokone rikkoutuisi kuukausien päästä, tämän paketin data olisi vanhaa, ellei siihen palautettaisi tuoreinta yövarmistusta erikseen.
Tämä johtaa suoraan siihen, mitä seuraavaksi on parannettava.
Kolme tasoa ja se, mikä yöarkistosta puuttuu
Koe jäsensi varmistuksen kolmeen tasoon, jotka palvelevat eri tarkoitusta. Yöarkisto on nopea ja pieni, kelpaa datan päivittäiseen turvaamiseen ja pilveen vientiin. Täysi palautuspaketti — salaisuuksineen, projektin juurineen ja Docker-imageineen — tehdään harvemmin, mutta vain se mahdollistaa palautuksen puhtaalle koneelle. Levykuva on valinnainen kolmas taso saman koneen nopeaan palautukseen, muttei korvaa kahta ensimmäistä. Vasta nämä yhdessä muodostavat kokonaisuuden, jossa yhden tason puute ei kaada koko palautettavuutta.
Selvin parannuskohde on, että salaisuudet — ne tiedostot, joita ilman mikään ei käynnisty — eivät saa elää vain tuotantokoneella tai satunnaisessa täydessä paketissa. Niille tarvitaan oma, salattu varmistuksensa, joka viedään turvaan erikseen. Tähän liittyy kokeen kiusallisin yksityiskohta: palautuspaketti sisältää selväkielisiä tunnuksia ja salasanoja, mikä tekee sekä USB-tikusta että sen Windows-kopiosta arkaluontoista aineistoa. Prosessin on jatkossa salattava paketti ja säilytettävä purkuavain erillään — salaamatonta pakettia ei jätetä lojumaan tavalliselle työpöytäkoneelle.
Yövarmistuksesta pitää myös tulla itseään valvova. Sen kuuluu epäonnistua äänekkäästi, jos arkistoa ei synny, tarkistussumma ei täsmää, Node-REDin vuot eivät ole kelvollista JSONia, Home Assistantin oleelliset hakemistot puuttuvat, tietokannan varmistus on tyhjä, arkiston koko poikkeaa rajusti totutusta, pilvikopio ei vastaa paikallista tiedostoa, tai edellisestä onnistuneesta pilvivarmistuksesta on kulunut liian kauan. Jokainen näistä on hiljainen vika, joka ilman omaa hälytystään huomataan vasta silloin kun palautusta oikeasti tarvitaan — eli pahimmalla mahdollisella hetkellä.
Opit
Varmuuskopio ei ole varmuuskopio ennen palautustestiä. Onnistuneelta näyttävä backup voi olla täysin hyödytön, eikä sitä voi tietää katsomatta. Ainoa todiste palautettavuudesta on rakentaa järjestelmä tyhjästä ja katsoa nouseeko se — mieluiten vielä uudelleenkäynnistyksen yli.
Väärä epäonnistuminen on palautuksessa vaarallisempi kuin väärä onnistuminen. Verifiointi, joka hylkää terveen palautuksen, voi saada hylkäämään toimivan järjestelmän juuri silloin kun paniikki on suurimmillaan. ”Data palautui” ja ”verifiointi epäonnistui” on pidettävä ehdottomasti erillään.
Palautettu kone on tuotantokone, joka ei tiedä olevansa koe. Se sisältää oikeat asetukset ja tavoittaa oikeat laitteet heti kun verkko sallii. Kaksi yhtä aikaa toimivaa ohjainta on pahempi kuin ei varakonetta — split-brain samasta releestä on juuri se arvaamattomuus, jota koko järjestelmä pyrkii välttämään. Yksi ohjain kerrallaan.
Salaisuudet ovat erillinen ongelma datasta. Tokeneita ja salasanoja ei voi käsitellä samalla huolettomuudella kuin mittausdataa. Ne vaativat oman salatun varmistuksensa ja avaimen, joka säilytetään erillään — muuten koko palautuspaketti on vuotoriski.
Palautettavuus on ominaisuus, joka pitää harjoitella, ei kertaluontoinen tarkistus. Pieni verifiointi joka yö, täysi paketti jokaisen merkittävän muutoksen jälkeen, ja päästä päähän -palautus erilliselle koneelle säännöllisin väliajoin. Muuten palautusohje vanhenee hiljaa samalla tavalla kuin konfiguraatio osassa 18.
Mitä vielä puuttuu
Palautusautomaatiosta korjataan seuraavaksi ne kaksi vikaa, jotka koe paljasti: salaisuuksien purku niin ettei se riko hakemisto-oikeuksia, ja verifiointi joka ei hylkää tervettä dataa. Sen jälkeen rakennetaan uusi paketti ja ajetaan toinen puhdas palautus varmistukseksi. Varakoneelle suunnitellaan pysyvä lukko, joka estää Dockeria käynnistymästä automaattisesti ja torjuu tuotantoverkon ennen erillistä, tietoista vaihtokomentoa — niin että koneen voi käynnistää turvallisesti tarkastusta varten ilman split-brain-riskiä. Docker-imaget kiinnitetään tarkkaan versioon, ettei myöhempi päivitys vaihda niitä huomaamatta. Ja salaisuuksien salattu offsite-varmistus sekä hallitun tuotantoon vaihdon runbook — sellainen, joka on saatavilla myös ilman internetiä — ovat molemmat vielä tekemättä.
Varakone on nyt olemassa ja todistetusti toimiva. Mutta valmiudella on oma määritelmänsä, joka täyttyy vasta kun tuorein testattu paketti on käsillä, salaisuudet ovat turvassa erikseen, kone on lukossa tai sammuksissa, ja vaihdon ohje on luettavissa silloinkin kun kaikki muu on poikki. Siihen asti tämä on toimiva koe eikä valmis järjestelmä — mikä on täsmälleen se rehellinen ero, jota koko tämä sarja on yrittänyt pitää näkyvissä.
Palautuskoe vastasi kysymykseen, joka oli roikkunut vastaamattomana koko rakennusprojektin ajan: saako tämän palautettua? Saa. Mutta vastaus tuli varauksin, ja juuri ne varaukset ovat se työ, joka nyt on edessä.
Seuraavaksi rakennetaan yhdestä lämpöpumpun näytteestä jälkikäteen auditoitava rivi, jossa komento, lupa ja fyysinen reletila ovat oikein ajallisesti kohdistettuja. Se osoittautui hankalammaksi kuin uskoin — ei siksi että logiikka olisi monimutkaista, vaan siksi että data valehtelee monella tavalla onnistuneelta näyttäessään. Mukana muun muassa objekti, jossa on kaikki oikeat kentät ja oikea aikaleima mutta joka silti hylätään, koska se tulee ”väärästä maailmasta”. Ja koska lämmitysdataa ei voi kerätä jälkikäteen, tämä on aito, sään sanelema kilpajuoksu.