Как делать резервные копии сервера HIP своими руками

У HIP нет кнопки «снять снапшот»: единственная операция в панели, которая трогает диск, - переустановка, и она всё стирает. Значит, резервные копии сервера HIP - целиком ваша зона ответственности: их делают инструментами на самом сервере, а хранят в другом месте. В инструкции: как привести данные в согласованное состояние перед копией, как забрать файлы и базы, зачем нужны restic и borg, как запускать бэкап по расписанию через systemd-таймер и как убедиться, что из копии реально можно восстановиться.

Коротко. Снапшотов в панели HIP нет, бэкап - только на вашей стороне. Перед копией выполните sync, а лучше на минуту остановите приложение и базу либо снимите дамп средствами СУБД. Файлы забирайте через tar (разово) или rsync -aAX (регулярно) на другую машину; базы - через pg_dump или mysqldump с ротацией по N дней. Рабочий инструмент по умолчанию - restic: шифрует и дедуплицирует сам, кладёт копии по SFTP или в объектное хранилище, запускается из systemd-таймера. Держите правило 3-2-1 и раз в месяц проверяйте восстановление.

В панели HIP нет встроенных снапшотов

Сразу главное: в панели HIP нет функции снапшотов. Нельзя одной кнопкой снять образ диска и потом так же откатиться. Единственная операция в панели, которая трогает диск, - это переустановка (Rebuild), и она не сохраняет, а стирает всё: систему, файлы, базы, настройки (см. Как переустановить ОС на сервере HIP).

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

Снапшот и бэкап - в чём разница

Снапшот (snapshot) - мгновенный образ всего диска: система, файлы, базы, настройки, всё как было в секунду съёмки. Снапшоты бывают у гипервизоров и в панелях некоторых провайдеров; у HIP такой функции нет. Даже там, где снапшот есть, он хранится рядом с сервером и вместе с сервером теряется.

Резервная копия (бэкап) - независимый набор ваших данных, сохранённый в другом месте: на другом сервере, в объектном хранилище, на домашнем диске. Копия не привязана к серверу HIP и переживёт что угодно с самим сервером - переустановку, удаление, проблему с оплатой или аккаунтом.

Грубо: снапшот - это «откатить весь сервер на вчерашний вечер». Бэкап - это «достать вот этот файл или вот эту базу за прошлую среду, даже если сервера больше нет». На HIP доступен только второй вариант, и вся статья дальше - про него.

Перед копией: приведите данные в согласованное состояние

Бэкап забирает файлы «как есть» на момент запуска. Если в этот момент база данных дописывает транзакцию, а приложение - лог, в копию попадёт наполовину записанное состояние. Большинство СУБД (PostgreSQL, MySQL с движком InnoDB) умеют восстановиться из такого при старте за счёт своего журнала, но полагаться на это не стоит - особенно для файловой копии базы.

Минимум - сбросить на диск то, что операционная система держит в оперативной памяти:

sync

Команда возвращает управление, когда буферы записаны. Вывода при успехе нет.

По возможности - на минуту остановить приложение и базу, снять копию, включить обратно:

systemctl stop myapp
systemctl stop postgresql
sync
# запускаете бэкап, дожидаетесь завершения
systemctl start postgresql
systemctl start myapp

Если остановка недопустима, снимайте базу не файлом, а дампом - СУБД сама выгрузит данные в согласованном виде (об этом ниже отдельно), а restic/rsync пусть забирают уже готовый файл дампа, а не «живые» файлы базы.

Файлы: tar и rsync

Для разовой копии каталогов подходит tar: он собирает всё в один сжатый архив.

tar czf /root/backup-$(date +%F).tar.gz --exclude='/var/www/*/cache' /etc /root /home /var/www

• c - создать архив, z - сжать gzip, f - в указанный файл
• --exclude - пропустить каталог, который не нужен в копии (кеш, временные файлы)
• в конце - список того, что класть: /etc (настройки системы и сервисов), каталог приложения, /home (данные пользователей)
• $(date +%F) - подставляет дату в имя файла, вида 2026-09-10

Архив потом увезите с сервера: scp /root/backup-*.tar.gz you@backuphost:/srv/backups/. Пока он лежит только на сервере, это не резервная копия.

Для регулярной синхронизации всего сервера на другую машину используйте rsync - он копирует только изменившееся:

rsync -aAX --delete \
--exclude={"/proc/*","/sys/*","/dev/*","/run/*","/tmp/*","/var/tmp/*","/var/cache/*","/var/lib/lxcfs","/swapfile","/swap.img","/lost+found"} \
/ backup@backuphost:/srv/backups/web01/

• -a - режим архива: сохраняет права, владельцев, временные метки, символьные ссылки
• -A - переносит списки доступа (ACL), -X - расширенные атрибуты файлов
• --delete - делает зеркало: удаляет на приёмнике то, чего уже нет на сервере. Без него удалённые файлы накапливаются в копии
• --exclude={...} - виртуальные и временные каталоги, которые копировать бессмысленно и вредно: /proc, /sys, /dev - это не файлы, а интерфейсы ядра; /tmp, /var/cache - временное; /swapfile или /swap.img - файл подкачки (имя зависит от системы, проверьте своё через swapon --show)

Что вы должны увидеть: rsync перечислит передаваемые файлы и в конце напишет sent ... bytes received ... bytes и total size is .... Ошибки доступа выводятся строками rsync: ... Permission denied - запускайте под sudo или root. Синтаксис {...} - это раскрытие фигурных скобок в bash; в упрощённой оболочке sh перечислите пути отдельными --exclude.

Чистые tar и rsync ничего не шифруют. Если приёмник - чужое хранилище, копию надо зашифровать (об этом ниже) или сразу взять инструмент, который делает это сам.

Базы данных: pg_dump и mysqldump

Файлы базы из-под работающей СУБД копировать нельзя - получите битый снимок. Нужен дамп: СУБД сама выгружает данные в согласованном виде.

PostgreSQL, одна база в своём сжатом формате:

sudo -u postgres pg_dump -Fc mydb > /root/db/mydb-$(date +%F).dump

MySQL или MariaDB, все базы (запускать под root, аутентификация идёт через сокет):

mysqldump --single-transaction --quick --all-databases | gzip > /root/db/all-$(date +%F).sql.gz

• -Fc у pg_dump - собственный сжатый формат Postgres, из него удобно восстанавливать выборочно через pg_restore
• --single-transaction - согласованный срез таблиц InnoDB без блокировки записи; для старых таблиц MyISAM не сработает, там нужен --lock-all-tables
• --quick - выгружает построчно, не собирая всю таблицу в память
• pg_dump и pg_restore идут с сервером PostgreSQL - это версия 16 на Ubuntu 24.04 и 14 на 22.04; на MariaDB mysqldump доступен и под именем mariadb-dump (/usr/bin/mariadb-dump)
• двух команд мало: дамп надо (1) увезти с сервера, (2) делать по расписанию, (3) хранить N последних и удалять старые

Простая ротация - в каталоге лежат только дампы, поэтому удаляем всё старше 7 дней:

find /root/db -type f -mtime +7 -delete

Дальше эти дампы забирает restic вместе с остальными файлами - и увозит с сервера сразу в зашифрованном виде.

restic или borg: зачем они

tar, rsync, pg_dump - это кирпичи. Чтобы из них получилась нормальная система бэкапа, надо самому решить шифрование, дедупликацию (не хранить одно и то же по десять раз), инкременты (копировать только изменения), ротацию и проверку целостности. restic и borg - это уже готовые системы, где всё перечисленное внутри:

• шифруют копию на клиенте, до отправки - в хранилище попадают только зашифрованные данные;
• хранят инкременты с дедупликацией - первый бэкап полный, дальше летят только изменившиеся блоки;
• умеют ротацию по правилам («держи 7 дневных, 4 недельных, 6 месячных»);
• проверяют, что архив читается и не побился.

restic проще стартовать, и он умеет много типов приёмников: SFTP, S3-совместимые хранилища, локальный диск. borg старше, чуть быстрее на больших объёмах и экономнее по месту, но приёмник должен быть либо локальным, либо доступным по SSH с установленным borg. Для первой своей системы бэкапа берите restic; borg - если у вас есть выделенный бэкап-сервер и очень большие объёмы.

Минимальный путь с restic

Установка (заодно ставим borg - на случай, если решите пользоваться им):

apt install -y restic borgbackup

На Ubuntu 24.04 из репозитория ставятся restic 0.16.4 и borg 1.2.8 - этого хватает для всего, что ниже. В старых LTS версия ниже (на 22.04 restic примерно 0.12-0.14), и часть флагов, включая --read-data-subset=5%, может отсутствовать - тогда обновите его командой restic self-update или возьмите бинарник со страницы релиза на GitHub.

Настройте доступ к репозиторию - это место, где restic хранит копии. Здесь пример по SFTP на другую машину (нужен SSH-доступ на приёмник по ключу):

export RESTIC_REPOSITORY="sftp:backup@backuphost:/srv/restic/web01"
export RESTIC_PASSWORD="длинная-случайная-фраза"
restic init

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

Первый бэкап - перечисляете каталоги:

restic backup /etc /root /home /var/www

В конце вывода: Files: N new, ..., Added to the repository: ..., snapshot a1b2c3d4 saved. Это и есть признак успеха.

Посмотреть список точек:

restic snapshots

Ротация - оставить 7 дневных, 4 недельных, 6 месячных, остальное удалить и освободить место:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Проверка, что репозиторий цел:

restic check

Автозапуск: systemd-таймер

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

Файл с доступами /root/.restic-env (права только root: chmod 600 /root/.restic-env):

RESTIC_REPOSITORY=sftp:backup@backuphost:/srv/restic/web01
RESTIC_PASSWORD=длинная-случайная-фраза

Сервис /etc/systemd/system/restic-backup.service:

[Unit]
Description=restic backup

[Service]
Type=oneshot
EnvironmentFile=/root/.restic-env
ExecStart=/usr/bin/restic backup /etc /root /home /var/www
ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
ExecStartPost=/usr/bin/curl -fsS -m 10 https://hc-ping.com/ВАШ-UUID

• Type=oneshot - сервис отрабатывает и завершается, это не постоянный процесс
• EnvironmentFile - подтягивает переменные RESTIC_* из защищённого файла, чтобы пароли не лежали в самом юните
• первый ExecStartPost - ротация сразу после успешного бэкапа
• второй ExecStartPost - пинг сервиса мониторинга (Healthchecks.io и подобные). Запустилось - пинг прошёл. Упало - пинга нет, и монитор пришлёт уведомление. Это проверено: если ExecStart завершился ненулевым кодом, ни один ExecStartPost не выполняется, так что пинг - именно сигнал успеха

Таймер /etc/systemd/system/restic-backup.timer:

[Unit]
Description=daily restic backup

[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true
RandomizedDelaySec=15m

[Install]
WantedBy=timers.target

• OnCalendar - когда запускать (каждый день в 03:30)
• Persistent=true - если сервер в это время был выключен, запустить пропущенный бэкап при включении
• RandomizedDelaySec - случайный разброс старта, чтобы не бить в хранилище пиком в одну секунду

Включить и проверить:

systemctl daemon-reload
systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

Последняя команда покажет строку таймера с колонками NEXT, LEFT, LAST, PASSED, UNIT, ACTIVATES; время в NEXT сдвинуто на случайную дельту из-за RandomizedDelaySec. Ручная проверка прямо сейчас - systemctl start restic-backup.service, затем journalctl -u restic-backup.service -e.

Привычнее cron? Строка 30 3 * * * . /root/.restic-env && restic backup /etc /root /home /var/www в crontab -e сделает то же, но без журнала и без запуска пропущенных заданий.

Правило 3-2-1, сроки хранения, шифрование

Правило 3-2-1 - это минимальный разумный уровень:

• 3 копии данных: рабочая на сервере и ещё две;
• 2 разных носителя или площадки: не «две папки на том же диске»;
• 1 копия вне площадки: у другого провайдера, в другом регионе, дома.

Куда складывать копии на практике: второй недорогой VPS с большим диском и доступом по SSH, объектное хранилище с S3-совместимым API или диск дома. Главное - другая площадка: если теряете сервер целиком, копия должна остаться.

Сроки хранения (retention) ставьте от того, за какой срок проблема может остаться незамеченной. Типично: 7 дневных, 4-8 недельных, 6-12 месячных. Битый файл, который никто не открывал месяц, должен ещё находиться в копии.

Шифрование обязательно для всего, что лежит вне вашего сервера. restic и borg шифруют сами. Если делаете tar или rsync в чужое хранилище - шифруйте перед отправкой. В скрипте пароль руками ввести некому, поэтому берём его из файла:

echo 'длинная-случайная-фраза' > /root/.gpg-pass
chmod 600 /root/.gpg-pass
tar czf - /etc /home /var/www \
| gpg -c --batch --pinentry-mode loopback --passphrase-file /root/.gpg-pass \
-o /root/backup-$(date +%F).tar.gz.gpg

• --batch --pinentry-mode loopback --passphrase-file - обязательны в неинтерактивном режиме. Без них gpg -c в конвейере не может запросить пароль и молча создаёт пустой файл с кодом возврата 0 - тихий обвал бэкапа, который вы заметите только при попытке восстановиться
• файл /root/.gpg-pass держите с правами 600 и не в том же каталоге, куда кладёте архив

Расшифровать потом: gpg -d --batch --pinentry-mode loopback --passphrase-file /root/.gpg-pass /root/backup-2026-09-10.tar.gz.gpg | tar xzf -.

Проверяйте восстановление

Бэкап, из которого ни разу не восстанавливались, - это не бэкап, а предположение. Раз в месяц прогоняйте пробное восстановление.

restic, отдельный каталог во временную папку:

restic restore latest --target /tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /tmp/restore-test/etc/nginx

Пустой вывод diff - файлы из копии совпадают с боевыми. Заодно проверьте целостность самих данных в репозитории:

restic check --read-data-subset=5%

Дамп базы - поднимите во временную базу и посмотрите, что данные на месте:

sudo -u postgres createdb restore_test
sudo -u postgres pg_restore -d restore_test /root/db/mydb-2026-09-10.dump
sudo -u postgres psql -d restore_test -c "select count(*) from users;"
sudo -u postgres dropdb restore_test

Число строк примерно совпадает с боевым - дамп рабочий.

Раз в несколько месяцев проверяйте и полное восстановление: возьмите чистый сервер (как - в статье Как создать сервер в панели HIP), разверните на нём копию из restic и убедитесь, что сайт открывается. Пока это не проверено, вы не знаете, сколько времени займёт восстановление и всё ли в копии есть.

Сценарий -> что восстанавливать

• Сломали конфиг в /etc, сервис не стартует. Восстанавливать - отдельный файл из restic. Чем - restic restore latest --include /etc/... --target /tmp/r, затем скопировать нужное на место.
• Уронили или повредили базу. Восстанавливать - последний дамп. Чем - загрузить в чистую базу через pg_restore или mysql < dump.sql.
• Случайно удалили каталог приложения. Восстанавливать - этот каталог из restic. Чем - restic restore нужного пути из последней точки.
• Сервер не загружается. Восстанавливать - сначала систему, потом данные. Чем - поднять через режим восстановления; если не помогает - переустановка и restic restore данных.
• Переезд на другой сервер. Восстанавливать - файлы и базы на свежую ОС. Чем - rsync -aAX каталогов либо restic restore на новый сервер.
• Компрометация, шифровальщик. Восстанавливать - только данные, не систему. Чем - переустановить ОС и поднять данные из проверенной копии за дату до заражения.

Частые вопросы

Есть ли снапшоты у HIP

Нет. В панели HIP нет функции снапшотов: единственная операция, затрагивающая диск, - это переустановка (Rebuild), и она стирает всё. Резервные копии сервера HIP делаются только на вашей стороне - инструментами на самом сервере с выгрузкой в другое место.

Как забэкапить VPS без снапшотов

Поставьте restic или borg, создайте репозиторий в другом месте (второй сервер по SFTP или объектное хранилище) и запускайте restic backup по расписанию через systemd-таймер. Отдельно снимайте дампы баз через pg_dump или mysqldump. Копия шифруется на сервере до отправки, так что в хранилище уходят только зашифрованные данные.

restic или borg

Оба - системы инкрементного шифрованного бэкапа с дедупликацией и ротацией. restic проще в старте и поддерживает много типов хранилищ, включая S3-совместимые. borg чуть быстрее и экономнее на больших объёмах, но требует, чтобы приёмник был локальным или доступным по SSH с установленным borg. Для первой системы бэкапа берите restic.

Куда складывать бэкапы VPS

Не на тот же сервер. Подходит второй недорогой VPS с большим диском и доступом по SSH, объектное хранилище с S3-совместимым API или диск дома. Главное - другая площадка: если теряете сервер целиком, копия должна остаться. Держите правило 3-2-1: три копии, два носителя, одна вне площадки.

Как автоматизировать бэкап сервера

Сделайте systemd-сервис с командами restic backup и restic forget --prune и таймер с OnCalendar на нужное время и Persistent=true. В конце сервиса добавьте пинг сервиса мониторинга: прошёл бэкап - пришёл пинг, упал - пинга нет, и придёт уведомление. Так вы узнаете о сломанном бэкапе до того, как он понадобится.

Как проверить, что бэкап рабочий

Раз в месяц делайте пробное восстановление: restic restore одного каталога во временную папку и diff с боевым, restic check --read-data-subset=5% для целостности данных, а дамп базы поднимайте во временную базу и сверяйте число строк. Бэкап, из которого ни разу не восстанавливались, не считается рабочим.

Что дальше

• Как переустановить ОС на сервере HIP - что именно стирает Rebuild и как пройти его по шагам.
• Как создать сервер в панели HIP - если нужен второй сервер под приёмник бэкапов или под проверку восстановления.
• Защита свежего VPS - фаервол, отдельный пользователь и первые шаги на чистой системе, в том числе на бэкап-сервере.