Бэкап: как настроить резервное копирование сервера и VPS — инструкция для новичка

Что такое бэкап и чем он отличается от снапшота и RAID

Бэкап — это отдельная копия данных, которую можно развернуть на другом сервере. Представьте: вы по ошибке выполнили rm -rf /var/www/site на VPS (Virtual Private Server, виртуальном выделенном сервере). Сайт исчез, а вместе с ним рухнула база MySQL shop_db. Без копии магазин придётся собирать заново, а заказы за недели потеряются.

Снапшот — моментальный слепок диска, но он лежит в хранилище провайдера рядом с сервером. Если аккаунт заблокирован или площадка недоступна, пропадут и сервер, и слепок. Поэтому снапшот не заменяет бэкап.

RAID (Redundant Array of Independent Disks, массив независимых дисков) защищает от отказа диска, но мгновенно повторяет на втором диске удаление файлов и вирус. Как устроены зеркальные массивы, читайте в материале про настройку RAID 1, а о хранении копий дома — в статье про домашний сервер для данных.

Вот что спасёт сайт /var/www/site и базу shop_db в разных ситуациях:

• Удалили каталог или таблицу: помогает только бэкап, RAID бессилен.
• Вирус зашифровал файлы: выручит копия вне сервера.
• Отказал один диск: достаточно RAID, но бэкап не помешает.
• Недоступна площадка провайдера: остаётся только копия вне неё, по правилу 3-2-1 это 1 из 3 копий.

Как работает бэкап: типы копий и правило 3-2-1

Бэкап — отдельная копия данных, которую можно развернуть на другом сервере. Копии бывают трёх типов: полная, инкрементная и дифференциальная. Полная копирует всё сразу: каталог /var/www/site и базу shop_db. Две другие сохраняют только изменения.

Снапшот бэкапом не считается: это слепок диска, который делает гипервизор и хранит рядом с сервером. Если пропадёт площадка провайдера, исчезнут и сервер, и слепок. Бэкап должен лежать отдельно.

Правило 3-2-1 и график для сквозного примера выглядят так:

• 3 копии данных: рабочие файлы и две резервные;
• 2 типа носителей: диск сервера (/backup) и отдельный сервер;
• 1 копия вне площадки: её передают по SSH, порт 22, — подробнее про сетевые протоколы;
• воскресенье: полная копия;
• с понедельника по субботу: 6 инкрементных копий, запуск в 03:00;
• потеря данных при сбое: не больше 24 часов.

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

Копируйте всё, что нельзя быстро собрать заново: файлы сайта (/var/www/site), базу данных MySQL (shop_db), конфиги и почту. Конфиги nginx лежат в /etc/nginx, задания cron — в выводе crontab -l. Систему и пакеты можно поставить заново, поэтому их копировать не обязательно. Расположение файлов проще понять из руководства по Linux для сервера, а ящики на своём домене описаны в материале о настройке доменной почты.

Частоту задаёт RPO (Recovery Point Objective, допустимая потеря данных). При ежедневной копии вы теряете до 24 часов данных, при копии каждые 6 часов — до 6 часов. Хранить копии удобно по схеме 7/4/3: 7 ежедневных, 4 еженедельных и 3 ежемесячных.

Выбирайте частоту по тому, сколько работы пропадёт при сбое:

• сайт-визитка или блог: раз в сутки;
• интернет-магазин и форум: базу копируйте каждые 6 часов, файлы — раз в сутки;
• почта: раз в сутки;
• конфиги: после каждого изменения.

Как настроить бэкап VPS по шагам

Возьмём сквозной пример: сайт лежит в /var/www/site, база MySQL называется shop_db, копии сначала попадают в /backup, а затем уходят на второй сервер. Скрипт запускается каждый день в 03:00, поэтому при сбое вы потеряете не более 24 часов данных.

Если команды в терминале вам пока незнакомы, сначала прочитайте основы Linux для сервера. Проверять файлы на сервере можно и в графическом клиенте: подключитесь по SFTP через FileZilla. Для копий нужен запас диска, поэтому заранее подберите VPS с достаточным объёмом.

Выполняйте шаги по порядку, каждый занимает пару минут:

1. Подключитесь по SSH (Secure Shell, защищённый удалённый доступ): ssh root@IP-адрес -p 22. Затем создайте каталог для копий: mkdir /backup && chmod 700 /backup, чтобы его читал только владелец.
2. Создайте скрипт /usr/local/bin/backup.sh. Первой командой сделайте дамп базы: mysqldump --single-transaction -u root -p shop_db | gzip > /backup/shop_db.sql.gz. Второй заархивируйте сайт: tar -czf /backup/site.tar.gz /var/www/site. Пароль MySQL для запуска без вас храните в файле ~/.my.cnf с правами chmod 600, а не в тексте скрипта.
3. Сделайте скрипт исполняемым: chmod +x /usr/local/bin/backup.sh. Запустите его вручную и убедитесь, что ошибок нет. Права на файлы дампов выставьте командой chmod 600 /backup/*.
4. Добавьте задание в cron (планировщик задач Linux): выполните crontab -e и впишите 0 3 * * * /usr/local/bin/backup.sh. Следом добавьте очистку: find /backup -type f -mtime +7 -delete, она удалит файлы старше 7 дней.
5. Выгрузите копии на второй сервер командой rsync -az -e "ssh -p 22" /backup/ user@IP-второго-сервера:/backup/. Эту строку тоже добавьте в конец скрипта, чтобы вторая копия появлялась автоматически.
6. Проверьте результат: выполните ls -lh /backup на обоих серверах и сверьте размеры файлов. Дамп текстовой базы обычно получается в 2–4 раза меньше исходных данных.

Эта схема закрывает ежедневную копию с хранением вне сервера. Разворачивать копию на тестовом VPS стоит раз в 3 месяца: только так вы узнаете, что бэкап рабочий.

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

Копия на том же сервере гибнет вместе с ним при сбое диска или взломе. По правилу 3-2-1 одна копия должна лежать вне площадки провайдера. Выбирайте хранилище по независимости от основного сервера, скорости и цене.

Сравните четыре популярных варианта:

Место считайте так: объём данных × число хранимых копий + запас. Для схемы из 7 ежедневных, 4 еженедельных и 3 ежемесячных копий это 14 копий. Для 10 ГБ данных получится до 140 ГБ без сжатия. Текст, дампы и код gzip сжимает в 2–4 раза, то есть до 35–70 ГБ, а фото и архивы почти не сжимаются.

Шифруйте копии до отправки. Утилиты restic и BorgBackup используют AES-256 (Advanced Encryption Standard) и хранят данные в зашифрованном виде. Пароль держите отдельно от сервера. Для домашнего хранилища соберите NAS-сервер по инструкции и настройте внешний IP-адрес для доступа, а для второго сервера подберите VPS под хранение копий.

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

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

Ниже пять типичных ошибок: копии на том же сервере, непроверенное восстановление, копирование базы обычными файлами, открытые права на дампы и отсутствие ротации. У каждой есть причина и простое решение.

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

Каталог /backup на самом VPS (виртуальном сервере) пропадает вместе с ним: при сбое диска, взломе или удалении аккаунта исчезают и сайт, и копии. Отправляйте вторую копию на отдельный сервер: rsync -az -e "ssh -p 22" /backup/ user@host:/backup/.

Восстановление ни разу не проверяли

Архив может оказаться битым или неполным, и вы узнаете об этом в момент аварии. Раз в 3 месяца разворачивайте копию на тестовом VPS и открывайте сайт. Если после этого страница не грузится по таймауту, разберите ошибку 522 Connection Timed Out.

Базу копируют как обычные файлы

Файлы MySQL меняются во время записи, поэтому такую копию часто не удаётся поднять. Делайте логический дамп: mysqldump --single-transaction -u root -p shop_db | gzip > /backup/shop_db.sql.gz. Сжатие gzip обычно уменьшает дамп в 2–4 раза.

Дампы доступны всем пользователям

В дампе лежат пароли и данные клиентов, и любой пользователь сервера может его прочитать. Закройте доступ: chmod 700 /backup для каталога и chmod 600 для файлов дампов.

Нет ротации, и диск забит

Копии копятся, пока диск не заполнится, а следующий запуск backup.sh не завершится с ошибкой. Удаляйте старые файлы в скрипте: find /backup -type f -mtime +7 -delete.

Проверьте свою схему по пяти пунктам: копия вне сервера, тест восстановления, mysqldump, права 700 и 600, ротация. Если все пункты выполнены, бэкап поможет в реальной аварии, а не только на бумаге.

Ручной бэкап, панель хостинга или специальные утилиты: что выбрать

Скрипт /usr/local/bin/backup.sh с записью cron 0 3 * * * даёт полный контроль: вы сами решаете, что копировать, куда отправлять и сколько хранить. Он бесплатный и понятный, но работу скрипта проверяете вы сами.

Автобэкап в панели провайдера включается за несколько кликов. Наличие, глубина хранения и цена зависят от тарифа, а копии часто лежат рядом с сервером, как и снапшот. Одной панелью правило 3-2-1 не закрыть, поэтому заранее сравните условия хранения копий на VPS.

Утилиты restic и BorgBackup делают дедупликацию: одинаковые блоки данных хранятся один раз, и ежедневные копии занимают заметно меньше места. Они шифруют данные алгоритмом AES-256, поэтому их удобно отправлять вне площадки. Настройки CDN вроде Cloudflare в бэкап сервера не входят, их ведите отдельно: настройте Cloudflare и сохраните параметры.

Выбор зависит от объёма данных и опыта:

• Новичку: скрипт из шагов выше плюс вторая копия на отдельном сервере по SSH, порт 22.
• Большие объёмы данных или нужно шифрование: restic или Borg.
• Автобэкап панели: дополнительный слой, а не единственная копия.
• Kubernetes: у него свои инструменты резервного копирования, их разбирает материал о настройке кластера Kubernetes.

Для кого этой схемы бэкапа недостаточно

Ежедневная копия в 03:00 даёт RPO (Recovery Point Objective, допустимую потерю данных) до 24 часов. Если магазин принимает заказы круглосуточно, а потеря даже 15 минут недопустима, одной копии мало. Нужна репликация: база постоянно передаёт изменения на второй сервер.

Вторая граница — объём. Когда данных сотни ГБ, воскресная полная копия занимает часы, а 100 ГБ по каналу 100 Мбит/с скачиваются больше двух часов. Здесь помогают инкрементные утилиты с дедупликацией, например restic или BorgBackup. Третий случай — требования закона или договора к срокам и месту хранения данных: схема с 7 ежедневными, 4 еженедельными и 3 ежемесячными копиями под них не рассчитана.

Если на тестовом сервере нет ценных данных, хватит снапшота: он дешевле и делается за минуты.

Куда идти дальше, зависит от вашей ситуации:

• нужна репликация: изучите документацию вашей СУБД (системы управления базами данных) и подготовьте второй сервер с постоянным белым IP-адресом;
• данных сотни ГБ: перейдите на restic или BorgBackup;
• действуют требования закона: уточните их у юриста и у провайдера;
• сервер тестовый: делайте снапшот и при необходимости разверните сервер заново.