Как сделать бэкап VPS своими руками: полное руководство

В личном кабинете WeaselCloud у услуги VPS всего два действия - «Изменить услугу» и «Параметры обновления» (апгрейд тарифа) - и это весь список, никакой кнопки «сделать бэкап» или раздела со снапшотами там нет. Значит бэкап VPS - это то, что вы настраиваете сами, без опоры на панель, и первое, что стоит понять на берегу: копия, которая лежит в соседней папке на том же диске, бэкапом не является. Если сервер откажет целиком - из-за диска, из-за ошибки в консоли, из-за чужих рук - копия откажет вместе с ним.

Коротко. Заберите файлы с сервера через tar (разовый архив) или rsync (регулярное обновление) на другую машину - свой компьютер, второй VPS или объектное хранилище. Базы данных выгружайте отдельно, mysqldump или pg_dump. Для настоящей автоматизации возьмите restic - он шифрует и дедуплицирует копию сам, докладывает только то, что изменилось, и работает по SFTP или в S3-совместимое хранилище без установки чего-либо на другой стороне. Запускайте его по расписанию через systemd-таймер, держите копии по правилу 3-2-1 и хотя бы раз в месяц по-настоящему восстанавливайтесь из бэкапа на отдельной машине - иначе вы просто не знаете, рабочий он или нет.

В панели WeaselCloud нет ни снапшотов, ни кнопки «сделать бэкап»

На странице услуги в my.weasel.cloud есть общая информация, вкладка «Информация о хостинге» с IP и паролем сервера, параметры конфигурации только для чтения и блок «Действия», а в нём буквально два пункта: сменить услугу и изменить тариф. Ни резервного копирования, ни снапшотов (снапшот - мгновенный слепок состояния диска целиком, который панель делает за вас одной кнопкой) здесь нет, как нет и консоли с кнопкой перезагрузки - панель тонкая, это биллинговая обёртка вокруг сервера, а не полноценная система управления.

Это обычное дело среди недорогих VPS: многие провайдеры оставляют бэкап целиком на клиенте, а свои снапшоты продают отдельной платной опцией либо не продают вовсе. В проверенных частях кабинета WeaselCloud такого раздела нет; если у вас на аккаунте видно что-то похожее на бэкап-услугу - уточните в поддержке, но по умолчанию на неё рассчитывать не стоит.

Файлы: tar для разового среза, rsync - для постоянного бэкапа VPS

Для файлов есть два инструмента под разные задачи. tar (от tape archive - изначально утилита для записи на ленточные накопители) собирает файлы в один архив разом; удобно перед рискованным обновлением или переносом сервера, но неудобно для ежедневного повтора - каждый раз архив собирается заново целиком.

tar -czvf backup-$(date +%F).tar.gz /etc /var/www /home

• -c - создать новый архив, -z - сжать через gzip, -v - показывать список файлов по ходу работы, -f - имя выходного файла
• $(date +%F) - подставляет текущую дату в формате 2026-09-24, чтобы архивы не перезаписывали друг друга
• перечисляйте только то, что реально нужно восстановить - конфиги, файлы сайта, домашние каталоги; архивировать всю файловую систему целиком, включая /proc и /sys, не нужно и бессмысленно

Дальше архив нужно унести с сервера - хотя бы простым scp backup-2026-09-24.tar.gz user@другой-сервер:/backups/. Пока файл лежит только на исходном VPS, это не бэкап, а просто ещё один файл на том же диске.

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

rsync -aAX --delete /var/www/ user@backup-host:/backups/var-www/

• -a (archive) - сохраняет права доступа, время изменения, символические ссылки и владельца файла
• -A - переносит ACL (расширенные права доступа, если они используются), -X - расширенные атрибуты файловой системы
• --delete - убирает на приёмнике файлы, которых уже нет в источнике, то есть копия становится зеркалом, а не архивом версий; используйте этот флаг только тогда, когда вам действительно нужна точная копия текущего состояния, а не история изменений

Базы данных: mysqldump и pg_dump в двух словах

Копировать файлы базы напрямую через tar, пока MySQL или PostgreSQL работает, - плохая идея: во время записи файл может оказаться в несогласованном состоянии. Правильный путь - логический дамп средствами самой СУБД.

mysqldump --single-transaction --quick mydb | gzip > mydb-$(date +%F).sql.gz

• --single-transaction - снимает согласованный слепок в рамках одной транзакции, не блокируя таблицы InnoDB на время дампа
• --quick - читает таблицу построчно, а не грузит её всю в память, полезно на больших базах

Для PostgreSQL аналог:

pg_dump -Fc mydb > mydb-$(date +%F).dump

• -Fc - собственный сжатый формат pg_dump, из которого потом можно восстановить и отдельные таблицы, а не только всю базу целиком через pg_restore

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

Шаг вперёд от tar и rsync: restic, а не borg

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

Из двух популярных вариантов - restic и borg - для типичного VPS мы рекомендуем restic по конкретной причине: он говорит по SFTP, S3-совместимому протоколу и ещё нескольким бэкендам напрямую, и ему не нужно ничего на другом конце, кроме SSH-доступа. Borg в похожей ситуации обычно требует, чтобы сам borg был установлен и на удалённой машине - он запускает там свой процесс через SSH. Если вторая точка хранения - чужой сервер или объектное хранилище, куда вы не планируете ничего лишнего ставить, restic просто удобнее. У borg дедупликация считается более зрелой - разумный повод присмотреться к нему отдельно, если объём данных большой и оба конца под вашим полным контролем.

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

Установите restic и создайте репозиторий - место, где будут храниться зашифрованные снимки:

sudo apt install -y restic

export RESTIC_REPOSITORY=sftp:user@backup-host:/srv/restic-repo

export RESTIC_PASSWORD='пароль-от-репозитория-не-от-сервера'

restic init

• пароль репозитория - это отдельный секрет, которым шифруются все снимки; потеряете его - потеряете доступ к бэкапу целиком, храните его отдельно от самого сервера
• пакет restic из стандартного репозитория Ubuntu иногда на версию-другую отстаёт от свежего релиза - если нужны самые новые флаги, скачайте актуальный бинарник со страницы релизов на GitHub

Сам бэкап и просмотр списка снимков:

restic backup /etc /var/www /home

restic snapshots

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

Чтобы старые снимки не копились бесконечно, задайте политику хранения:

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

• оставляет по одному снимку за последние 7 дней, по одному за последние 4 недели и по одному за последние 6 месяцев, остальное помечает на удаление
• --prune сразу же освобождает место в репозитории - без этого флага помеченные снимки просто перестают быть видны, но место на диске не возвращается

Автоматический бэкап VPS: systemd-таймер или cron

Команду, которую надо запускать руками раз в неделю, рано или поздно забудут, так что бэкап ставится на расписание. Systemd - штатная система запуска сервисов в Linux; кроме обычных служб она умеет запускать задачи по расписанию через пару unit-файлов - таймер и сервис, который он включает.

Сначала спрячьте пароль репозитория в отдельный файл, чтобы не хранить его прямо в unit-файле:

sudo tee /etc/restic/env >/dev/null <<'EOF'

RESTIC_REPOSITORY=sftp:user@backup-host:/srv/restic-repo

RESTIC_PASSWORD=пароль-от-репозитория

EOF

sudo chmod 600 /etc/restic/env

• chmod 600 - читать и писать файл может только root; в нём лежит секрет, который открывает доступ ко всем вашим бэкапам

Сервис, который выполняет сам бэкап - /etc/systemd/system/backup.service:

[Unit]

Description=Ежедневный бэкап через restic

[Service]

Type=oneshot

EnvironmentFile=/etc/restic/env

ExecStart=/usr/bin/restic backup /etc /var/www /home

ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

• Type=oneshot - служба один раз выполняет команду и завершается, а не работает постоянно в фоне, как, например, веб-сервер
• ExecStartPost - выполняется сразу после успешного бэкапа, здесь же чистит старые снимки по политике хранения

И таймер, который запускает этот сервис - /etc/systemd/system/backup.timer:

[Unit]

Description=Таймер ежедневного бэкапа

[Timer]

OnCalendar=*-*-* 03:00:00

Persistent=true

RandomizedDelaySec=600

[Install]

WantedBy=timers.target

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

Включите таймер:

sudo systemctl daemon-reload

sudo systemctl enable --now backup.timer

Что вы должны увидеть: systemctl list-timers backup.timer покажет строку с временем следующего запуска. Логи конкретного запуска смотрите через journalctl -u backup.service - это служебные логи самой задачи, не построчный вывод restic.

Если таймер кажется избыточным для одной команды, подойдёт и запись в crontab -e: 0 3 * * * /usr/bin/restic backup /etc /var/www /home >> /var/log/restic-backup.log 2>&1. Cron проще завести, systemd-таймер удобнее смотреть через journalctl и не теряет запуски, пропущенные из-за выключенного сервера.

Раз второе хранилище - другой сервер или облако, VPS должен доставать до него по сети: SSH-порт 22 для SFTP или 443 для S3-совместимого хранилища. ufw по умолчанию не блокирует исходящие соединения, но если вы меняли эту политику по инструкции про базовый ufw на VPS - проверьте sudo ufw status, прежде чем разбираться, почему restic не подключается.

Правило 3-2-1: сколько копий держать и где

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

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

Если из-за срока хранения снимков или объёма данных на сервере не хватает места даже под временный архив перед отправкой - это повод не урезать бэкапы, а поменять тариф VPS на диск побольше.

Проверяйте, что бэкап реально восстанавливается

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

restic restore latest --target /tmp/restore-test

• latest - самый свежий снимок, который подходит под указанные при бэкапе пути
• --target - куда развернуть файлы; используйте отдельный каталог или вообще отдельную тестовую машину, а не боевой сервер, чтобы случайно ничего не перезаписать

Заведите себе простое правило - раз в месяц действительно восстановить свежий снимок и сверить хотя бы один известный файл или запустить дамп базы обратно в тестовую копию СУБД. Это отнимает 10-15 минут и превращает бэкап из «наверное, работает» в проверенный факт.

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

Есть ли у WeaselCloud снапшоты VPS?

В проверенных разделах личного кабинета - нет. У услуги VPS на странице действий доступны только смена услуги и изменение тарифа, отдельной функции снапшота или бэкапа там не было. Резервное копирование настраивается полностью на стороне клиента.

restic или borg - что выбрать?

Для VPS с удалённым хранилищем, куда не хочется ставить лишний софт, - restic: он работает по SFTP и S3-совместимым протоколам без установки чего-либо на другом конце. Borg обычно требует установленный borg и на приёмной стороне, зато у него более зрелая дедупликация - разумный выбор, если оба конца под вашим полным контролем.

Куда складывать бэкапы VPS, если нет второго сервера?

Подойдёт S3-совместимое объектное хранилище, обычный SFTP-доступ на любой другой машине - включая домашний компьютер с постоянным включением - или недорогой второй VPS в другом регионе исключительно под роль бэкап-хранилища.

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

Через systemd-таймер (пара unit-файлов - сервис с самой командой и таймер с расписанием) или через обычный cron. Систематический вариант через systemd удобнее смотреть в логах через journalctl и не теряет пропущенные из-за выключения сервера запуски благодаря Persistent=true.

Нужно ли останавливать сайт на время бэкапа?

Для файлов - обычно нет, rsync и restic просто читают файлы как есть. Для баз данных остановка не нужна, если используете правильный флаг дампа - --single-transaction у mysqldump снимает согласованный слепок без блокировки таблиц InnoDB на всё время дампа.

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

Регулярно по-настоящему восстанавливать его - хотя бы раз в месяц развернуть свежий снимок командой вроде restic restore latest --target /каталог в отдельную папку или на тестовую машину и сверить содержимое. Пока восстановление не проверено, бэкап нельзя считать надёжным, каким бы регулярным ни было его создание.

Коротко

• В проверенных разделах панели WeaselCloud нет ни снапшотов, ни кнопки бэкапа - резервное копирование VPS настраивается полностью самостоятельно.
• Копия, которая лежит на том же диске, что и оригинал, бэкапом не является - файлы нужно уносить на другую машину: свой компьютер, второй VPS или объектное хранилище.
• Для файлов - tar для разового среза или rsync -aAX для регулярного обновления; для баз данных - mysqldump --single-transaction или pg_dump -Fc.
• restic - основной инструмент для инкрементального, зашифрованного и дедуплицированного бэкапа, работает по SFTP и S3-совместимым хранилищам без установки чего-либо на другой стороне; borg - альтернатива, если оба конца под вашим контролем.
• Автоматизация - systemd-таймер (расписание + журнал через journalctl) или cron; для удалённого хранилища серверу нужен исходящий доступ в сеть.
• Правило 3-2-1: 3 копии, на 2 разных носителях, минимум 1 - в другом месте физически.
• Бэкап без проверенного восстановления - непроверенный бэкап; раз в месяц реально разворачивайте свежий снимок и сверяйте содержимое.

Что дальше

• Защита свежего VPS: что сделать в первые 10 минут - если ещё не закрыли базовые уязвимости сервера до того, как настраивать бэкапы.
• Базовый фаервол ufw на VPS - что проверить в правилах исходящего трафика, если сервер не может подключиться ко второму хранилищу.
• Как поменять тариф VPS в WeaselCloud - если бэкапам и рабочим данным стало тесно на текущем диске.