Varmuuskopiointi ei ole valinnainen: WordPress-sivuston backup-strategia käytännössä

Miksi hosting-palvelun oma backup ei riitä

Monella isännöintipalvelulla on jonkinlainen automaattinen varmuuskopiointi mukana paketissa, ja se on parempi kuin ei mitään. Siinä on kuitenkin kolme toistuvaa ongelmaa.

Ensinnäkin varmuuskopio säilyy usein samalla palvelimella tai samassa infrastruktuurissa kuin alkuperäinen sivusto. Jos palvelin kaatuu kokonaan, palvelun tarjoaja ajautuu ongelmiin, tai tiliä kohtaa hyökkäys, varmuuskopio voi kadota samaan aikaan alkuperäisen datan kanssa.

Toiseksi säilytysaika on usein lyhyt, tyypillisesti seitsemästä kolmeenkymmeneen päivään. Jos ongelma huomataan vasta myöhemmin, kuten kävi tuolle asiakkaalle, ehjää versiota ei enää löydy.

Kolmanneksi näitä varmuuskopioita ei juuri koskaan testata. Moni saa vasta kriisin keskellä tietää, että varmuuskopio oli viallinen, osittainen tai ei sisältänyt tietokantaa lainkaan.

3-2-1-sääntö sovellettuna WordPressiin

Tietoturva-alalla vakiintunut nyrkkisääntö on yksinkertainen: pidä vähintään kolme kopiota datasta, kahdella eri tallennusvälineellä, joista yksi sijaitsee fyysisesti tai loogisesti eri paikassa kuin alkuperäinen.

WordPress-sivustolla tämä tarkoittaa käytännössä kolmea kerrosta. Ensimmäinen on alkuperäinen, tuotannossa oleva sivusto palvelimellasi. Toinen on palvelintason snapshot, esimerkiksi Hetzner Cloudin automaattiset levykuvat, jotka mahdollistavat nopean palautuksen infrastruktuurin tasolla. Kolmas on sovellustason varmuuskopio, joka on tallennettu kokonaan eri palveluun, esimerkiksi Cloudflare R2:een tai muuhun S3-yhteensopivaan objektivarastoon.

Näistä kolmesta juuri kolmas kerros unohtuu useimmin. Palvelintason snapshotit suojaavat laiterikolta, mutta eivät auta, jos ongelma on itse sisällössä: virheellinen päivitys, tietokantaa korruptoiva lisäosa, tai kokonaan poistettu tili palveluntarjoajan päässä.

Mitä pitää varmuuskopioida, ei vain tiedostoja

WordPress-sivusto koostuu kahdesta erillisestä osasta, jotka molemmat pitää varmuuskopioida yhdessä, ei erikseen ilman koordinointia.

Tiedostojärjestelmä sisältää ydinasennuksen, teemat, lisäosat ja wp-content/uploads-kansion, jossa ovat kaikki ladatut kuvat ja media. Tietokanta puolestaan sisältää kaiken sisällön: artikkelit, sivut, kommentit, käyttäjätiedot ja asetukset.

Jos varmuuskopioit vain tiedostot mutta et tietokantaa, palautettu sivusto näyttää oikealta mutta on tyhjä sisällöltä. Jos varmuuskopioit vain tietokannan mutta et uploads-kansiota, kaikki kuvat ja liitteet katoavat, vaikka teksti palautuisikin. Toimiva varmuuskopio sisältää molemmat, otettuina samalla hetkellä, jotta ne pysyvät synkronissa keskenään.

Työkalut, joita itse käytän

WP-CLI on tehokkain tapa automatisoida varmuuskopiointi palvelintasolla ilman selainpohjaista lisäosaa, joka kuluttaa resursseja tuotantosivustolla. Yksinkertainen skripti voi näyttää tältä:

#!/bin/bash
DATE=$(date +%Y-%m-%d)
BACKUP_DIR="/var/backups/wordpress/$DATE"
mkdir -p "$BACKUP_DIR"

# Tietokanta
wp db export "$BACKUP_DIR/database.sql" --path=/var/www/sivusto

# Tiedostot
tar -czf "$BACKUP_DIR/wp-content.tar.gz" /var/www/sivusto/wp-content

# Siirto ulkoiseen varastoon (esim. rclone Cloudflare R2:een)
rclone copy "$BACKUP_DIR" remote:varmuuskopiot/sivusto/$DATE
Tämä ajetaan cronilla, esimerkiksi kerran vuorokaudessa yöllä, jolloin kävijämäärä ja palvelinkuorma ovat pienimmillään.

Jos et halua rakentaa omaa skriptiä, UpdraftPlus on vakiintunut lisäosa, joka hoitaa saman asian selainpohjaisesti ja tukee suoraa siirtoa pilvitallennukseen. Se on hyvä lähtökohta pienemmälle sivustolle, jossa itse rakennettu automaatio olisi ylimitoitettu.

Testaa palautus, älä vain oleta

Tämä on se osa, jonka useimmat ohittavat. Varmuuskopio, jota ei ole koskaan palautettu testiympäristöön, on vain oletus toimivuudesta, ei todiste siitä.

Suosittelen kalenteroimaan palautustestin neljännesvuosittain: ota tuorein varmuuskopio, pystytä se erilliseen testiympäristöön (esimerkiksi alidomainiin tai paikalliseen kehitysympäristöön), ja tarkista, että sivusto toimii, kirjautuminen onnistuu ja sisältö näyttää oikealta. Tämä paljastaa ongelmat silloin, kun niillä ei ole vielä väliä, ei silloin kun asiakas soittaa paniikissa.

Säilytysaika ja versiointi

Yksi varmuuskopio ei riitä, koska ongelma huomataan usein viiveellä. Käytännön minimi on pitää useampi versio rinnakkain:

• Päivittäiset varmuuskopiot, säilytettynä 7–14 vuorokautta
• Viikoittaiset varmuuskopiot, säilytettynä 4–8 viikkoa
• Kuukausittaiset varmuuskopiot, säilytettynä 6–12 kuukautta

Tämä mahdollistaa palautuksen paitsi äkilliseen vikaan, myös hiipivään ongelmaan, joka huomataan vasta viikkojen kuluttua. Vanhentuneiden versioiden automaattinen siivoaminen kannattaa myös rakentaa mukaan, ettei tallennustila kasva rajattomasti.

Käytännön muistilista

Jos et tee tästä artikkelista mitään muuta, tee ainakin tämä:

1. Varmista, että sekä tiedostot että tietokanta varmuuskopioituvat samanaikaisesti.
2. Varmista, että vähintään yksi kopio sijaitsee fyysisesti eri palvelussa kuin tuotantosivusto.
3. Aseta säilytysaika riittävän pitkäksi, vähintään kuukaudeksi, mieluummin pidemmäksi.
4. Testaa palautus oikeasti, älä vain oleta sen toimivan.
5. Automatisoi koko prosessi, jotta se ei ole kiinni siitä, muistaako joku tehdä sen manuaalisesti.

Varmuuskopiointi ei ole kiinnostava aihe ennen kuin sitä tarvitsee, ja silloin se on jo liian myöhäistä hoitaa kuntoon. Tunnin työ toimivan automaation rakentamiseen säästää helposti viikkoja, jos jotain menee pieleen.

Jos haluat, että käyn läpi oman sivustosi varmuuskopiointitilanteen tai rakennan automaation puolestasi, ota yhteyttä osoitteeseen markus@markusmedia.fi.

– Markus Silvo