Oma serveri varundamine: mis tegelikult katki läheb

Lühidalt

• 3-2-1 reegel: andmetest kolm koopiat kahel andmekandjal, millest üks on võrguühenduseta ja vähemalt üks teises asukohas.
• Andmebaasi varundatakse selle enda tööriistadega, mitte kunagi selle kausta kopeerimisega töö ajal.
• Varukoopia on olemas alles siis, kui see on taastatud, ja taastamist hinnatakse sisu, mitte tagastuskoodi järgi.
• Tootmisserveris ei tehta üldist puhastust: kirjalik teenuste ja nende andmeköidete inventuur ning sihitud käsud.

Miks töötavast varundusest ei piisa

Isemajutatud serveri varundamine mahub ühte tuntud reeglisse: kolm koopiat, kaks andmekandjat, üks koopia eemal. Päriselt kaitseb see, kui lisada sellele tõeliselt läbiproovitud taastamised. Kõik muu on teostuse detail, kuid just selles detailis lähevad andmed kaduma.

Meie server käitab Dockeri konteinerites umbes tosinat teenust Traefiku ruuteri taga: CRM Twenty, automatiseerimine n8n, statistika Matomo, e-allkiri, arveldus ja tehisintellekti mudelid. Järgnev pärineb sellest käitamisest, sealhulgas meie vigadest, ja need on meie SaaS-ist lahkumise teenuse reeglid, mis tarnitakse automaatsete serverivälise varukoopiate ja testitud taastamisega.

3-2-1 reegel ja mida see ei ütle

Prantsuse andmekaitseasutus CNIL esitab seda oma andmete varundamise juhendis tehnika tasemena: andmetest kolm koopiat kahel erineval andmekandjal, millest üks on võrguühenduseta. Sama juhend soovitab hoida vähemalt ühte geograafiliselt eraldi asukohas ja hoiatab varukoopiate eest, mida hoitakse andmetega samades süsteemides ilma isoleerimata: lunavara võiks siis jõuda nii ühtede kui teisteni.

Renditud serveri puhul tähendab see konkreetselt kolme koopiat:

See viimane punkt on oluline: kui ründaja või skriptiviga saab serveris õigused, ei tohi ta saada samade võtmetega kaugkoopiat kustutada.

Reegel ei ütle, kuidas kopeerida kasutusel olevat andmebaasi ega kuidas teada, et koopiast on kasu. Just seal läheb katki.

Mis tegelikult katki läheb

1. Andmebaas, mis on kopeeritud nagu tavaline kaust

PostgreSQL-i andmebaasi andmekataloogi kopeerimine töö ajal ei anna usaldusväärset varukoopiat. PostgreSQL-i dokumentatsioon failisüsteemi tasandi varundamisest ütleb seda otse: kasutatava koopia saamiseks tuleb andmebaasiserver peatada, välja arvatud juhul, kui kasutatakse andmeköite kooskõlalist hetktõmmist. Andmebaasi varundatakse seega selle enda tööriistadega: loogiline eksport (pg_dump) väikeste andmebaaside jaoks või baasvarukoopia, mida täiendab tehingulogi (WAL) pidev arhiveerimine, suuremate jaoks.

See teine mehhanism võimaldab naasta täpsesse ajahetke. PostgreSQL-i dokumentatsioon pidevast arhiveerimisest selgitab seda: logi soovitud hetkeni uuesti läbi mängides saab andmebaasi tagasi sellisena, nagu see oli mis tahes ajahetkel pärast baasvarukoopiat. Sellest tuleneb juhis:

Sõna „test“ on ametlikus dokumentatsioonis: see ei ole agentuuri ettevaatusabinõu.

2. Unustatud andmeköide

Dockeriga elavad kasulikud andmed andmeköidetes või ühendatud kaustades. Kiirelt lisatud teenus andmeköitega, mida keegi varundusskripti ei lisanud, ja rikke päeval avastatakse, et seda pole kunagi kopeeritud. Lahendus on lihtne ja tõhus: kirjalik nimekiri teenustest, nende andmeköidetest ja varundusmeetodist, mis loetakse üle iga uue teenuse lisamisel.

3. Üldine puhastuskäsk

See on meie viga ja me räägime sellest, sest see on õpetlik.

docker system prune dokumentatsioon on samas selge: vaikimisi kustutab see kõik peatatud konteinerid, võrgud, mida ükski konteiner ei kasuta, orvuks jäänud tõmmised (ilma sildita) ja kasutamata ehitusvahemälu; valikuga --all kõik kasutamata tõmmised. Serveris, kus mõni teenus on ajutiselt peatatud, võib „kasutamata“ tähendada „tootmises, kuid mitte sel hetkel“.

Andmeköiteid vaikimisi ei kustutata, et mitte kustutada olulisi andmeid, mida ükski konteiner sel hetkel ei kasuta: see päästis meie andmed. Valikuga --volumes ei kehti see enam anonüümsete andmeköidete kohta.

Meie nõuanne: tootmisserveris ei tehta üldist puhastust, selle asemel sihitud puhastus ja ajakohane teenuste inventuur. Intsident, mis ei jäta maha kirjalikku reeglit, kordub.

4. Kunagi taastamata varukoopia

Kõige vaiksem juhtum. Skript töötab igal ööl, ei teata ühestki veast, ja keegi pole kunagi kontrollinud, kas arhiivi saab lahti pakkida, kas andmebaas laaditakse uuesti, kas rakendus käivitub selle peal. Varukoopia on olemas alles alates päevast, mil see edukalt taastati.

Ja edu hinnatakse sisu, mitte tagastuskoodi järgi. Ühes meie hallatavas projektis tagastas taastamistööriist vea pelgalt hoiatuste puhul: seepärast valideerime taastamise leitud tabelite ja kirjete arvu järgi.

5. Hoiatus, mis välja ei lähe

Varundusskript, mis ebaõnnestub ilma teavitamata, on halvem kui skripti puudumine, sest see annab vale turvatunde. Iga varundus peab ebaõnnestumise korral saatma signaali ja ideaalis ka signaali, kui see üldse ei käivitunud.

Protseduur, mida soovitame

VKE-le, mis käitab mõnda teenust oma serveris:

• Igal ööl: iga andmebaasi eksport selle tööriistaga, loetletud andmeköidete koopia, krüpteeritud saatmine kaugsalvestusse oma juurdepääsuandmetega.
• Igal nädalal: automaatne kontroll, et öised failid on olemas, usutava suurusega ja lahti pakitavad.
• Igas kvartalis: ühe teenuse täielik taastamine ühekordses konteineris või testmasinas, ajaga mõõdetud ja sisu järgi valideeritud. Mõõdetud ajast saab Teie tegelik taasteaeg, mille saate juhtkonnale teatada.
• Iga uue teenusega: inventuuri ja skripti uuendamine enne tootmisse viimist, mitte pärast.
• Säilitamine: igapäevased koopiad mõneks nädalaks, igakuised koopiad kauemaks. Kestus sõltub Teie kohustustest ja isikuandmetest: andmete hoidmine vajalikust kauem ei ole turvalisus, vaid võlg.

Ausad piirangud

See protseduur kaitseb andmete kaotuse eest. See ei taga kättesaadavust: teenuse taastamine võtab aega ja selle aja jooksul see seisab. Kui Teie tegevus ei talu mõnetunnist katkestust, on vaja dubleerimist (teist serverit, mis on valmis üle võtma), mis muudab kulu. See on rida, mis tuleb arvestada SaaS-ist lahkumise tegeliku kolme aasta kulu arvutusse.

Kust alustada

Kirjutage inventuur: iga teenus, selle andmebaas, andmeköited ja varundusmeetod. Seejärel taastage üks terve teenus, kasvõi väike, ja pange kirja, kui kaua see võtab. Varukoopiad on vaid üks ehituskivi Teie projektide ühises infrastruktuuri aluses, ligipääsude, seire ja eelarvete kõrval. Kui Teil pole veel serverit, alustage vähekriitilisest tööriistast, nagu soovitab meie juhend esimesena isemajutatavatest tööriistadest. Delegeerimiseks katab meie SaaS-ist lahkumise haldusteenus seire, uuendused ja testitud varukoopiad. Ülejäänud käitamise teemad on meie infrastruktuuri ja pilve rubriigis.

Korduma kippuvad küsimused

Allikad

1. Andmete varundamise juhendis (uus vahekaart)cnil.fr
2. PostgreSQL-i dokumentatsioon failisüsteemi tasandi varundamisest (uus vahekaart)postgresql.org
3. PostgreSQL-i dokumentatsioon pidevast arhiveerimisest (uus vahekaart)postgresql.org
4. Docker system prune dokumentatsioon (uus vahekaart)docs.docker.com