# Стратегия за резервни копия на сървър: резервни копия по правилото 3-2-1

> Стратегия за резервни копия на сървър по правилото 3-2-1: какво да архивирате, как копията да оцелеят след атака и защо да тествате възстановяването.

Източник: https://phpsos.de/bg/ratgeber/backups-3-2-1/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Надеждната стратегия за резервни копия на сървър следва правилото 3-2-1: три копия, два вида носители, едно копие извън сградата. За да оцелеят копията и след атака, поне едно копие се нуждае от защита срещу изтриване от самия сървър. А едва успешният тест за възстановяване показва, че архивирането работи в критичен момент.

## Какво означава правилото 3-2-1

Правилото 3-2-1 е прост, доказан с години принцип за архивиране на данни:

- **3 копия:** оригиналните данни и две резервни копия.
- **2 вида носители:** например локален диск и обектно хранилище или хранилище на сървър и лента.
- **1 копие извън сградата:** на друго местоположение, при друг доставчик или офлайн.

За уеб сървърите това означава конкретно: резервно копие на същия твърд диск като уебсайта не се брои за самостоятелно копие. Ако сървърът откаже или бъде компрометиран, и двете са загубени. Затова за ръководството основният въпрос не е „Имаме ли резервни копия?“, а „Можем ли да възстановим дейността от копие, което инцидентът не е достигнал?“

## Стратегия за резервни копия на сървър, която оцелява след атака

Атакуващите знаят, че резервните копия обезсмислят работата им. Който има достъп до сървър, затова често търси и резервни копия, за да ги изтрие или шифрова. Съвременната стратегия затова често разширява правилото 3-2-1 до **3-2-1-1-0**: допълнително едно копие офлайн или неизменяемо и нула грешки при теста за възстановяване.

Три принципа правят резервните копия устойчиви:

- **Pull вместо push:** Отделна система за резервни копия взема данните от уеб сървъра. Самият уеб сървър няма данни за достъп, с които би могъл да изтрие резервни копия.
- **Неизменяемост:** Обектно хранилище със заключване на съхранението или snapshots, които не могат да се изтриват през определено време.
- **Разделени достъпи:** Акаунтът за резервни копия не е същият като клиентския акаунт при хостинг доставчика и има собствен втори фактор.

> **Важно:**
> Шифровайте резервните копия, които са извън сградата, и съхранявайте ключа отделно. Изгубеният ключ прави копието неизползваемо, а съхранен заедно с него ключ обезсмисля шифроването.

## Какво трябва да се архивира

При уеб сървърите често се архивира само webroot. За пълно възстановяване тогава липсват важни части.

| Област | Примери | Указание |
|---|---|---|
| Файлове на приложението | Webroot, качвания, теми, разширения | Качванията се променят често |
| Бази данни | MySQL/MariaDB, PostgreSQL | да се архивират консистентно, не само копиране на файлове |
| Конфигурация | Уеб сървър, PHP-FPM пулове, php.ini, cron задачи | необходима за бързо ново изграждане |
| Сертификати и ключове | TLS сертификати, ключове на приложението | да се съхраняват шифровани и отделно |
| Документация | Достъпи, зависимости, ред на възстановяване | без нея всяко ново изграждане отнема по-дълго |

## Пример: архивиране на база данни и файлове

Следният пример показва основните градивни елементи на ежедневно архивиране. На практика инструмент за резервни копия с шифроване, дедупликация и правила за съхранение поема прехвърлянето извън сградата.

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

# Консистентно архивиране на базата данни; данните за достъп от защитен файл, не в командата
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
  --single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"

# Файлове на приложението и конфигурация
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d

# Контролни суми за по-късна проверка
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
```

Файлът `.backup-my.cnf` съдържа данните за достъп на потребител на базата данни, който има право само да чете, и има права `0600`. `--single-transaction` осигурява при InnoDB таблици консистентно състояние, без магазинът да се спира.

След това отделна система прехвърля архива извън сградата. Важно е тази стъпка да се наблюдава: задача за резервно копие, която мълчаливо се проваля от дни, иначе се забелязва едва в критичен момент. Достатъчно е ежедневно съобщение за успех, размер и продължителност, стига някой да го чете и да се занимава с отклоненията.

Ако ползвате допълнително резервни копия или snapshots на Вашия хостинг доставчик, изяснете писмено колко дълго се пазят, можете ли сами да възстановявате и запазват ли се копията при прекратен или блокиран акаунт. Тези копия са добро допълнение, но не заместват собствено, независимо архивиране.

## Съхранение: защо по-старите състояния са важни след PHP2Shell

След атака най-ценното не е най-новото резервно копие, а най-новото чисто. При PHP2Shell според медийни съобщения на 17.10.2026 е наблюдаван първи опит за атака, а пачовете излязоха на 21.10.2026. Който пази само седем дни, може вече да няма състояние, което със сигурност е преди възможното проникване.

Доказана схема съчетава няколко периода, например ежедневни копия за няколко седмици, седмични за няколко месеца и месечни за една година. Точните периоди зависят от Вашата нужда от защита и от задълженията за изтриване от защитата на данните.

Важно е и следното: резервно копие от времето след проникване може да съдържа уеб шелове или променени файлове. След инцидент никога не възстановявайте на сляпо, а сравнявайте файловете с чисто състояние и ги проверявайте, преди уебсайтът да е отново онлайн. Указания на какво да внимавате ще намерите на страницата [Признаци за компрометиране](https://phpsos.de/bg/php2shell/bin-ich-gehackt-anzeichen/). Пачът не премахва внедрен зловреден софтуер, а и резервното копие не го прави от само себе си.

## Тестване и документиране на възстановяването

Резервно копие без тест е предположение. Едва възстановяването показва дали всички части са налице, дали ключът работи и колко дълго действително отнема процесът.

- Възстановявайте редовно цялостно архивиране върху тестова среда, включително база данни и конфигурация.
- Проверете дали уебсайтът след това работи изцяло: вход, поръчки, формуляри, поща.
- Измерете продължителността и запишете кои стъпки са били ръчни. Сравнете резултата със срока, който Вашата дейност най-много може да издържи без уебсайт.
- Съхранявайте инструкцията за възстановяване там, където е достъпна и при отказал сървър, например в [ИТ плана за аварийни ситуации](https://phpsos.de/bg/compliance/notfallplan-erstellen/).

## Как конкретно помага PHP SOS?

- Проверяваме Вашите съществуващи резервни копия за пълнота, съхранение, отделеност от сървъра и защита срещу изтриване.
- Настройваме архивиране по 3-2-1 с неизменяемо копие и тестваме възстановяването заедно с Вас.
- След инцидент установяваме последното чисто състояние и го възстановяваме върху пачната система в рамките на [премахването на злонамерен софтуер](https://phpsos.de/bg/leistungen/malware-entfernung/).
- В [договора за поддръжка на сигурността](https://phpsos.de/bg/leistungen/security-wartungsvertrag/) наблюдаваме непрекъснато архивите и извършваме редовни тестове за възстановяване.


## Често задавани въпроси

**Какво означава правилото 3-2-1 при резервните копия?**  
Три копия на Вашите данни, на два различни вида носители, от които едно на друго място. Правилото гарантира, че нито хардуерна повреда, нито атака, нито пожар засягат всички копия едновременно.

**Достатъчно ли е резервното копие на моя хостинг доставчик?**  
То е добро допълнение, но рядко е достатъчно. Изяснете колко дълго хостинг доставчикът пази състоянията, можете ли сами да възстановявате и дали атакуващ с Вашия клиентски акаунт би могъл да изтрие резервните копия. Препоръчва се собствено, независимо копие.

**Мога ли след хакване просто да възстановя последното резервно копие?**  
Само с внимание. Последното резервно копие може вече да съдържа злонамерен код, а уязвимостта, през която е влязъл атакуващият, след това още е отворена. Първо изяснете и затворете причината, после възстановете проверено състояние върху пачната система.

**Колко често да тествам възстановяването?**  
Редовно и след по-големи промени в системата. Доказал се е твърд ритъм, например пълно възстановяване веднъж на тримесечие върху тестова среда. Важно е тестът да се документира и пропуските да се отстраняват.

## Източници

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI: Архивиране на данни](https://www.bsi.bund.de/)
- [php.net: Съобщения за сигурност относно PHP2Shell](https://www.php.net/)