Резервное копирование (backup) — создание и хранение копий данных для восстановления после потери, повреждения или атаки. Единственная надёжная защита от случайного удаления, ransomware, аппаратных сбоев и человеческих ошибок.
Как работает
Стратегии резервного копирования строятся вокруг правила 3-2-1: три копии данных, на двух разных носителях, одна — вне основного места хранения (offsite). Например: основные данные на сервере, бекап в объектном хранилище, ещё одна копия в другом регионе.
Типы бекапов: полный (full) — копия всех данных, долго, надёжно. инкрементальный (incremental) — только изменения с последнего бекапа, быстро. дифференциальный (differential) — изменения с последнего полного бекапа.
Инструменты резервного копирования
rsync — базовый инструмент синхронизации файлов. С флагом --link-dest создаёт инкрементальные снимки через hard links. BorgBackup — дедупликация, шифрование, инкрементальные бекапы. 100 GB данных с ежедневными снимками за месяц занимают 110 GB вместо 3 TB. tar — создание архивных копий директорий.
Бекапы баз данных
Файловое копирование включённой базы данных повреждает бекап — нужны специальные инструменты. MySQL/MariaDB: mysqldump --all-databases --single-transaction создаёт консистентный дамп без блокировки таблиц InnoDB. PostgreSQL: pg_dump или pg_basebackup для физических копий. Автоматический дамп через cron каждую ночь — минимум для продакшена.
История
Резервное копирование существует с момента появления цифровых данных. Первые магнитные ленты для бекапа — 1960-е. В 1980-х корпоративные системы создавали ночные ленточные бекапы. Ransomware-волна 2010-х (Locky, WannaCry, REvil) поставила бекапы во главу угла безопасности: атаки шифруют данные и требуют выкуп. Единственное надёжное решение — изолированные бекапы, недоступные с атакованного сервера.
Автоматизация на VPS
# Ежедневный бекап через cron
0 3 * * * /usr/local/bin/backup.sh
# backup.sh: дамп MariaDB + rsync на удалённый сервер
#!/bin/bash
DATE=$(date +%Y%m%d)
mysqldump --all-databases -u root -p"$DBPASS" | gzip > /tmp/db_$DATE.sql.gz
rsync -az /tmp/db_$DATE.sql.gz backup@remote:/backups/
rsync -az /var/www/ backup@remote:/backups/www/На что обращать внимание
Бекап без проверки восстановления — не бекап. Раз в месяц тестируйте полное восстановление на отдельном сервере. Шифруйте бекапы перед отправкой в облачное хранилище — утечка бекапа раскрывает все данные. Изолируйте бекап-сервер: если атакующий получил доступ к основному серверу, он не должен иметь возможность удалить бекапы (Write-Once storage, отдельные SSH-ключи).
Проверка восстановления
Игнорируемый, но критичный шаг — тестирование бекапа. Создайте отдельный VPS или используйте Docker-контейнер для полного восстановления из последнего снимка. Для баз данных: разверните дамп на тестовой БД и выполните несколько ключевых запросов. Для файлов: восстановите выборку, проверьте целостность через md5sum. SLA на восстановление (RTO, RPO) определяет частоту бекапов: если допустимая потеря данных 4 часа — бекапы нужны каждые 4 часа.