# Бэкапы VPS: снапшоты, копии в S3 и restic — что выбрать и как настроить > Чем снапшот отличается от копии в S3 и от restic, как настроить резервное копирование каталогов и баз на VPS, проверить восстановление и не потерять данные при падении сервера. - Рубрика: Гайды по играм - Игра: VPS - Опубликовано: 2026-11-13T20:00:00+03:00 - Обновлено: 2026-11-13T20:00:00+03:00 - Адрес: https://blog.egnetwork.ru/vps-bekapy-snapshot-restic - Автор: Команда EGN Самая дорогая ошибка на VPS — отсутствие копий. Сервер можно случайно удалить, испортить обновлением или потерять вместе с машиной, на которой он работает. Поэтому бэкап — не опция, а часть настройки. Вопрос только в том, какой вариант выбрать и как проверить, что он работает. ## Коротко Снапшот — это быстрый откат всего диска на момент снимка, но он хранится на той же ноде и может пропасть вместе с ней. Копия в отдельном хранилище S3 переживает падение сервера. restic создаёт зашифрованные версии каталогов в S3 или на другом диске и управляет сроком хранения. Для надёжности комбинируйте: снапшот перед обновлением и restic по расписанию. ## Три слоя защиты Каждый вариант отвечает на свой вопрос. Снапшот отвечает на вопрос «как откатиться за минуту»: перед обновлением ядра или большой правкой конфигов вы снимаете снапшот и при ошибке возвращаете диск. Копия в S3 отвечает на вопрос «что делать, если сервер пропал»: данные лежат в другом месте, и их можно развернуть на новом VPS. restic отвечает на вопрос «какая версия файла была неделю назад» и даёт шифрование, дедупликацию и проверку целостности. ![Три слоя: снапшот на ноде, копия в S3 и версии restic](https://blog.egnetwork.ru/media/608) Важное различие: снапшот не заменяет копию. В кабинете EGN это прямо сказано в описании вкладки «Бэкапы»: копия диска хранится в отдельном хранилище S3, вне сервера и его ноды, и переживает потерю сервера. Снапшоты при этом лежат на локальном хранилище ноды. ## Как это выглядит в кабинете EGN В карточке VPS есть две вкладки: «Снапшоты» и «Бэкапы». Первая нужна для быстрых откатов, вторая — для копий в S3. На вкладке «Бэкапы» доступны две категории: «Горячее» с быстрым восстановлением и «Холодное», которое дешевле, но восстанавливается медленнее. Кнопка «Сделать копию сейчас» запускает копию вручную, а блок «Копии по расписанию» задаёт автоматику. Снапшоты оплачиваются по фактическому размеру снимка, списание идёт ежедневно, и у сервера есть лимит числа снапшотов, поэтому ненужные удаляйте. Актуальные цены и лимиты показаны в самой карточке. ![Вкладка «Бэкапы» в карточке VPS](https://blog.egnetwork.ru/media/598) Порядок действий в панели: 1. Откройте карточку сервера в разделе «Облачные серверы». 2. Перейдите на вкладку «Бэкапы» и выберите тип хранения: горячее для часто меняющихся данных, холодное для архивов. 3. Нажмите «Сделать копию сейчас» перед важной операцией и дождитесь статуса готовности. 4. Настройте расписание, если копии нужны регулярно. Если расписание выключено, копии делаются только вручную, и про них легко забыть. 5. На вкладке «Снапшоты» создавайте снимок перед обновлением системы и удаляйте его, когда убедились, что всё работает. ## Настройка restic с S3 restic — программа для резервного копирования, которая хранит данные в зашифрованном репозитории. Установите её и создайте репозиторий в S3. Пример для S3-совместимого хранилища: ```bash sudo apt install -y restic export RESTIC_REPOSITORY=s3:https://s3.example.com/vps-backups export RESTIC_PASSWORD_FILE=/root/.restic-pass export AWS_ACCESS_KEY_ID=ваш-ключ export AWS_SECRET_ACCESS_KEY=ваш-секрет restic init ``` Эти же четыре строки удобно положить в файл `/root/.restic-env` (права 600) и подключать командой `source /root/.restic-env`. Пароль репозитория сохраните в файл `/root/.restic-pass` с правами 600. Потерять пароль нельзя: восстановить данные без него невозможно. Ключи доступа к S3 держите в отдельном файле с правами 600 (ниже `/root/.restic-env`), а не в скриптах, которые попадают в git. Для локального теста можно создать репозиторий на другом диске: ```bash restic -r /srv/restic-test init ``` ## Резервная копия каталогов Копируйте не всё подряд, а то, что нельзя восстановить заново: конфиги, данные приложений, дампы баз, а не системные каталоги. Пример для сайта и настроек nginx: ```bash restic backup /var/www /etc/nginx /root/backups restic snapshots ``` Команда `restic snapshots` выводит список версий с идентификаторами и датами. Каждая новая копия хранит только изменившиеся блоки, поэтому повторные запуски занимают мало места. ## Срок хранения и очистка Без политики хранения репозиторий растёт бесконечно. Команда `forget` удаляет старые версии по правилам, а `--prune` освобождает место: ```bash restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune ``` Эта команда оставляет семь последних дневных копий, четыре недельные и шесть месячных. Перед первым запуском посмотрите, что будет удалено, добавив `--dry-run`. ## Расписание через cron Запускайте резервное копирование по расписанию. Скрипт `/root/restic-backup.sh` подключает файл с переменными, выполняет backup и forget. Затем добавьте его в cron: ```bash #!/bin/bash set -e source /root/.restic-env restic backup /var/www /etc/nginx /root/backups restic forget --keep-daily 7 --keep-weekly 4 --prune ``` ```bash sudo chmod 700 /root/restic-backup.sh sudo crontab -e ``` Строка для cron, которая запускает скрипт каждый день в 3:15: ```bash 15 3 * * * /root/restic-backup.sh >> /var/log/restic-backup.log 2>&1 ``` Лог поможет понять, что пошло не так, если копия перестала создаваться. ## Проверка восстановления Копия, которую не восстанавливали, не считается. Раз в месяц проверяйте восстановление на отдельном каталоге: ```bash restic check restic restore latest --target /root/restore-test --include /etc/nginx ls /root/restore-test/etc/nginx ``` `restic check` проверяет целостность репозитория, а восстановление в тестовый каталог показывает, что файлы действительно извлекаются. После проверки удалите каталог `/root/restore-test`. ## Симптом → причина → решение | Симптом | Частая причина | Что сделать | |---|---|---| | `Fatal: wrong password` | Пароль в файле не совпадает с репозиторием | Проверьте `RESTIC_PASSWORD_FILE`, пароль нельзя восстановить | | `Fatal: unable to open config file` | Неверный адрес или ключи S3 | Проверьте `RESTIC_REPOSITORY` и ключи доступа | | Копия растёт слишком быстро | Бэкапят кеши, логи и временные файлы | Исключите их через `--exclude` | | Старые версии не удаляются | `forget` запускали без `--prune` | Добавьте `--prune` или запустите `restic prune` | | Cron не создаёт копии | Скрипт не выполняется или нет переменных | Смотрите `/var/log/restic-backup.log` и запускайте скрипт вручную | | После отката снапшота пропали свежие изменения | Откат возвращает диск на момент снимка, всё позднее теряется | Снимайте снапшот непосредственно перед операцией, а данные, изменённые после него, сохраняйте отдельно | ## Примеры **Обновление ядра.** Снимите снапшот, выполните обновление, перезагрузите сервер. Если система не поднялась, откатитесь на снапшот. Сразу после успешной проверки снапшот можно удалить. **Переезд сайта на другой VPS.** Сделайте restic-копию каталогов и дамп базы, разверните их на новом сервере командой `restic restore latest --target /`, восстановите базу по дампу. Этот сценарий отрабатывает раз, когда вы переносите сервис. **Удалили файл по ошибке.** Найдите версию командой `restic snapshots`, затем восстановите конкретный файл: `restic restore --target /root/restore-test --include /var/www/index.html`. ## Что будет при переустановке Переустановка ОС на VPS удаляет файлы, базы и настройки на диске. Снапшоты и резервные копии при этом остаются, и к ним можно вернуться (так сказано в окне подтверждения переустановки в кабинете). Копии restic во внешнем S3 тоже не затрагиваются: после переустановки поставьте restic и выполните `restic restore`. ## Что копировать и как часто Разные данные меняются с разной скоростью, поэтому и копировать их нужно по-разному: | Что | Как часто | Куда | Срок хранения | |---|---|---|---| | Дамп базы | раз в сутки | S3 через restic | 7 дней, 4 недели, 6 месяцев | | Каталог сайта и загрузки | раз в сутки | S3 через restic | 7 дней, 4 недели | | Конфиги nginx, cron, systemd | раз в неделю и перед правкой | S3 через restic | 4 недели | | Снапшот VPS | перед обновлением ядра или крупной правкой | в кабинете | до проверки результата | | Миры и файлы игрового сервера | по расписанию игры или раз в сутки | S3 или снапшот | 7 дней и 4 недели | Таблица не универсальная: сверяйтесь с тем, сколько данных вы готовы потерять. Если сайт меняется каждый час, копируйте чаще. ## Симптом → причина → решение (восстановление) | Симптом | Причина | Решение | |---|---|---| | `restic restore` завершился, но файлов нет | Указан неверный `--target` или `--include` | Выведите список `restic ls latest`, проверьте пути | | Восстановленная база не поднимается | Дамп снят с другой версии PostgreSQL | Восстанавливайте на ту же версию или выполните миграцию | | Права файлов после восстановления неверные | restic сохраняет владельца, но не всегда в новой системе | Проверьте `chown` для каталогов приложения после восстановления | ## Частые ошибки - **Снапшот принимают за бэкап.** Снапшот на той же ноде не спасёт при её потере. Нужна отдельная копия. - **Пароль restic хранят в скрипте.** Файл с паролем должен иметь права 600 и не попадать в git. - **Копируют всё подряд.** Системные каталоги проще восстановить переустановкой, а конфиги и данные нужно сохранить. - **Не проверяют восстановление.** Через полгода выясняется, что копии пустые или повреждены. - **Дампы баз не делают отдельно.** Копия каталога с работающей базой может быть несогласованной, поэтому используйте дамп, как описано в статье [База данных на VPS: MySQL или PostgreSQL без утечек в интернет](https://blog.egnetwork.ru/vps-baza-dannykh-mysql-postgresql). - **Не следят за местом.** Растущий репозиторий без `forget` в какой-то момент упрётся в лимит. ## Итог Работающая схема бэкапов VPS состоит из трёх частей: снапшот для быстрого отката, копия в S3 на случай потери сервера и restic с расписанием и политикой хранения. Проверяйте восстановление раз в месяц. Если сервер ставится под игры, посмотрите статью [Игровой сервер на VPS или хостинг игр](https://blog.egnetwork.ru/vps-igrovoy-server-vs-hosting), там разобрано, когда копии делает панель, а когда вам. ## Вопросы и ответы ### Снапшот — это то же самое, что бэкап? Нет. Снапшот хранится на той же ноде и откатывает диск, а копия в S3 лежит отдельно и переживает падение сервера. ### Сколько хранить копий? Для большинства проектов хватает семи ежедневных, четырёх недельных и шести месячных. Для важных данных добавьте ещё годовые. ### Можно ли обойтись без restic? Да, если вы копируете один каталог и вам достаточно архива через `tar`. restic нужен, когда важны версии, шифрование и проверка целостности. ### Как часто делать копии? Для данных, которые меняются каждый час, ежечасно или чаще. Для сайта и конфигов обычно хватает раза в сутки. Сервер под игры за пару минут — [egnetwork.ru](https://egnetwork.ru/) ## Официальные источники - [s3.example.com](https://s3.example.com/vps-backups) --- Материал EGN (blog.egnetwork.ru), обновлено 13 ноября 2026; при цитировании указывайте ссылку.