Накратко: Надеждната стратегия за резервни копия на сървър следва правилото 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 сертификати, ключове на приложението | да се съхраняват шифровани и отделно |
| Документация | Достъпи, зависимости, ред на възстановяване | без нея всяко ново изграждане отнема по-дълго |
Пример: архивиране на база данни и файлове
Следният пример показва основните градивни елементи на ежедневно архивиране. На практика инструмент за резервни копия с шифроване, дедупликация и правила за съхранение поема прехвърлянето извън сградата.
#!/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. Който пази само седем дни, може вече да няма състояние, което със сигурност е преди възможното проникване.
Доказана схема съчетава няколко периода, например ежедневни копия за няколко седмици, седмични за няколко месеца и месечни за една година. Точните периоди зависят от Вашата нужда от защита и от задълженията за изтриване от защитата на данните.
Важно е и следното: резервно копие от времето след проникване може да съдържа уеб шелове или променени файлове. След инцидент никога не възстановявайте на сляпо, а сравнявайте файловете с чисто състояние и ги проверявайте, преди уебсайтът да е отново онлайн. Указания на какво да внимавате ще намерите на страницата Признаци за компрометиране. Пачът не премахва внедрен зловреден софтуер, а и резервното копие не го прави от само себе си.
Тестване и документиране на възстановяването
Резервно копие без тест е предположение. Едва възстановяването показва дали всички части са налице, дали ключът работи и колко дълго действително отнема процесът.
- Възстановявайте редовно цялостно архивиране върху тестова среда, включително база данни и конфигурация.
- Проверете дали уебсайтът след това работи изцяло: вход, поръчки, формуляри, поща.
- Измерете продължителността и запишете кои стъпки са били ръчни. Сравнете резултата със срока, който Вашата дейност най-много може да издържи без уебсайт.
- Съхранявайте инструкцията за възстановяване там, където е достъпна и при отказал сървър, например в ИТ плана за аварийни ситуации.
Как конкретно помага PHP SOS?
- Проверяваме Вашите съществуващи резервни копия за пълнота, съхранение, отделеност от сървъра и защита срещу изтриване.
- Настройваме архивиране по 3-2-1 с неизменяемо копие и тестваме възстановяването заедно с Вас.
- След инцидент установяваме последното чисто състояние и го възстановяваме върху пачната система в рамките на премахването на злонамерен софтуер.
- В договора за поддръжка на сигурността наблюдаваме непрекъснато архивите и извършваме редовни тестове за възстановяване.
Често задавани въпроси
Какво означава правилото 3-2-1 при резервните копия?
Три копия на Вашите данни, на два различни вида носители, от които едно на друго място. Правилото гарантира, че нито хардуерна повреда, нито атака, нито пожар засягат всички копия едновременно.
Достатъчно ли е резервното копие на моя хостинг доставчик?
То е добро допълнение, но рядко е достатъчно. Изяснете колко дълго хостинг доставчикът пази състоянията, можете ли сами да възстановявате и дали атакуващ с Вашия клиентски акаунт би могъл да изтрие резервните копия. Препоръчва се собствено, независимо копие.
Мога ли след хакване просто да възстановя последното резервно копие?
Само с внимание. Последното резервно копие може вече да съдържа злонамерен код, а уязвимостта, през която е влязъл атакуващият, след това още е отворена. Първо изяснете и затворете причината, после възстановете проверено състояние върху пачната система.
Колко често да тествам възстановяването?
Редовно и след по-големи промени в системата. Доказал се е твърд ритъм, например пълно възстановяване веднъж на тримесечие върху тестова среда. Важно е тестът да се документира и пропуските да се отстраняват.