Varmuuskopio, jota et ole koskaan palauttanut, ei ole varmuuskopio

Huonoin hetki huomata, ettei varmuuskopio toimi, on se hetki, kun tarvitset sitä. Silti kaikkein yleisin toimintamalli on juuri tämä: varmuuskopiot määritetään kerran, hallintapaneelissa näkyy vihreä merkki kahdeksantoista kuukauden ajan, ja sitten palautus tuottaa tyhjän tietokannan.

Tietokantavarmuuskopion palautuksen testaaminen ei ole samanlainen best practice kuin useimmat valinnaiset käytännöt. Varmuuskopio on väite, ja ennen kuin olet palauttanut sellaisen, väitettä ei ole testattu.

Näin ne epäonnistuvat ja mitä tarkistuksessa on oikeasti varmistettava.

Neljä tapaa, joilla varmuuskopio on hiljaisesti hyödytön

1. Se on tyhjä, eikä kukaan tarkistanut sitä

Osittain epäonnistuva pg_dump voi silti tuottaa tiedoston. Väärää tietokannan nimeä käyttävä dump tuottaa kelvollisen, oikean mutta tyhjän tiedoston. Molemmat näyttävät onnistuneilta kaikelle, mikä tarkistaa vain nollasta poikkeavan paluuarvon tai tiedoston olemassaolon.

Maailman halvin tarkistus: katso koko ja vertaa sitä eiliseen. Jos varmuuskopio on 400 tavua ja eilinen oli 40 Mt, varmuuskopio on kertonut sinulle kaiken olennaisen. Jos se on ollut 400 tavua kuuden kuukauden ajan, se on yrittänyt kertoa sen koko ajan.

2. Se sisältää datan, mutta ei sen ympärillä olevia asioita

Yksittäisen tietokannan pg_dump ei sisällä rooleja eikä muita tietokantoja. Kun palautat sen uudelle palvelimelle, taulut saapuvat, mutta jokainen GRANT viittaa rooliin, jota ei ole olemassa. Sovelluksesi yhdistää tietokantaan ja saa kaikkeen vastaukseksi permission denied.

Laajennusten kanssa tilanne on sama. Jos skeemasi tarvitsee pgcrypto- tai uuid-ossp-laajennuksen eikä kohteessa ole niitä, palautus epäonnistuu kesken kaiken ja jättää jälkeensä joitakin tauluja.

3. Liput olivat väärät tarvitsemaasi palautusta varten

pg_dump tuottaa eri asioita formaatista riippuen, ja virhe huomataan yleensä vasta paineen alla:

• Plain SQL palautetaan psql:llä, ja se on ihmisen luettavaa. Sitä ei voi palauttaa valikoivasti, ja suurten tietokantojen kanssa se on hidasta.
• Custom format (-Fc) palautetaan pg_restore:lla, se tukee rinnakkaisuutta ja valikoivaa palautusta, ja sitä kannattaa käyttää kaikkeen vähänkään suurempaan.

Varmuuskopion tekeminen plain-muodossa, koska opas teki niin, ja sen huomaaminen häiriötilanteen aikana, ettei yksittäistä taulua voi palauttaa, on erityinen ja vältettävissä oleva huonon päivän muoto.

4. Et pysty purkamaan sen salausta

Jos varmuuskopiot on salattu — kuten niiden pitäisi olla — avain on osa varmuuskopiota. Avain, joka on vain menetetyllä koneella tai vain alhaalla olevan palvelun ympäristömuuttujassa, on avain, jota sinulla ei ole silloin, kun sillä on merkitystä.

Miltä oikea tarkistus näyttää

Testi ei ole ”onko tiedosto olemassa”. Palauta se jonnekin muualle ja esitä sille kysymys.

# 1. Restore into a scratch database, not the live one
createdb verify_$(date +%Y%m%d)
pg_restore -d verify_$(date +%Y%m%d) --no-owner --no-privileges latest.dump

# 2. Ask it something only real data can answer
psql -d verify_$(date +%Y%m%d) -c "
  select
    (select count(*) from users)            as users,
    (select count(*) from orders)           as orders,
    (select max(created_at) from orders)    as newest_order;
"

# 3. Drop it
dropdb verify_$(date +%Y%m%d)

Kohta 2 on koko asian ydin. Ilman virheitä valmistuva palautus ei vieläkään kerro, ovatko tiedot siellä. Rivimäärät ja tuoreustarkistus kertovat.

Kolme asiaa, jotka kannattaa varmistaa:

• Rivimäärät ovat oikeassa suuruusluokassa. Niiden ei tarvitse olla täsmälleen samoja — data muuttuu — mutta taulu, jossa oli 200 000 riviä ja jossa on nyt 12, tarkoittaa epäonnistunutta palautusta.
• Uusin tietue on tuore. Jos ”öisimmän” varmuuskopiosi uusin tilaus on maaliskuulta, varmuuskopiointityösi pysähtyi maaliskuussa.
• Sovellus pystyy oikeasti yhdistämään tietokantaan. Ohjaa staging-instanssi palautettuun tietokantaan ja lataa yksi sivu.

Tee se aikataulun mukaan, älä vasta häiriötilanteessa

Realistinen tahti on kuukausittain ja automaattisesti, niin että tulos päätyy paikkaan, jonka huomaat. Kalenterimuistutus ”testaa varmuuskopiot” on muistutus, jonka siirrät myöhemmäksi.

Testaus pysyy toiminnassa, kun teet epäonnistumisesta näkyvän: jos tarkistuskysely palauttaa kynnysarvoa vähemmän rivejä, sen pitäisi lähettää hälytys samalla tavalla kuin tuotantovirhe. Hiljaisesti epäonnistuva varmuuskopiointijärjestelmä ei eroa lainkaan siitä, ettei varmuuskopiointijärjestelmää olisi — ennen kuin sillä on merkitystä.

Näin Dockup käsittelee asian

Kolme päätöstä, joista jokainen kohdistuu yhteen edellä kuvatuista ongelmista.

Varmuuskopiot tallennetaan muualle. Samalla levyllä tietokannan kanssa oleva varmuuskopio ei ole varmuuskopio — se on kopio, joka katoaa levyn mukana. Dockup streamaa tietokantavarmuuskopiot suoraan object storageen niiden valmistuessa, joten tiedosto ei ole koskaan riippuvainen sen tuottaneesta hostista.

Ne salataan, eikä avain ole koneella. Varmuuskopiot salataan AES-256-GCM:llä streamauksen aikana. Palautuksen kannalta olennaista on se, että alusta säilyttää avaimen sen sijaan, että se olisi varmuuskopioitavan palvelun ympäristössä.

Varmuuskopiota, joka ei tuottanut mitään, ei kirjata varmuuskopioksi. Tämä ratkaisee tyhjän tiedoston ongelman suoraan: jos dump päättyy nollasta poikkeavaan paluuarvoon tai tuottaa nolla tavua, upload poistetaan ja varmuuskopio kirjataan epäonnistuneeksi. Et päädy vihreiden merkintöjen listaan, jonka joukossa yksi on 400 tavun tiedosto.

dockup db backup my-project/main-db --json     # take one now
dockup db backups my-project/main-db --json    # list them with sizes

Listauksessa näkyvät koot ovat halvin käytettävissäsi oleva health check. Seuraa niiden kehitystä.

Epämukava kysymys

Jos tuotantotietokantasi tuhoutuisi seuraavan kymmenen minuutin aikana, kuinka kauan kestäisi saada se takaisin käyttöön ja kuinka paljon menettäisit?

Jos et pysty vastaamaan kumpaankin lukuun, sinulla ei ole varmuuskopiointistrategiaa — sinulla on varmuuskopiotiedostoja. Ero riippuu täysin siitä, onko joku koskaan tehnyt palautusta.

Usein kysytyt kysymykset

Kuinka usein palautus pitäisi testata? Kuukausittain on järkevä oletus, ja testaus kannattaa automatisoida manuaalisen työn sijaan. Tärkeintä on, että epäonnistumisesta tulee näkyvä, ei se, että tahti on erityisen tiheä.

Miksi palautus valmistui, mutta dataa ei syntynyt? Yleensä dump otettiin väärästä tietokannasta tai se epäonnistui kesken kirjoittamisen, mutta tiedosto jäi silti jäljelle. Vertaa varmuuskopioiden kokoja ajan mittaan — tyhjä dump näkyy selvästi kokojen kehityksessä mutta ei status-sarakkeessa.

Pitäisikö varmuuskopiot salata? Kyllä, ja avaimen on oltava paikassa, joka säilyy koneen menettämisestä huolimatta. Salattu varmuuskopio, jonka avain oli menetetyllä palvelimella, ei ole palautettavissa.

Onko snapshot sama asia kuin varmuuskopio? Ei. Volume snapshot tallentaa levyn, mukaan lukien tietokannan tilan kyseisellä hetkellä. Looginen dump on rakenteensa ansiosta eheä. Useimmat tiimit tarvitsevat molemmat eri vikatilanteita varten.