Moduuli 8 · 8.1
Varmuuskopiointisuunnitelma palvelimellesi
Moduuli 8: Varmuuskopiot ja valvonta · Lukuaika: 11 minuuttia
Tavoite: Tämän oppitunnin jälkeen osaat tehdä omalle palvelimellesi varmuuskopiointisuunnitelman: mitä säilytät, missä, kuinka usein ja kuinka kauan, ja miten varmistat, että palauttaminen toimii.
Keskeiset käsitteet: 3-2-1-sääntö, tilannevedos (snapshot), palveluntarjoajan varmuuskopio, oma varmuuskopio palveluntarjoajan ulkopuolella, RPO, RTO, tietokantavedos (mariadb-dump, pg_dump), asetukset hakemistossa /etc, Docker-volyymit, salaus, kiristyshaittaohjelma, append-only, palautustesti
Miksi suunnitelma eikä vain "onhan meillä varmuuskopio"?
Lähes jokainen palvelimensa menettänyt uskoi, että varmuuskopio on olemassa. Sitten selviää, että siinä on vain käyttöjärjestelmä eikä tietokantaa, tai se on samalla palvelimella, joka on nyt poissa, tai sama kiristyshaittaohjelma on salannut senkin, tai kukaan ei tiedä salasanaa. Varmuuskopiosta on hyötyä vasta, kun sen voi palauttaa. Siksi aloitat suunnitelmalla ja lopetat testiin.
Suunnitelma vastaa viiteen kysymykseen:
- Mitä pitää pystyä palauttamaan?
- Kuinka paljon tietoja saa menettää? (RPO)
- Kuinka nopeasti kaiken pitää taas toimia? (RTO)
- Missä kopiot ovat, ja kuinka monta niitä on?
- Miten tiedät, että se toimii?
Mitä pitää pystyä palauttamaan?
Palvelin koostuu kerroksista. Jokaista kerrosta ei tarvitse varmuuskopioida:
| Kerros | Esimerkki | Varmuuskopio? |
|---|---|---|
| Käyttöjärjestelmä ja paketit | Debian, nginx, PHP | Ei välttämättä: ne voi asentaa uudelleen. Luettelo kannattaa kuitenkin ottaa: dpkg --get-selections |
| Asetukset | /etc (nginx, SSH, palomuuri, systemd-yksiköt), compose-tiedostosi | Kyllä, pieniä ja korvaamattomia |
| Sovellukset ja sivustot | /var/www, /opt/<app>, /srv | Kyllä, ellei niitä saa Gitistä |
| Tiedot | tietokannat, ladatut tiedostot, Docker-volyymit (/var/lib/docker/volumes) | Kyllä, tärkein kaikista |
| Salaisuudet | salasanat, API-avaimet, itse varmuuskopiosi avain | Kyllä, mutta erikseen ja salattuna (katso alla) |
| Lokit, välimuistit, väliaikaiset tiedostot | /var/log, /var/cache, /tmp | Yleensä ei |
Kiinnitä erityistä huomiota tietokantoihin. Käynnissä oleva tietokanta kirjoittaa jatkuvasti. Jos kopioit käynnissä olevan MariaDB:n tai PostgreSQL:n tiedostot, kopio voi olla vioittunut. Tee siksi ensin vedos (dump): yhtenäinen hetkikuva tiedostona, jonka otat sen jälkeen mukaan varmuuskopioon.
root@web1:~# mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles-$(date +%F).sql.gz
root@web1:~# sudo -u postgres pg_dumpall | gzip > /var/backups/db/pg-$(date +%F).sql.gz(mariadb-dump oli aiemmin nimeltään mysqldump; sekin komento toimii yleensä vielä.) Jos tietokanta on kontissa, teet saman komennolla docker compose exec (oppitunti 9.4).
RPO ja RTO: kuinka paljon saa menettää?
Kaksi alan käsitettä auttaa tekemään valintoja:
- RPO (recovery point objective): kuinka pitkän ajan tiedot saat enintään menettää? Päivittäinen varmuuskopio kello 03:00 tarkoittaa, että jos palvelin kaatuu kello 22:00, menetät lähes päivän verran tietoja. Tilauksia vastaanottavalle verkkokaupalle se on liikaa; kerran viikossa muuttuvalle blogille se sopii hyvin.
- RTO (recovery time objective): kuinka kauan saa kestää, ennen kuin kaikki taas toimii? Palveluntarjoajan täyden varmuuskopion palauttaminen voi onnistua minuuteissa; uuden palvelimen rakentaminen ja kaiken palauttaminen käsin voi viedä tunteja.
Kirjaa ne ylös omalle palvelimellesi. Ne ratkaisevat, kuinka usein varmuuskopioit ja miten säilytät kopiot.
Tilannevedos, palveluntarjoajan varmuuskopio, oma varmuuskopio
VPS:ssä on yleensä kolmenlaisia turvaverkkoja. Ne muistuttavat toisiaan, mutta suojaavat eri asioilta.
1. Tilannevedos (snapshot). Hetkikuva koko virtuaalilevystä, tehty palveluntarjoajan hallintapaneelissa. Nopea tehdä, nopea palauttaa. Ihanteellinen juuri ennen päivitystä (oppitunti 4.3). Mutta: useimmilla palveluntarjoajilla tilannevedos on samalla tallennustilalla kuin palvelimesi. Jos tallennustila hajoaa tai menetät tilisi, tilannevedos katoaa myös. Tilannevedosta ei myöskään säilytetä pitkään: se kasvaa kaikkien myöhempien muutosten mukana. Tilannevedos ei ole varmuuskopio.
2. Palveluntarjoajan varmuuskopio. Moni palveluntarjoaja tekee (mahdollisesti lisäpalveluna) automaattisesti joka päivä kopion koko palvelimestasi toiselle tallennustilalle. WebOkéllä tämä on esimerkiksi päivittäinen varmuuskopio koko VPS:stä, ja sitä säilytetään seitsemän päivää; muilla palveluntarjoajilla käytäntö on samankaltainen omin säilytysajoin. Se on hyvä toinen kerros rikkoutuneen laitteiston ja omien eilisten virheidesi varalta. Mutta kyse on edelleen yhdestä toimijasta: tilisi, maksusi, heidän häiriönsä. Lisäksi palautus tehdään yleensä koko palvelimelle kerralla.
3. Oma varmuuskopiosi palveluntarjoajan ulkopuolella. Kopio tiedoistasi toisella toimijalla tai toisessa paikassa, jonka teet ja jota hallinnoit itse (oppitunti 8.2). Tämä kerros jää jäljelle, kun kaikki muu menee pieleen.
3-2-1-sääntö
Yleinen nyrkkisääntö:
- 3 kopiota tiedoistasi (alkuperäinen ja kaksi varmuuskopiota);
- 2 erilaisella tallennustilalla tai järjestelmässä;
- joista 1 toisessa sijainnissa.
VPS:llä se voi tarkoittaa: tiedot palvelimella, palveluntarjoajan päivittäinen varmuuskopio ja salattu oma varmuuskopio resticillä toisen toimijan tallennustilaan. Nykyaikainen lisäys on, että vähintään yhtä kopiota ei voi poistaa se, joka kaappaa palvelimen (offline tai append-only, oppitunti 8.2). Palvelimelle päässyt kiristyshaittaohjelma etsii aktiivisesti varmuuskopioita salatakseen tai poistaakseen nekin. Varmuuskopio, jonka palvelin itse saa poistaa, ei suojaa tältä.
Salaus ja varmuuskopion salasana
Toisella toimijalla olevan varmuuskopion pitää olla salattu: siinä on asiakastietoja, salasanoja ja avaimia. restic (oppitunti 8.2) salaa oletuksena. Samalla syntyy kuitenkin uusi riski: varmuuskopion salasana. Jos se katoaa, varmuuskopio on käyttökelvoton. Samoin käy, jos salasana on vain sillä palvelimella, jonka menetit.
Säilytä salasana siksi myös palvelimen ulkopuolella: salasanojen hallintaohjelmassa ja mahdollisesti paperilla kassakaapissa. Sama koskee sen tallennustilan tunnuksia, jossa varmuuskopiosi on.
Palautuksen testaaminen
Suunnitelman tärkein osa. Palautustesti tarkoittaa, että palautat varmuuskopion oikeasti paikkaan, jossa se ei riko mitään, ja tarkistat, että lopputulos toimii.
- Pieni ja usein: palauta yksi tiedosto tai kansio hakemistoon
/tmp/terugja vertaa (diff). Esimerkiksi kuukausittain. - Iso ja silloin tällöin: rakenna varmuuskopiosta kokonaan uusi testipalvelin, tuo tietokanta ja käynnistä sivusto. Esimerkiksi kerran vuodessa tai jokaisen suuren muutoksen yhteydessä. Tämä on samalla harjoitus sitä varten, että jotain todella menee pieleen (oppitunti 10.3).
Kirjaa ylös, kuinka kauan se kesti: se on todellinen RTO:si.
Säilytysajat
Älä säilytä vain viimeisintä varmuuskopiota. Jos huomaat vasta kahden viikon päästä, että tiedosto on vioittunut tai poistettu, tarvitset kolmen viikon takaisen varmuuskopion. Yleinen malli: seitsemän päivittäistä, neljä viikoittaista ja kuusi kuukausittaista versiota. restic hoitaa tämän komennolla forget (oppitunti 8.2). Muista myös tietosuoja-asetus (GDPR): henkilötietoja ei säilytetä pidempään kuin on tarpeen, ei myöskään varmuuskopioissa. Kirjaa säilytysaikasi ylös.
Käytännössä
Käytä palveluntarjoajan tilannevedosta juuri ennen riskialttiita muutoksia ja poista se sen jälkeen; pidä palveluntarjoajan päivittäinen varmuuskopio päällä, jos sellainen on; ja tee lisäksi oma salattu varmuuskopio tiedoista ja asetuksista toiselle toimijalle. WebOkéllä nämä löytyvät VPS-näkymästä nimillä Snapshots ja Backups; muilla palveluntarjoajilla nimet ja säilytysajat ovat erilaiset, mutta periaate on sama. Webhotellipaketissa tai hallinnoidussa palvelussa sovitaan usein toisin: tarkista, mitä sinun tapauksessasi on järjestetty.
Yhteenveto
- Varmuuskopiosta on hyötyä vasta, kun palautus toimii; aloita suunnitelmalla ja lopeta testiin.
- Varmuuskopioi ennen kaikkea tiedot ja asetukset: tietokannat vedoksina,
/etc, sivustot, Docker-volyymit, compose-tiedostot. - Määritä RPO (kuinka paljon saa menettää) ja RTO (kuinka nopeasti kaiken pitää toimia).
- Tilannevedos (sama tallennustila, lyhyt säilytys), palveluntarjoajan varmuuskopio (eri tallennustila, sama toimija) ja oma varmuuskopio palveluntarjoajan ulkopuolella ovat kolme eri kerrosta; noudata 3-2-1-sääntöä niin, että vähintään yhtä kopiota palvelin ei itse voi poistaa.
- Salaa, säilytä varmuuskopion salasana palvelimen ulkopuolella ja testaa palautusta pienesti ja usein, isosti silloin tällöin.
Tietovisa (quiz)
Tehtävä
Tehtävä O8.1: Varmuuskopiointisuunnitelmasi. Tee omalle palvelimellesi yhden sivun varmuuskopiointisuunnitelma: mitä pitää pystyä palauttamaan (kerroksittain), RPO ja RTO, mitä kopioita sinulla on (tilannevedos, palveluntarjoaja, oma) ja missä, säilytysaikasi, missä varmuuskopion salasana on ja milloin teet palautustestin. Täytä lomake; lähettämisen jälkeen näet esimerkkisuunnitelman, johon voit verrata omaasi.
Tehtävä O8.1: Varmuuskopiointisuunnitelmasi
Tämän tehtävän teet itse, kukaan ei tarkista sitä. Merkitse tekemäsi kohdat ja merkitse tehtävä tehdyksi.
Tietokannat dumpilla, ei käynnissä olevan tietokannan erillisinä tiedostoina. Päivittäin salattuna (restic) toiselle palveluntarjoajalle; snapshot vain muutosten yhteydessä. 7 päivittäistä, 4 viikoittaista ja 6 kuukausittaista versiota on hyvä alku. Kuukausittain pieni palautus, vuosittain täydellinen uudelleenrakennus. Älä koskaan kirjoita tähän oikeaa salasanaa.
Merkintäsi ja muistiinpanosi pysyvät vain tässä selaimessa, emme lähetä niitä minnekään. Jos olet kirjautunut sisään, tallennamme kohtaan Omat kurssit vain sen, että olet tehnyt tehtävän.
Lue lisää
- VPS-palvelimen snapshotit ja varmuuskopiot
- Varmuuskopiointistrategia: 3-2-1-sääntö omalle yrityksellesi
- Turvallisesti verkossa -kurssilla: oppitunnit 3-2-1-säännöstä ja varmuuskopioista, jotka selviävät kiristyshaittaohjelmasta.
- MariaDB, mariadb-dump: https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump
- PostgreSQL, Backup and Restore (SQL Dump): https://www.postgresql.org/docs/current/backup-dump.html
