Что такое бэкап на самом деле: инструкция для айтишника

Давайте сразу без воды: бэкап (резервная копия) — это ваша последняя линия обороны. Это тот самый спасательный круг, когда всё пошло ко дну: сервер лег, базу затерли, вирус-шифровальщик все файлы превратил в кашу. Если у вас нет нормального бэкапа, вы просто теряете данные. А вместе с ними — деньги, время и нервы.

Представьте, что вы разработчик, который месяц пилил фичу. Или админ, который настраивал сложную конфигурацию. Или владелец сайта с тысячами заказов. А потом что-то пошло не так, и все это исчезло. Бэкап — это единственная возможность откатиться назад и сказать: «Ничего страшного, у нас же была копия».

Почему это важно даже для крутых спецов?

Кажется, что у опытных ребят все под контролем. Git, тесты, автоматические деплои. Но жизнь любит подкидывать сюрпризы.

• Человеческий фактор. Самый частый сценарий. DROP DATABASE production; — и тишина. Или скрипт, который чистил временные файлы и по ошибке удалил не то.

• Технические сбои. Жесткий диск редко умирает со свистом и дымом. Чаще он просто тихо перестает определяться в один прекрасный день.

• Вредоносное ПО. Ransomware (вирусы-шифровальщики) не дремлют. Они шифруют все, до чего дотянутся, включая сетевые диски.

• Физические проблемы. Пожар, потоп в дата-центре, проблемы с электричеством. Бывает и такое.

Сухой остаток: если данные существуют в одном экземпляре, их как бы и нет. Любой серьезный инцидент это докажет.

Главное правило: 3-2-1

Запомните эту магическую формулу. Это основа основ, с которой нельзя спорить.

• 3 копии данных. Оригинал + две резервных копии. Всего три.

• 2 разных типа носителей. Нельзя хранить все на одинаковых дисках. Комбинации: внутренний HDD + внешний SSD, локальный NAS + облако (S3, Яндекс.Облако, Google Drive).

• 1 копия за пределами офиса/локации. Если все бэкапы лежат в одном серверной, а там случился потоп, вы теряете всё. Одна копия должна быть географически удалена.

Как копировать: виды бэкапов

Тут есть выбор. От простого и ресурсоемкого до сложного и экономичного.

Полный бэкап (Full)
Копирует всё подряд, каждый раз. Просто, надежно, но долго и требует много места. Как делать полную фотографию архива каждый день. Хорошо подходит для еженедельного создания основной точки восстановления.

Инкрементальный бэкап (Incremental)
Умный способ. Первый раз копируется всё (полный бэкап), а потом — только то, что изменилось с момента последней копии (неважно, полной или инкрементальной). Быстро, экономит место. Но чтобы восстановить данные на определенный день, нужна цепочка: полный бэкап + все инкрементальные копии до нужной даты. Если одно звено цепи битое — восстановление может сломаться.

Дифференциальный бэкап (Differential)
Компромиссный вариант. Первый раз — полная копия. Потом каждый раз копируется всё, что изменилось с момента последнего полного бэкапа. Размер копий со временем растет, но восстановление проще: нужны только последний полный бэкап и последний дифференциальный.

Что выбрать на практике? Частая схема:

• В воскресенье ночью — Полный бэкап.

• С понедельника по субботу — Инкрементальные бэкапы.

• Раз в месяц — Отправить полную копию на внешний носитель и увезти в другое место.

Что копировать? Иерархия важности

1. Данные. Самое ценное. Базы данных, документы, исходный код (хотя код должен быть в Git!), медиафайлы. То, что создают люди и программы, и что нельзя просто так взять и восстановить.

2. Конфигурации. Настройки серверов (файлы из /etc/), конфиги веб-серверов (nginx, Apache), настройки Docker, Kubernetes, CI/CD. Их восстановление с нуля — адская работа.

3. Система. Образы виртуальных машин, контейнеров. Нужно, но требует много места. Иногда проще и быстрее развернуть чистую систему и накатить на неё конфиги и данные из бэкапов 1 и 2.

Автоматизируйте это!

Ручные бэкапы — это путь в никуда. Человек забудет, устанет, ошибется.

Простой скрипт для примера (Bash):

# Куда складываем копии
BACKUP_DIR="/mnt/backup_storage"
DATE=$(date +%Y-%m-%d_%H-%M)
# Название вашей БД
DB_NAME="my_app_db"

# 1. Дамп базы данных PostgreSQL
pg_dump -U postgres $DB_NAME | gzip > $BACKUP_DIR/db_$DATE.sql.gz

# 2. Копируем важные директории (например, загруженные файлы)
tar -czf $BACKUP_DIR/uploads_$DATE.tar.gz /var/www/myapp/uploads/

# 3. Копируем ключевые конфиги
tar -czf $BACKUP_DIR/configs_$DATE.tar.gz /etc/nginx/ /etc/postgresql/

# 4. Отправляем копию в облако (пример для S3-совместимого)
aws s3 cp $BACKUP_DIR/db_$DATE.sql.gz s3://my-backup-bucket/

# 5. Чистим старые бэкапы локально (храним 30 дней)
find $BACKUP_DIR -name "*.gz" -mtime +30 -delete

# 6. Пишем в лог
echo "$DATE: Backup completed successfully" >> /var/log/backup.log