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

Что такое backup и чем он отличается от обычной копии файлов

Backup — это отдельная копия данных, из которой можно восстановить сервер после сбоя. Она хранится не на том же диске и желательно не на том же сервере. Общие принципы разобраны в материале о резервном копировании.

Backup не равен другим способам защиты. RAID (массив из нескольких дисков) переживает поломку одного диска, но повторяет и ваши ошибки: удалённый файл исчезает со всех дисков сразу. Снимок диска на том же хосте пропадёт вместе с хостом, а папка /root/copy рядом с оригиналом не спасёт при сбое диска или взломе. Если вы ещё выбираете сервер, посмотрите, как устроена аренда виртуального сервера, а основы хостинга описаны в статье что такое хостинг.

В инструкции мы используем один пример: VPS (виртуальный сервер) на Ubuntu с сайтом и базой MySQL, около 20 ГБ данных.

Отдельная копия защищает в четырёх ситуациях:

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

Как работает backup: полные, инкрементальные копии и правило 3-2-1

Полная копия сохраняет все выбранные данные целиком. Для VPS с 20 ГБ данных каждый запуск займёт около 20 ГБ. Инкрементальная копия сохраняет только изменения с прошлой копии: она быстрая и компактная, но для восстановления нужна вся цепочка. Дифференциальная копия хранит изменения с последней полной: она больше инкрементальной, зато для восстановления хватит двух звеньев.

Программа restic совмещает плюсы этих подходов. Каждый запуск restic backup создаёт снимок, который выглядит как полная копия, но хранит только новые блоки данных. Одинаковые блоки записываются один раз (дедупликация), поэтому первая копия близка к размеру исходных данных, а следующие содержат только изменения. Данные шифруются паролем хранилища ещё до отправки на удалённый сервер.

Одной копии мало: диск и сервер могут выйти из строя одновременно. RAID и снимки диска на том же хосте backup не заменяют. Правило 3-2-1 для вашего VPS выглядит так:

• 3 копии данных: рабочие файлы на VPS и две резервные;
• 2 типа носителей: например, диск сервера и объектное хранилище;
• 1 копия вне основного сервера: в другом дата-центре.

Внешней копией хорошо служит объектное хранилище S3 (Simple Storage Service), подробнее о нём в материале о том, что такое S3. Другие варианты сравните в обзоре программ для резервного копирования.

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

Копируйте то, что нельзя скачать заново: настройки, файлы сайта, пользовательские данные и дампы баз. Систему и программы проще переустановить, чем хранить. В нашем примере VPS на Ubuntu с сайтом и MySQL занимает около 20 ГБ, и для восстановления хватает четырёх каталогов.

Базу данных копируйте дампом, а не файлами работающей системы управления базами данных (СУБД): такие файлы могут оказаться в несогласованном состоянии. Для MySQL используйте mysqldump --single-transaction, для PostgreSQL — pg_dump, результат сохраняйте в /var/backups/db. Дамп делайте заранее, например в 02:30, чтобы к запуску restic в 03:00 файл был готов. Если вы только ставите СУБД, разберите установку PostgreSQL.

Не включайте в копию то, что создаётся заново или не хранит данных:

• /proc и /sys — виртуальные каталоги ядра;
• /tmp и /var/cache — временные файлы и кеш;
• установленные пакеты — их вернёт apt.

Для Nextcloud добавьте каталог с его данными, подробности — в инструкции по установке Nextcloud на VPS. Если путей на сервере много, сверьтесь с описанием структуры Linux для сервера.

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

Настройка идёт на примере VPS с Ubuntu, сайтом и базой MySQL, около 20 ГБ данных. Копии уходят на отдельный сервер по SFTP (SSH File Transfer Protocol), поэтому поломка основного диска хранилище не заденет. restic шифрует данные и хранит их снимками с дедупликацией: одинаковые блоки записываются один раз.

Если вы подключаетесь к серверу впервые, сначала прочитайте, как подключиться к серверу через PuTTY. Доступ к хранилищу удобно проверить в графическом клиенте, как описано в материале про SFTP-подключение в FileZilla. Если сомневаетесь, хватит ли ресурсов тарифа, изучите ответы на вопросы о VPS.

Выполняйте команды от root или через sudo строго по порядку:

1. Подключитесь к серверу по SSH (Secure Shell), порт 22: ssh root@IP-адрес.
2. Установите restic командой apt install restic и проверьте версию: restic version.
3. Создайте файл пароля из 16+ символов: echo 'ваш-пароль' > /root/.restic-pass, затем chmod 600 /root/.restic-pass. Выполните export RESTIC_PASSWORD_FILE=/root/.restic-pass и создайте хранилище: restic init --repo sftp:backup@storage.example.com:/backups/vps1. Копию пароля сохраните отдельно от сервера.
4. Сделайте дамп базы данных: mysqldump --single-transaction --all-databases > /var/backups/db/all.sql. Для PostgreSQL используйте pg_dump.
5. Запустите первую копию: restic backup /etc /var/www /home /var/backups/db. Она близка по размеру к исходным данным, следующие содержат только изменения.
6. Откройте crontab -e и добавьте запись 0 3 * * * с командой restic backup из шага 5. Копирование будет запускаться каждый день в 03:00, а строку с дампом поставьте в cron чуть раньше.
7. Настройте ротацию: restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune. Затем проверьте восстановление: restic restore latest --target /tmp/restore.

Раз в месяц запускайте restic check: команда проверяет целостность хранилища и сообщает о повреждённых данных. Вместе с пробным восстановлением это единственный способ убедиться, что копия рабочая. Если файлы из /tmp/restore открываются и дамп базы читается, настройка завершена.

Сколько места и денег нужно для backup

Возьмём пример из инструкции: на VPS (виртуальном сервере) лежит около 20 ГБ данных. Первая копия по размеру близка к исходным данным, следующие содержат только изменения.

С историей из 7 ежедневных, 4 еженедельных и 6 ежемесячных снимков закладывайте под хранилище 30–40 ГБ. При цене внешнего хранилища обычно 1–3 ₽ за ГБ в месяц это 30–120 ₽ в месяц, точнее зависит от провайдера и тарифа.

Копия на том же диске не спасает: при поломке диска, взломе или удалении раздела пропадут и сервер, и копия. RAID и снимки диска на том же хосте backup не заменяют. Сравните варианты хранения:

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

Частые ошибки при backup и как их исправить

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

У каждой есть причина и понятное решение, кроме потери пароля.

Копия лежит на том же диске

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

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

Причина: копия создаётся, но неизвестно, читается ли она. Раз в месяц запускайте restic check и restic restore latest --target /tmp/restore.

Базу копируют файлами на ходу

Причина: файлы MySQL меняются во время копирования и получаются несогласованными. Решение: делайте дамп mysqldump --single-transaction в /var/backups/db, для PostgreSQL используйте pg_dump.

Потерян пароль хранилища

Решения нет: данные зашифрованы, без пароля их не открыть. Используйте пароль не короче 16 символов и храните его копию отдельно от сервера.

Диск хранилища переполнился

Причина: снимки копятся без ротации. Решение: запускайте restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune и закладывайте 30–40 ГБ на каждые 20 ГБ данных.

Cron не запустился, и никто не заметил

Причина: задание тихо падает после смены пути или пароля. Раз в неделю смотрите вывод restic snapshots: свежий снимок должен быть не старше суток.

Разместите копию отдельно, делайте дамп базы, настройте ротацию и раз в месяц проверяйте восстановление. Тогда backup сработает в тот день, когда он понадобится.

Чем ещё можно сделать backup: rsync, снимки VPS и панель хостинга

Restic не единственный вариант. Новичку чаще встречаются ещё три: rsync (Remote Sync, программа синхронизации файлов), снимки диска у провайдера и встроенные копии панели хостинга. Они решают разные задачи, и не каждый даёт полноценный backup.

Rsync копирует файлы быстро, но хранит только последнее состояние: файл, удалённый или испорченный на сервере, при следующем запуске исчезнет и из копии. Снимок диска лежит на том же хосте, поэтому backup не заменяет. Копии панели удобны, но часто хранятся на том же сервере и могут не включать настройки из /etc.

Сравните способы по главным критериям:

Для VPS с сайтом выберите restic плюс дамп базы через mysqldump --single-transaction. Снимок у провайдера добавьте вторым уровнем: перед обновлением системы он вернёт сервер за считаные минуты. Другие программы сравните в подборке программ для резервного копирования.

Когда такого backup недостаточно

Схема из этой инструкции рассчитана на один VPS на Ubuntu с примерно 20 ГБ данных и одной ночной копией в 03:00. Если сервер выйдет из строя в 17:00, вы потеряете 14 часов работы: заказы, регистрации, записи в базе. Для сайта-визитки это приемлемо, для интернет-магазина с оплатами нет.

Дамп через mysqldump --single-transaction тоже даёт только срез на момент запуска. Если в высоконагруженной базе данных (БД) нельзя терять даже несколько минут, нужна репликация: второй сервер получает изменения постоянно и может заменить основной. Репликация дополняет backup, но не заменяет его: случайно удалённая таблица исчезнет на реплике сразу.

Ещё три случая выходят за рамки примера. Это серверы Windows, где нет cron и привычных путей вроде /etc; объёмы в терабайтах, где первая копия идёт сутками, а 1 ТБ в хранилище обычно стоит 1 000–3 000 ₽ в месяц; компании с формальными требованиями к срокам и месту хранения данных.

Что делать вместо этого или вместе с этим:

• настройте репликацию средствами самой БД и оставьте ночной backup как страховку от ошибок;
• выберите готовое корпоративное решение для резервного копирования с отчётами и журналом операций;
• если нужна отказоустойчивость на нескольких серверах, изучите настройку кластера Kubernetes;
• для проекта с жёсткими требованиями сравните VPS-хостинги по рейтингу и проверьте, какие варианты копирования они предлагают;
• обратитесь к системному администратору, а типовые вопросы прочитайте в разборе о VPS.