--- title: "Снапшоты VPS и резервные копии на внешней площадке" description: "Как работают снапшоты VPS, сколько их входит в каждый тариф, как делать согласованные снимки и как добавить зашифрованные внешние резервные копии с restic." url: https://offshoreserv.com/ru/docs/vps/snapshots lang: ru updated: 2026-09-25 source: HTML page at the url above (canonical); this is its Markdown version --- База знаний · VPS # Снапшоты VPS и резервные копии на внешней площадке Как работают снапшоты VPS в OffshoreServ, сколько их входит в каждый тариф, как делать согласованные снапшоты и как настроить зашифрованное резервное копирование на внешнюю площадку с помощью restic или Borg. Обновлено 25 сентября 2026 г.5 мин чтения В этом руководстве - Снапшот — это копия диска VPS на определённый момент времени для быстрого отката. Он не заменяет резервную копию на внешней площадке. - Тарифы включают 2 снапшота (Dinghy, Sloop, Cutter), 3 (Schooner, Brigantine) или 5 (Frigate, Flagship). - Перед запросом снапшота сделайте дамп баз данных или остановите их. - Отправляйте зашифрованные резервные копии на другую площадку с помощью restic или Borg, удаляйте старые версии и проверяйте восстановление. VPS6 разделов Снапшоты позволяют быстро откатить [офшорный VPS](https://offshoreserv.com/ru/offshore-vps) к прежнему состоянию. Резервные копии позволяют восстановиться, если пропал сам сервер или доступ к нему. Нужно и то и другое. В этом руководстве объясняется, чем они различаются, каковы лимиты снапшотов по тарифам, как делать снапшоты, после которых базы данных остаются целыми, и как настроить зашифрованное резервное копирование на внешнюю площадку. ## Снапшоты и резервные копии Снапшот — это копия всего диска VPS на определённый момент времени, которая хранится на нашей платформе вместе с VPS. Восстановление из снапшота возвращает весь сервер точно в то состояние, поэтому это самый быстрый способ отменить неудачное обновление или ошибку в конфигурации. Резервная копия — это копия ваших данных, которая хранится в другом месте: на другом сервере, в другой локации, на вашем собственном оборудовании. Она не зависит от VPS, может хранить много версий и позволяет восстанавливать отдельные файлы. Обычно следуют правилу 3-2-1: три копии данных на носителях двух типов, одна из них — на внешней площадке. | Параметр | Снапшот | Резервная копия на внешней площадке | | --- | --- | --- | | Что копируется | Весь диск | Выбранные вами файлы и дампы баз данных | | Где хранится | На нашей платформе, вместе с вашим VPS | На машине под вашим контролем, в другом месте | | Восстановить | Откат всего диска | Отдельные файлы или полная пересборка сервера | | Версии | От 2 до 5 в зависимости от тарифа | Столько, сколько оставляет ваше правило хранения | | Защищает от | Неудачных обновлений, ошибок в конфигурации | Потери сервера, потери доступа, ошибок, замеченных спустя недели | ## Снапшоты в тарифах | Тарифы | Снапшоты | | --- | --- | | Dinghy, Sloop, Cutter | 2 | | Schooner, Brigantine | 3 | | Frigate, Flagship | 5 | Если все слоты заняты, укажите в запросе, какой снапшот заменить. ## Создание, восстановление и удаление снапшотов ### Создать На странице сервера в личном кабинете, в разделе **Действия с сервером**, выберите **Создать снапшот** и дайте ему имя, из которого понятно, зачем он сделан, например `before-php-upgrade`. Наша команда создаст снапшот, и запрос на той же странице будет отмечен как выполненный: дождитесь этого, прежде чем вносить рискованные изменения, такие как обновление дистрибутива до новой версии, установка нового ядра или миграция базы данных. Если на сервере работает база данных, сначала подготовьте её, как описано в следующем разделе. ### Восстановить > При восстановлении весь диск заменяется содержимым снапшота. Всё, что было записано после его создания, теряется: новые файлы, строки в базах данных, заказы, почта. Сначала скопируйте с сервера всё, что вам нужно, или сделайте снапшот текущего состояния, если есть свободный слот. В разделе **Действия с сервером** выберите **Восстановить из снапшота** и укажите имя снапшота. VPS вернётся в состояние на момент снапшота, а запрос будет отмечен как выполненный, когда сервер снова будет в сети. Проверьте, что ваши сервисы запустились, а задания по расписанию и сертификаты в порядке. ### Удалить Отправьте запрос **Удалить снапшот** в разделе **Действия с сервером**, указав имя снапшота. Удаление снапшота необратимо. Храните хотя бы один заведомо рабочий снапшот, например сделанный после первоначальной настройки, а снапшоты, сделанные перед изменениями, удаляйте, когда изменения несколько дней проработают без проблем. ## Как делать согласованные снапшоты Снапшот работающего сервера согласован на уровне сбоя (crash-consistent): диск выглядит так, будто в этот момент отключили питание. Журналируемые файловые системы хорошо с этим справляются. Базы данных обычно тоже восстанавливаются, но могут потерять последние транзакции, а таблица, в которую в этот момент шла запись, может оказаться повреждённой. Прежде чем запрашивать снапшот сервера с базой данных, воспользуйтесь одним из двух способов ниже. ### Кратковременная остановка базы данных Самый простой вариант. Остановите службу (для PostgreSQL она называется `postgresql`): ``` systemctl stop mariadb ``` Запросите снапшот и снова запустите службу, когда запрос будет отмечен как выполненный (до этого момента база данных недоступна): ``` systemctl start mariadb ``` ### Предварительный дамп баз данных Лучший вариант, если база данных должна оставаться доступной: дамп, сделанный непосредственно перед запросом снапшота, согласован, даже если рабочие файлы базы данных — нет, и его можно повторно использовать для резервного копирования на внешнюю площадку. Между созданием дампа и моментом, когда запрос будет отмечен как выполненный, не записывайте ничего важного. Для MariaDB (в MySQL команда называется `mysqldump`): ``` mkdir -p /root/db-dumps chmod 700 /root/db-dumps mariadb-dump --all-databases --single-transaction --routines --events > /root/db-dumps/mariadb.sql ``` Для PostgreSQL: ``` runuser -u postgres -- pg_dumpall > /root/db-dumps/postgresql.sql ``` ## Резервное копирование на внешнюю площадку с restic или Borg И restic, и Borg шифруют данные на вашем сервере до того, как что-либо его покинет, выполняют дедупликацию и экономно хранят множество версий. Место назначения видит только зашифрованные данные, поэтому им может быть любая машина, доступная по SSH: второй VPS, [сервер для хранения данных](https://offshoreserv.com/ru/offshore-dedicated-servers/storage) в другой нашей [локации](https://offshoreserv.com/ru/locations) или домашний компьютер. Копируйте `/etc`, `/home`, `/root`, корневые каталоги сайтов и данные приложений, а также дампы баз данных вместо рабочих файлов баз данных. Скорректируйте пути в примерах под свой сервер. ### restic На VPS установите restic, создайте SSH-ключ для root и скопируйте его на хост для резервных копий. Затем сгенерируйте случайный пароль репозитория, инициализируйте репозиторий и запустите первое резервное копирование: ``` apt install -y restic ssh-keygen -t ed25519 -N "" -f /root/.ssh/id_ed25519 ssh-copy-id backup@BACKUP_HOST install -m 600 /dev/null /root/.restic-pass openssl rand -base64 32 > /root/.restic-pass export RESTIC_REPOSITORY=sftp:backup@BACKUP_HOST:/srv/restic/web1 export RESTIC_PASSWORD_FILE=/root/.restic-pass restic init restic backup /etc /home /root /var/www --exclude-caches restic snapshots ``` > Сохраните копию пароля репозитория в менеджере паролей. Без него никто не сможет расшифровать резервную копию, в том числе и вы. ### Borg Borg должен быть установлен и на хосте для резервных копий, поскольку он работает там через SSH. Настройте SSH-ключ, как в примере с restic. Эти команды рассчитаны на Borg 1.2 и 1.4 — версии, которые входят в пакеты текущих выпусков Debian и Ubuntu: ``` apt install -y borgbackup install -m 600 /dev/null /root/.borg-pass openssl rand -base64 32 > /root/.borg-pass export BORG_REPO=ssh://backup@BACKUP_HOST/./borg/web1 export BORG_PASSCOMMAND="cat /root/.borg-pass" borg init --encryption=repokey-blake2 borg create --stats --compression zstd '::{hostname}-{now}' /etc /home /root /var/www borg list borg key export "$BORG_REPO" /root/borg-key.txt ``` Сохраните `borg-key.txt` и парольную фразу в надёжном месте вне сервера, затем удалите экспортированный файл с VPS. ## Автоматизация, очистка и проверка Поместите обе строки `export`, команды для дампа баз данных и команду резервного копирования в скрипт, например `/usr/local/sbin/offsite-backup`, и сделайте его доступным для чтения только root: ``` chmod 700 /usr/local/sbin/offsite-backup crontab -e ``` Добавьте в crontab пользователя root строку, которая будет запускать скрипт каждую ночь в 03:30: ``` 30 3 * * * /usr/local/sbin/offsite-backup ``` Завершите скрипт правилом хранения, чтобы старые версии удалялись. Приведённые правила сохраняют ежедневные копии за неделю, еженедельные — за месяц и ежемесячные — за шесть месяцев. Для restic: ``` restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune ``` Для Borg: ``` borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6 borg compact ``` Непроверенная резервная копия может не восстановиться, когда она понадобится. Раз в месяц проверяйте репозиторий и восстанавливайте данные во временный каталог. С restic: ``` restic check restic restore latest --target /root/restore-test ``` С Borg выведите список архивов, затем извлеките один из них в пустой каталог: ``` borg check mkdir -p /root/restore-test cd /root/restore-test borg extract '::ARCHIVE_NAME' etc ``` Сервер, который сам отправляет свои резервные копии, может их и удалить, если злоумышленник получит права root. Чтобы этого не случилось, сделайте репозиторий на хосте для резервных копий доступным только для добавления: у rest-server для restic есть режим `--append-only`, а Borg можно ограничить с помощью `borg serve --append-only` в файле `authorized_keys` пользователя, от имени которого выполняется резервное копирование. [Руководство по усилению защиты](https://offshoreserv.com/ru/docs/security/hardening) поможет вообще не допустить злоумышленников на сервер. **Застряли на каком-то шаге?** Клиенты с выделенными и GPU-серверами могут открыть тикет в [личном кабинете](https://offshoreserv.com/ru/account/support), указав IP-адрес сервера и то, что они уже пробовали сделать. Целевой срок первого ответа — менее 12 часов. Для всех остальных серверов используйте действия с сервером на его странице, [руководства](https://offshoreserv.com/ru/docs) и страницу [статуса сети](https://offshoreserv.com/ru/status). --- OffshoreServ — офшорный хостинг-провайдер: VPS, выделенные серверы, Windows RDP и GPU-серверы в семи юрисдикциях (Исландия, Швейцария, Молдова, Румыния, Нидерланды, Болгария и Малайзия), оплата только криптовалютой (Bitcoin, Ethereum, Monero, Tether (USDT) и Solana), без проверки личности (без KYC). Prices and plans: https://offshoreserv.com/ru/pricing · Answers: https://offshoreserv.com/ru/faq · Every page: https://offshoreserv.com/llms.txt