Trumpai: Patikima serverio atsarginių kopijų strategija laikosi 3-2-1 taisyklės: trys kopijos, du laikmenų tipai, viena kopija ne vietoje. Kad kopijos išgyventų ir ataką, bent viena kopija turi būti apsaugota nuo ištrynimo paties serverio. O tik sėkmingas atkūrimo testas parodo, kad kopija kritiniu atveju veiks.
Ką reiškia 3-2-1 taisyklė
3-2-1 taisyklė yra paprastas, daugelį metų pasiteisinęs duomenų kopijavimo principas:
- 3 kopijos: originalūs duomenys ir dvi atsarginės kopijos.
- 2 laikmenų tipai: pavyzdžiui, vietinis diskas ir objektų saugykla arba serverio saugykla ir juosta.
- 1 kopija ne vietoje: kitoje vietoje, pas kitą teikėją arba neprisijungusi (offline).
Žiniatinklio serveriams tai konkrečiai reiškia: kopija tame pačiame diske kaip ir svetainė nelaikoma savarankiška kopija. Jei serveris sugenda arba yra kompromituojamas, pražūsta abu. Vadovybei esminis klausimas todėl ne „Ar turime atsargines kopijas?“, o „Ar galime atkurti veiklą iš kopijos, kurios incidentas nepasiekė?“
Serverio atsarginių kopijų strategija, išgyvenanti ataką
Užpuolikai žino, kad atsarginės kopijos sugriauna jų darbą. Todėl kas turi prieigą prie serverio, dažnai ieško ir kopijų, kad jas ištrintų ar užšifruotų. Šiuolaikinė strategija 3-2-1 taisyklę todėl dažnai išplečia iki 3-2-1-1-0: papildomai viena kopija neprisijungusi arba nekeičiama, ir nulis klaidų atkūrimo teste.
Trys principai daro kopijas atsparias:
- Pull vietoj push: atskira atsarginio kopijavimo sistema pati paima duomenis iš žiniatinklio serverio. Pats žiniatinklio serveris neturi prisijungimo duomenų, kuriais galėtų kopijas ištrinti.
- Nekeičiamumas: objektų saugykla su saugojimo užraktu arba momentinės kopijos (snapshot), kurių tam tikrą laiką negalima ištrinti.
- Atskiros prieigos: atsarginio kopijavimo paskyra nėra ta pati kaip hostingo kliento paskyra ir turi savą antrą veiksnį.
Užšifruokite kopijas, esančias ne vietoje, ir raktą laikykite atskirai. Pamestas raktas padaro kopiją nenaudojama, kartu išsaugotas raktas šifravimą daro bevertį.
Ką reikia išsaugoti
Žiniatinklio serveriuose dažnai kopijuojama tik žiniatinklio šaknis (webroot). Pilnam atkūrimui tuomet trūksta svarbių dalių.
| Sritis | Pavyzdžiai | Pastaba |
|---|---|---|
| Programos failai | Webroot, įkėlimai, temos, plėtiniai | Įkėlimai keičiasi dažnai |
| Duomenų bazės | MySQL/MariaDB, PostgreSQL | saugoti nuosekliai, o ne tik kopijuoti failus |
| Konfigūracija | Žiniatinklio serveris, PHP-FPM baseinai, php.ini, cron užduotys | reikalinga greitam atstatymui |
| Sertifikatai ir raktai | TLS sertifikatai, programų raktai | laikyti užšifruotus ir atskirai |
| Dokumentacija | Prieigos, priklausomybės, atkūrimo eiga | be jos kiekvienas atstatymas trunka ilgiau |
Pavyzdys: duomenų bazės ir failų kopijavimas
Toliau pateiktas pavyzdys rodo kasdienės kopijos pagrindines dalis. Praktikoje perdavimą ne vietoje perima kopijavimo įrankis su šifravimu, dubliavimo šalinimu (deduplication) ir saugojimo taisyklėmis.
#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"
# Duomenų bazę kopijuoti nuosekliai; prisijungimo duomenys iš apsaugoto failo, ne komandoje
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
--single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"
# Programos failai ir konfigūracija
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d
# Kontrolinės sumos vėlesnei patikrai
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
Failas .backup-my.cnf turi duomenų bazės naudotojo, galinčio tik skaityti, prisijungimo duomenis ir teises 0600. --single-transaction InnoDB lentelėms užtikrina nuoseklią būseną nesustabdant parduotuvės.
Po to atskira sistema kopiją perduoda ne vietoje. Svarbu, kad šis žingsnis būtų stebimas: kopijavimo užduotis, kelias dienas tyliai nesėkminga, kitaip pastebima tik kritiniu atveju. Pakanka kasdienio pranešimo apie sėkmę, dydį ir trukmę, jei kas nors jį skaito ir sprendžia nukrypimus.
Jei papildomai naudojate hostingo teikėjo kopijas ar momentines kopijas (snapshot), raštu išsiaiškinkite, kiek laiko jos saugomos, ar patys galite atkurti ir ar kopijos išlieka, jei paskyra nutraukta ar užblokuota. Šios kopijos gerai papildo, bet nepakeičia savos, nepriklausomos kopijos.
Saugojimas: kodėl po PHP2Shell svarbios senesnės būsenos
Po atakos vertingiausia ne naujausia kopija, o naujausia švari. Pasak žiniasklaidos pranešimų, dėl PHP2Shell 2026-10-17 buvo pastebėtas pirmasis atakos bandymas, o pataisos pasirodė 2026-10-21. Kas saugo tik septynias dienas, galbūt nebeturi būsenos, kuri būtų saugiai prieš galimą įsilaužimą.
Pasiteisinusi schema derina kelis laikotarpius, pavyzdžiui, kasdienes kopijas kelioms savaitėms, savaitines kelioms mėnesiams ir mėnesines metams. Tikslūs laikotarpiai priklauso nuo jūsų apsaugos poreikio ir duomenų apsaugos ištrynimo pareigų.
Svarbu ir tai: kopija iš laikotarpio po įsilaužimo gali turėti webshell ar pakeistų failų. Po incidento niekada neatkurkite aklai, o palyginkite failus su švaria būsena ir patikrinkite, prieš svetainė vėl veiks internete. Į ką atkreipti dėmesį, rasite puslapyje Kompromitavimo požymiai. Pataisa nepašalina įterptos kenkėjiškos programinės įrangos, o kopija to savaime irgi nepadaro.
Atkūrimo testavimas ir dokumentavimas
Kopija be testo yra prielaida. Tik atkūrimas parodo, ar yra visos dalys, ar raktas veikia ir kiek laiko procesas iš tikrųjų trunka.
- Reguliariai testinėje aplinkoje atkurkite pilną kopiją, įskaitant duomenų bazę ir konfigūraciją.
- Patikrinkite, ar svetainė po to visiškai veikia: prisijungimas, užsakymai, formos, laiškai.
- Išmatuokite trukmę ir užfiksuokite, kurie žingsniai buvo rankiniai. Palyginkite rezultatą su laiku, kurį jūsų veikla daugiausia gali išsiversti be svetainės.
- Atkūrimo instrukciją laikykite ten, kur ji pasiekiama ir sugedus serveriui, pavyzdžiui, IT avariniame plane.
Kaip PHP SOS padeda konkrečiai?
- Tikriname jūsų esamas kopijas dėl išsamumo, saugojimo, atskyrimo nuo serverio ir apsaugos nuo ištrynimo.
- Įrengiame 3-2-1 kopijavimą su nekeičiama kopija ir kartu su jumis išbandome atkūrimą.
- Po incidento nustatome paskutinę švarią būseną ir atkuriame ją pataisytoje sistemoje per kenkėjiškų programų šalinimą.
- Per saugumo priežiūros sutartį nuolat stebime kopijas ir atliekame reguliarius atkūrimo testus.
Dažni klausimai
Ką reiškia 3-2-1 taisyklė atsarginėms kopijoms?
Trys jūsų duomenų kopijos, dviejų skirtingų tipų laikmenose, iš jų viena kitoje vietoje. Taisyklė užtikrina, kad nei techninės įrangos gedimas, nei ataka, nei gaisras vienu metu nepaliestų visų kopijų.
Ar pakanka mano hostingo teikėjo atsarginės kopijos?
Tai gerai papildo, bet retai pakanka. Išsiaiškinkite, kiek laiko teikėjas saugo būsenas, ar patys galite atkurti ir ar užpuolikas su jūsų kliento paskyra galėtų kopijas ištrinti. Rekomenduojama savo, nepriklausoma kopija.
Ar po įsilaužimo galiu tiesiog įdiegti paskutinę atsarginę kopiją?
Tik atsargiai. Paskutinė kopija jau gali turėti kenkėjiško kodo, o spraga, per kurią užpuolikas pateko, po to dar atvira. Pirmiausia išsiaiškinkite priežastį ir ją uždarykite, tada patikrintą būseną atkurkite į pataisytą sistemą.
Kaip dažnai turėčiau išbandyti atkūrimą?
Reguliariai ir po didesnių sistemos pakeitimų. Pasiteisino fiksuotas ritmas, pavyzdžiui, pilnas atkūrimas kartą per ketvirtį testinėje aplinkoje. Svarbu, kad testas būtų dokumentuotas, o spragos pašalintos.