# Serveru dublēšanas stratēģija: dublējumi pēc 3-2-1 noteikuma

> Serveru dublēšanas stratēģija pēc 3-2-1 noteikuma: ko saglabāt, kā dublējumi pārdzīvo uzbrukumu un kāpēc obligāti jāpārbauda to atjaunošana.

Avots: https://phpsos.de/lv/ratgeber/backups-3-2-1/  
Aktuāls uz: 25.10.2026  
Pakalpojuma sniedzējs: PHP SOS, PHP ārkārtas palīdzība un serveru drošība. Tūlītēja palīdzība pa WhatsApp: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20nepiecie%C5%A1ama%20pal%C4%ABdz%C4%ABba%20ar%20m%C5%ABsu%20PHP%20serveri.%20Uz%C5%86%C4%93mums%3A%20%E2%80%A6%20Vietne%3A%20%E2%80%A6

**Īsi:** Uzticama serveru dublēšanas stratēģija seko 3-2-1 noteikumam: trīs kopijas, divi glabāšanas veidi, viena kopija ārpus uzņēmuma. Lai dublējumi pārdzīvotu arī uzbrukumu, vismaz vienai kopijai jābūt aizsargātai pret paša servera veiktu dzēšanu. Un tikai sekmīgs atjaunošanas tests parāda, ka dublējums ārkārtas situācijā darbosies.

## Ko nozīmē 3-2-1 noteikums

3-2-1 noteikums ir vienkāršs, gadiem pārbaudīts datu dublēšanas pamatprincips:

- **3 kopijas:** oriģinālie dati un divi dublējumi.
- **2 glabāšanas veidi:** piemēram, lokālais disks un objektu glabātuve, vai servera krātuve un lente.
- **1 kopija ārpus uzņēmuma:** citā atrašanās vietā, pie cita sniedzēja vai bezsaistē.

Tīmekļa serveriem tas konkrēti nozīmē: dublējums tajā pašā cietajā diskā, kur vietne, neskaitās par patstāvīgu kopiju. Ja serveris izkrīt vai tiek kompromitēts, abi ir zaudēti. Vadībai galvenais jautājums tāpēc nav „Vai mums ir dublējumi?“, bet „Vai mēs varam atjaunot darbību no kopijas, ko incidents nav skāris?“

## Serveru dublēšanas stratēģija, kas pārdzīvo uzbrukumu

Uzbrucēji zina, ka dublējumi izjauc viņu darbu. Kas iegūst piekļuvi serverim, tāpēc bieži meklē arī dublējumus, lai tos dzēstu vai šifrētu. Moderna stratēģija tāpēc 3-2-1 noteikumu bieži paplašina līdz **3-2-1-1-0**: papildu kopija bezsaistē vai nemaināma, un nulle kļūdu atjaunošanas testā.

Trīs pamatprincipi dublējumus dara noturīgus:

- **Pull, nevis Push:** Atsevišķa dublēšanas sistēma paņem datus no tīmekļa servera. Pašam tīmekļa serverim nav piekļuves datu, ar kuriem tas varētu dublējumus dzēst.
- **Nemaināmība:** Objektu glabātuve ar glabāšanas bloķējumu vai momentuzņēmumi, ko noteiktu laiku nevar izdzēst.
- **Atsevišķas piekļuves:** Dublēšanas konts nav tas pats, kas hostinga klienta konts, un tam ir savs otrais faktors.

> **Svarīgi:**
> Šifrējiet dublējumus, kas atrodas ārpus uzņēmuma, un atslēgu glabājiet atsevišķi. Pazaudēta atslēga dublējumu padara nelietojamu, līdzi saglabāta atslēga šifrēšanu padara bezvērtīgu.

## Kas jāsaglabā

Tīmekļa serveros bieži dublē tikai webroot. Pilnīgai atjaunošanai tad trūkst svarīgu daļu.

| Joma | Piemēri | Norāde |
|---|---|---|
| Lietojumprogrammas faili | webroot, augšupielādes, motīvi, paplašinājumi | augšupielādes mainās bieži |
| Datubāzes | MySQL/MariaDB, PostgreSQL | dublēt konsekventi, nevis tikai kopēt failus |
| Konfigurācija | tīmekļa serveris, PHP-FPM pūli, php.ini, cron uzdevumi | vajadzīga ātrai atkārtotai uzbūvei |
| Sertifikāti un atslēgas | TLS sertifikāti, lietojumprogrammas atslēgas | glabāt šifrētas un atsevišķi |
| Dokumentācija | piekļuves, atkarības, atjaunošanas norise | bez tās katra atkārtota uzbūve ilgst ilgāk |

## Piemērs: datubāzes un failu dublēšana

Turpmākais piemērs rāda ikdienas dublēšanas pamatelementus. Praksē pārsūtīšanu ārpus uzņēmuma pārņem dublēšanas rīks ar šifrēšanu, deduplikāciju un glabāšanas noteikumiem.

```bash
#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"

# Datubāzi dublēt konsekventi; piekļuves dati no aizsargāta faila, nevis komandā
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
  --single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"

# Lietojumprogrammas faili un konfigurācija
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d

# Kontrolsummas vēlākai pārbaudei
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
```

Fails `.backup-my.cnf` satur datubāzes lietotāja piekļuves datus, kuram atļauts tikai lasīt, un tā tiesības ir `0600`. `--single-transaction` InnoDB tabulām nodrošina konsekventu stāvokli, nepārtraucot veikalu.

Pēc tam atsevišķa sistēma dublējumu pārsūta ārpus uzņēmuma. Svarīgi, lai šis solis tiktu uzraudzīts: dublēšanas uzdevums, kas vairākas dienas klusi neizdodas, citādi tiek pamanīts tikai ārkārtas situācijā. Pietiek ar ikdienas ziņojumu par sekmību, lielumu un ilgumu, ja vien kāds to lasa un novirzēm seko.

Ja papildus izmantojat sava hostinga sniedzēja dublējumus vai momentuzņēmumus, rakstiski noskaidrojiet, cik ilgi tie tiek glabāti, vai varat atjaunot paši un vai dublējumi saglabājas, ja konts tiek uzteikts vai bloķēts. Šīs kopijas ir laba papildinājums, bet neaizstāj savu, neatkarīgu dublējumu.

## Glabāšana: kāpēc vecāki stāvokļi pēc PHP2Shell ir svarīgi

Pēc uzbrukuma vērtīgākais nav jaunākais dublējums, bet jaunākais tīrais. Saskaņā ar plašsaziņas līdzekļu ziņojumiem PHP2Shell gadījumā 17.10.2026 tika novērots pirmais uzbrukuma mēģinājums, ielāpi parādījās 21.10.2026. Kas glabā tikai septiņas dienas, tam, iespējams, vairs nav stāvokļa, kas droši atrodas pirms iespējamās ielaušanās.

Pārbaudīta shēma apvieno vairākus periodus, piemēram, ikdienas dublējumus dažas nedēļas, iknedēļas dažus mēnešus un ikmēneša gadu. Precīzi periodi atkarīgi no jūsu aizsardzības vajadzības un datu aizsardzības dzēšanas pienākumiem.

Svarīgi arī: dublējums no laika pēc ielaušanās var saturēt webshell vai mainītus failus. Pēc incidenta nekad neatjaunojiet akli, bet salīdziniet failus ar tīru stāvokli un pārbaudiet tos, pirms vietne atkal iet tiešsaistē. Norādes, uz ko pievērst uzmanību, atradīsiet rakstā [Kompromitācijas pazīmes](https://phpsos.de/lv/php2shell/bin-ich-gehackt-anzeichen/). Ielāps neizņem ievadīto ļaunprogrammatūru, un dublējums to arī pats no sevis nedara.

## Atjaunošanas testēšana un dokumentēšana

Dublējums bez testa ir pieņēmums. Tikai atjaunošana parāda, vai ir visas daļas, vai atslēga darbojas un cik ilgi process patiešām ilgst.

- Regulāri testa vidē atjaunojiet pilnu dublējumu, ieskaitot datubāzi un konfigurāciju.
- Pārbaudiet, vai vietne pēc tam darbojas pilnībā: pieteikšanās, pasūtījumi, veidlapas, pasts.
- Izmēriet ilgumu un fiksējiet, kuri soļi bija manuāli. Salīdziniet rezultātu ar laiku, cik ilgi jūsu uzņēmums maksimāli var iztikt bez vietnes.
- Atjaunošanas instrukciju novietojiet tur, kur tā ir pieejama arī tad, ja serveris ir izkritis, piemēram, [IT ārkārtas rīcības plānā](https://phpsos.de/lv/compliance/notfallplan-erstellen/).

## Kā PHP SOS palīdz konkrēti?

- Pārbaudām jūsu esošos dublējumus uz pilnīgumu, glabāšanu, nodalīšanu no servera un aizsardzību pret dzēšanu.
- Ierīkojam 3-2-1 dublēšanu ar nemaināmu kopiju un kopā ar jums pārbaudām atjaunošanu.
- Pēc incidenta identificējam pēdējo tīro stāvokli un [ļaunprogrammatūras noņemšanas](https://phpsos.de/lv/leistungen/malware-entfernung/) ietvaros atjaunojam to ielāpotā sistēmā.
- [Security uzturēšanas līgumā](https://phpsos.de/lv/leistungen/security-wartungsvertrag/) pastāvīgi uzraugām dublējumus un veicam regulārus atjaunošanas testus.


## Biežāk uzdotie jautājumi

**Ko nozīmē 3-2-1 noteikums dublējumos?**  
Trīs jūsu datu kopijas, uz diviem dažādiem glabāšanas veidiem, no kurām viena atrodas citā vietā. Noteikums nodrošina, ka ne aparatūras bojājums, ne uzbrukums, ne ugunsgrēks neskar visas kopijas vienlaikus.

**Vai pietiek ar hostinga sniedzēja dublējumu?**  
Tas ir laba papildinājums, bet reti pietiekams. Noskaidrojiet, cik ilgi hostinga sniedzējs glabā stāvokļus, vai varat atjaunot paši un vai uzbrucējs ar jūsu klienta kontu varētu dublējumus izdzēst. Ieteicama sava, neatkarīga kopija.

**Vai pēc uzlaušanas var vienkārši atjaunot pēdējo dublējumu?**  
Tikai piesardzīgi. Pēdējais dublējums jau var saturēt ļaunprātīgu kodu, un ievainojamība, pa kuru uzbrucējs iekļuva, pēc tam joprojām ir atvērta. Vispirms noskaidrojiet un aizveriet cēloni, tad pārbaudītu stāvokli atjaunojiet ielāpotā sistēmā.

**Cik bieži jāpārbauda atjaunošana?**  
Regulāri un pēc lielākām sistēmas izmaiņām. Ir sevi pierādījis fiksēts ritms, piemēram, viena pilna atjaunošana ceturksnī testa vidē. Svarīgi, lai tests tiktu dokumentēts un robi novērsti.

## Avoti

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI: datu dublēšana](https://www.bsi.bund.de/)
- [php.net: drošības ziņojumi par PHP2Shell](https://www.php.net/)