Резервное копирование: как настроить бэкап по правилу 3-2-1 — инструкция для новичка

Что такое резервное копирование и зачем оно нужно

Резервное копирование — это отдельная копия сайта, баз данных и настроек, из которой вы восстановите работу после сбоя. Синхронизация копией не считается: она повторяет любое изменение, в том числе случайное удаление, и пустая папка появляется во втором месте за секунды. Основы разобраны в материале блога о бэкапе.

RAID (Redundant Array of Independent Disks, массив независимых дисков) переживёт отказ одного диска, но не ошибку человека. Если вы удалите таблицу или вирус зашифрует файлы, RAID мгновенно повторит это на всех дисках. Подробнее о массивах — в инструкции, как настроить RAID 1.

Представьте сайт в /var/www на VPS (виртуальном сервере) с Ubuntu. В 03:00 обновление ломает базу данных, и магазин перестаёт принимать заказы. Если у вас есть ночная копия, вы потеряете не больше 24 часов данных и вернёте сайт за время от нескольких минут до часа. Если копии нет, данные не вернуть. Свой сервер можно арендовать в пару кликов.

Данные теряются по четырём основным причинам:

• ошибка администратора: неверная команда или неудачное обновление;
• взлом и вирус-шифровальщик;
• сбой диска;
• удаление проекта или блокировка аккаунта у провайдера.

Какие бывают виды резервного копирования

Полная копия забирает все данные целиком. Если на сервере 10 ГБ, каждый запуск записывает 10 ГБ. Это самый простой для восстановления вариант, но самый долгий и затратный по месту.

Инкрементальная копия сохраняет только изменения с последней копии любого типа. При 2% ежедневных изменений это около 200 МБ в день. Дифференциальная копия сохраняет изменения с последней полной: в первый день около 200 МБ, на шестой день примерно 1,2 ГБ, если правки не повторяются.

Разницу по пяти параметрам показывает таблица для примера с 10 ГБ данных:

Программа restic хранит данные дедуплицированными снимками. Каждый снимок выглядит как полная копия, а на диск записываются только новые блоки данных. Поэтому новичку не нужно выбирать между типами вручную.

Настройку по шагам смотрите в инструкции по резервному копированию VPS через restic, а другие инструменты сравните в обзоре программ для резервного копирования.

Правило 3-2-1, RPO и RTO: сколько копий нужно

Правило 3-2-1 отвечает на вопрос «сколько копий нужно»: 3 копии данных на 2 типах носителей, и 1 из них за пределами основной площадки. Для VPS с Ubuntu это сайт в /var/www и база данных, копия на втором диске или сервере и копия в S3-хранилище у другого провайдера или в другом центре обработки данных (ЦОД). Копия на том же диске, что и оригинал, резервной не считается.

RPO (Recovery Point Objective) — допустимая потеря данных: за какой период вы готовы потерять изменения. Ежедневный бэкап по расписанию 0 3 * * * означает, что в худшем случае пропадут до 24 часов данных. RTO (Recovery Time Objective) — время восстановления. Оно зависит от объёма и канала, для небольшого сайта обычно от нескольких минут до часа. Проверить восстановление удобно на отдельной машине, которую можно создать в облаке за несколько минут.

Частоту выбирайте по цене потери данных:

• Блог: раз в сутки в 03:00, потеря до 24 часов обычно допустима.
• Интернет-магазин: файлы раз в сутки, базу копируйте чаще, например каждые несколько часов.
• База с заказами: дамп (mysqldump или pg_dump) каждый час или чаще, ведь каждый потерянный заказ — это деньги клиента.

Что копировать на сервере и сайте

В бэкап входит всё, без чего сайт не поднять на чистом сервере: файлы, база данных и настройки. На VPS с Ubuntu файлы сайта лежат в /var/www, а конфигурации веб-сервера — в /etc/nginx или /etc/apache2. Если вы ставили базу по инструкции установки PostgreSQL, её данные тоже включите в копию.

Базу копируют дампом, а не копированием файлов. Работающая база постоянно пишет на диск, поэтому скопированные файлы получаются повреждёнными. Команда mysqldump для MySQL и pg_dump для PostgreSQL выгружают согласованное состояние в один файл. Дамп делайте до отправки копии в хранилище.

Не копируйте кэш, временные файлы из /tmp и логи старше 30 дней: они увеличивают размер копии и не нужны для восстановления. Чем меньше лишнего, тем быстрее проходит ночной запуск в 03:00.

Отдельно добавьте то, что трудно воссоздать:

• ключи и сертификаты, например каталог /etc/letsencrypt, если выпускали сертификат через Let’s Encrypt;
• задачи планировщика cron: сохраните вывод crontab -l;
• письма из ящиков, если вы держите доменную почту на своём сервере;
• тома и compose-файлы, если сайт работает в контейнерах, как в инструкции по установке Docker на VPS.

Как настроить резервное копирование VPS пошагово

Схема ниже рассчитана на VPS (виртуальный сервер) с Ubuntu: сайт лежит в /var/www, база данных (БД) работает на MySQL или PostgreSQL. Копии делает restic: он шифрует данные в репозитории по умолчанию и отправляет в хранилище только изменения.

Репозиторий разместите в S3-совместимом хранилище или на втором сервере по SFTP (SSH File Transfer Protocol, порт 22). Если не знаете, как подключиться к серверу, откройте инструкцию по работе с PuTTY, а базовые команды посмотрите в материале про Linux для сервера.

Выполните шаги по порядку, на настройку уйдёт около 20–30 минут:

1. Определите данные: каталог /var/www, дамп базы и настройки в /etc.
2. Подключитесь к серверу по SSH (Secure Shell, порт 22) и выполните apt install restic.
3. Создайте репозиторий командой restic init с параметром -r и адресом вашего S3 или SFTP. Сохраните пароль отдельно от сервера: без него копии не расшифровать.
4. Сделайте дамп в /var/backups: mysqldump для MySQL или pg_dump для PostgreSQL. Не копируйте файлы работающей БД напрямую, такая копия получится повреждённой.
5. Запустите restic backup /var/www /var/backups /etc.
6. Соберите шаги 4 и 5 в один скрипт и добавьте его в cron (планировщик задач) со строкой 0 3 * * *: копия будет создаваться ежедневно в 03:00.
7. Настройте ротацию командой restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune: останутся 7 ежедневных, 4 недельных и 6 месячных копий.
8. Проверьте список через restic snapshots и сделайте пробное восстановление: restic restore latest --target /tmp/restore.

Повторяйте пробное восстановление раз в квартал и после крупных изменений на сервере. При ежедневном запуске в худшем случае вы потеряете до 24 часов данных. Разбор опций и примеры скриптов есть в блоге: резервное копирование VPS с restic. Если на диске не хватает места под дампы, подберите VPS с запасом по объёму.

Где хранить копии и сколько это стоит

Копия на том же диске, что и оригинал, не считается резервной. При поломке диска, взломе или ошибочной команде rm -rf пропадут оба экземпляра. По правилу 3-2-1 одна из 3 копий лежит вне основной площадки: у другого провайдера или в другом центре обработки данных (ЦОД).

Цена зависит от провайдера: от бесплатного варианта до оплаты за гигабайт в месяц. Для restic подойдёт S3-совместимое хранилище (объектное хранилище с оплатой за объём) или второй сервер по SFTP, порт 22.

Сравните пять вариантов:

NAS (сетевое хранилище) разберите по материалам как собрать NAS-сервер и как настроить домашний сервер для данных. Для личного облака пригодится установка Nextcloud на VPS, а ответы на вопросы о VPS помогут выбрать второй сервер.

Частые ошибки при резервном копировании

Данные чаще теряют не из-за отсутствия бэкапа, а из-за ошибок в его настройке. Пять самых распространённых: копия лежит на том же сервере, её ни разу не восстанавливали, копируют файлы живой базы без дампа, нет ротации, потерян пароль к репозиторию.

Каждая ошибка проявляется в момент аварии, когда исправлять уже поздно. Ниже у каждой есть причина и решение.

Копия лежит на том же сервере

Копия на том же диске, что и оригинал, не считается резервной: при сбое диска, взломе или удалении VPS (виртуального сервера) пропадёт всё сразу. Отправляйте репозиторий restic в S3-совместимое хранилище или на второй сервер по SFTP (порт 22) у другого провайдера. Так копия переживёт и атаку, о которой рассказано в материале о DDoS-атаках.

Копию ни разу не восстанавливали

Архив может оказаться пустым или неполным, и вы узнаете об этом только во время аварии. Раз в квартал и после крупных изменений сервера выполняйте restic restore latest --target /tmp/check и проверяйте, что сайт открывается.

Файлы работающей базы копируют без дампа

Во время записи файлы MySQL или PostgreSQL находятся в неконсистентном состоянии, поэтому копия получается повреждённой. Перед отправкой в хранилище делайте дамп: mysqldump для MySQL или pg_dump для PostgreSQL.

Нет ротации, и диск заполняется

Старые копии копятся, и однажды бэкап падает из-за нехватки места. Добавьте после каждого запуска restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune, а свободное место контролируйте через систему мониторинга Zabbix.

Пароль к репозиторию потерян или лежит на сервере

restic шифрует данные по умолчанию, и без пароля копию не открыть. Храните его в менеджере паролей, а не в файле на сервере, который вы защищаете. Проверить остальные доступы поможет проверка сайта на безопасность.

Вторая площадка, дамп, ротация 7/4/6, менеджер паролей и квартальная проверка закрывают все пять ошибок и занимают меньше часа настройки.

Какой способ выбрать и кому хватит бэкапа хостинга

Автокопии провайдера включаются в панели за несколько минут и не требуют знаний, но лежат на той же площадке, что и сайт. Скрипт с rsync или tar прост и бесплатен, однако ротацию, шифрование и проверку придётся писать самим. restic закрывает эти задачи: шифрует данные, хранит только изменения и удаляет старые копии командой restic forget --prune. Готовые программы с графическим интерфейсом подойдут, если командная строка вас пугает.

Копий провайдера хватает небольшому сайту или блогу, где за сутки вы теряете пару правок. Но они не заменяют копию вне площадки: при блокировке аккаунта или аварии в ЦОД (центре обработки данных) пропадут и сайт, и бэкап. Добавьте хотя бы одну копию у другого провайдера.

Выбирайте по сценарию:

• Небольшой сайт: копии провайдера плюс выгрузка раз в неделю во внешнее хранилище.
• Интернет-магазин: restic ежедневно в 03:00 и дамп базы через mysqldump или pg_dump, ведь до 24 часов заказов терять нельзя.
• База 1С: выгружайте её штатными средствами и храните файл вне площадки, подробности разобраны в материале про 1С в облаке.
• Собственный сервер: полное правило 3-2-1, о серверах читайте в статьях про VDS и создание сервера.

Самонастройка не подходит, если у вас нет доступа по SSH (Secure Shell) или на сервере лежат критичные данные, а администратора нет. Тогда берите управляемый тариф: провайдер настроит копии и проверит восстановление. Если сомневаетесь, найдите ответы на частые вопросы о VPS.